Folks I wanted to try to get some clarification on entries in a default keytab. This whole thing started with switching from using adcli on RHEL 7.5 to using realmd which defaults to using winbind/samba to join a system.
With adcli the keytab created on join (using realm join) looked something like this (ordering of entries is important here, and I am omitting duplicate entries with different encryption types for brevity): EXAMPLE$@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM RestrictedKrbHost/EXAMPLE@AD.EXAMPLE.COM RestrictedKrbHost/example.ad.example.com@AD.EXAMPLE.COM
Ok I can successfully kinit with the keytab using the samAccountName/NetBIOS name: kinit -k EXAMPLE$
I can NOT kinit with the other principals, the following fails: host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM RestrictedKrbHost/EXAMPLE@AD.EXAMPLE.COM RestrictedKrbHost/example.ad.example.com@AD.EXAMPLE.COM
All fail with variation of: kinit: Client 'X' not found in Kerberos database while getting initial credentials
After reading a lot this makes sense, these are service principals not host or user principals, best reference is here: https://ssimo.org/blog/id_016.html (Thanks Simo!)
You can make some of these host principals by setting the userPrincipalName to something like host/EXAMPLE@AD.EXAMPLE.COM or host/example.ad.example.com@AD.EXAMPLE.COM but this does not happen by default with realm join (which contradicts the man pages, I have a bug open on that here: https://bugzilla.redhat.com/show_bug.cgi?id=1643814)
Fine, now when joining using samba/winbind you end up with a keytab like this (here I will not omit the duplicates as it seems important to capture it all): host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM
Again I can kinit with the NetBIOS name but no others.
Now the trouble arises for me when I am trying to use something like requests-gssapi: https://github.com/pythongssapi/requests-gssapi when the system is joined using realmd/adcli simple code will work, it will kinit as the first principal it finds in the keytab, which is the NetBIOS name/samAccountName which is a host principal, everything just works.
However, when the system is joined using realmd/samba the keytab is in a completely different order and it turns out those first entries, they are not user principals nor host principals so everything at that point fails with 'client not found'. How to specify the principal to use is spectacularly unclear to me at least in python-gssapi and requests-gssapi, but that isn't really the question here. If you know the answer to that though, please feel free to chime in.
What should be the host or user principals that are held by the default keytab? And what should be service principals? And most importantly why? It is all very unclear to me.
I can force realmd to create a userPrincipleName which maps to a user principal with the --user-principal flag, but what is correct? Samba defaults to creating a UPN of host/EXAMPLE@AD.EXAMPLE.COM, and adcli defaults to host/example@AD.EXAMPLE.COM (which isn't even in the keytab) if user-princpal=yes in /etc/realmd.conf, otherwise I have not figured out how to use defaults from the command line and the man page appears to be incorrect that a UPN is created by default. I can obviously specify host/example.ad.example.com@AD.EXAMPLE.COM. But I can't seem to cover all the entries that are created by default in the /etc/krb5.keytab nor am I even sure if I should, if I could.
Clarity here would be much appreciated. And good luck with IBM, I really hope it makes things better.
On Mon, Oct 29, 2018 at 05:17:09AM -0000, Erinn Looney-Triggs wrote:
Folks I wanted to try to get some clarification on entries in a default keytab. This whole thing started with switching from using adcli on RHEL 7.5 to using realmd which defaults to using winbind/samba to join a system.
With adcli the keytab created on join (using realm join) looked something like this (ordering of entries is important here, and I am omitting duplicate entries with different encryption types for brevity): EXAMPLE$@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM RestrictedKrbHost/EXAMPLE@AD.EXAMPLE.COM RestrictedKrbHost/example.ad.example.com@AD.EXAMPLE.COM
Ok I can successfully kinit with the keytab using the samAccountName/NetBIOS name: kinit -k EXAMPLE$
I can NOT kinit with the other principals, the following fails: host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM RestrictedKrbHost/EXAMPLE@AD.EXAMPLE.COM RestrictedKrbHost/example.ad.example.com@AD.EXAMPLE.COM
All fail with variation of: kinit: Client 'X' not found in Kerberos database while getting initial credentials
After reading a lot this makes sense, these are service principals not host or user principals, best reference is here: https://ssimo.org/blog/id_016.html (Thanks Simo!)
You can make some of these host principals by setting the userPrincipalName to something like host/EXAMPLE@AD.EXAMPLE.COM or host/example.ad.example.com@AD.EXAMPLE.COM but this does not happen by default with realm join (which contradicts the man pages, I have a bug open on that here: https://bugzilla.redhat.com/show_bug.cgi?id=1643814)
Fine, now when joining using samba/winbind you end up with a keytab like this (here I will not omit the duplicates as it seems important to capture it all): host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM
Again I can kinit with the NetBIOS name but no others.
Now the trouble arises for me when I am trying to use something like requests-gssapi: https://github.com/pythongssapi/requests-gssapi when the system is joined using realmd/adcli simple code will work, it will kinit as the first principal it finds in the keytab, which is the NetBIOS name/samAccountName which is a host principal, everything just works.
However, when the system is joined using realmd/samba the keytab is in a completely different order and it turns out those first entries, they are not user principals nor host principals so everything at that point fails with 'client not found'. How to specify the principal to use is spectacularly unclear to me at least in python-gssapi and requests-gssapi, but that isn't really the question here. If you know the answer to that though, please feel free to chime in.
There is https://github.com/pythongssapi/requests-gssapi#explicit-principal do this help?
What should be the host or user principals that are held by the default keytab? And what should be service principals? And most importantly why? It is all very unclear to me.
You already mentioned that you need a user principals what kinit. Which of the principal is a user principal and which a service principal and if it makes a difference at all is completely up to the KDC. With AD 'samAccountName@AD.REALM' is the default and canonical principal, for hosts the samAccountName always ends with a '$' due to the NT and older heritage. You can add another user principal name in the userPrincipalName name, but only one since this LDAP attribute is a single-value attribute iirc. But even then 'samAccountName@AD.REALM' will still work.
Service principals are added to the default keytab /etc/krb5.keytab as well to make configuration more simple because many services will use it as the default location to lookup their principals too. Additionally in other Kerberos environments the KDC does not make this clear distinction between user and services principals. E.g. with FreeIPA you will only have a host/fully.qualified.name@IPA.REALM entry in /etc/krb5.keytab which can be used with kinit but is also used by sshd as service principal.
I can force realmd to create a userPrincipleName which maps to a user principal with the --user-principal flag, but what is correct? Samba defaults to creating a UPN of host/EXAMPLE@AD.EXAMPLE.COM, and adcli defaults to host/example@AD.EXAMPLE.COM (which isn't even in the keytab) if user-princpal=yes in /etc/realmd.conf, otherwise I have not figured out how to use defaults from the command line and the man page appears to be incorrect that a UPN is created by default. I can obviously specify host/example.ad.example.com@AD.EXAMPLE.COM. But I can't seem to cover all the entries that are created by default in the /etc/krb5.keytab nor am I even sure if I should, if I could.
I think this can be solved with the ticket you've opened.
Clarity here would be much appreciated. And good luck with IBM, I really hope it makes things better.
Thanks. I hope this help to clear it up a bit.
bye, Sumit
Sumit,
Thanks, like usual I appreciate you taking the time. After tapping this entire thing out, things became clearer to me within a few hours. It seems that is my curse, I get to ask a bunch of questions and then figure them out, which makes me feel silly afterwards.
But again thank you for confirming what I figured out after sending this off, it always helps.
-Erinn
On 10/30/18 9:52 AM, Sumit Bose wrote:
On Mon, Oct 29, 2018 at 05:17:09AM -0000, Erinn Looney-Triggs wrote:
Folks I wanted to try to get some clarification on entries in a default keytab. This whole thing started with switching from using adcli on RHEL 7.5 to using realmd which defaults to using winbind/samba to join a system.
With adcli the keytab created on join (using realm join) looked something like this (ordering of entries is important here, and I am omitting duplicate entries with different encryption types for brevity): EXAMPLE$@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM RestrictedKrbHost/EXAMPLE@AD.EXAMPLE.COM RestrictedKrbHost/example.ad.example.com@AD.EXAMPLE.COM
Ok I can successfully kinit with the keytab using the samAccountName/NetBIOS name: kinit -k EXAMPLE$
I can NOT kinit with the other principals, the following fails: host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM RestrictedKrbHost/EXAMPLE@AD.EXAMPLE.COM RestrictedKrbHost/example.ad.example.com@AD.EXAMPLE.COM
All fail with variation of: kinit: Client 'X' not found in Kerberos database while getting initial credentials
After reading a lot this makes sense, these are service principals not host or user principals, best reference is here: https://ssimo.org/blog/id_016.html (Thanks Simo!)
You can make some of these host principals by setting the userPrincipalName to something like host/EXAMPLE@AD.EXAMPLE.COM or host/example.ad.example.com@AD.EXAMPLE.COM but this does not happen by default with realm join (which contradicts the man pages, I have a bug open on that here: https://bugzilla.redhat.com/show_bug.cgi?id=1643814)
Fine, now when joining using samba/winbind you end up with a keytab like this (here I will not omit the duplicates as it seems important to capture it all): host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM host/example.ad.example.com@AD.EXAMPLE.COM host/EXAMPLE@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM EXAMPLE$@AD.EXAMPLE.COM
Again I can kinit with the NetBIOS name but no others.
Now the trouble arises for me when I am trying to use something like requests-gssapi: https://github.com/pythongssapi/requests-gssapi when the system is joined using realmd/adcli simple code will work, it will kinit as the first principal it finds in the keytab, which is the NetBIOS name/samAccountName which is a host principal, everything just works.
However, when the system is joined using realmd/samba the keytab is in a completely different order and it turns out those first entries, they are not user principals nor host principals so everything at that point fails with 'client not found'. How to specify the principal to use is spectacularly unclear to me at least in python-gssapi and requests-gssapi, but that isn't really the question here. If you know the answer to that though, please feel free to chime in.
There is https://github.com/pythongssapi/requests-gssapi#explicit-principal do this help?
What should be the host or user principals that are held by the default keytab? And what should be service principals? And most importantly why? It is all very unclear to me.
You already mentioned that you need a user principals what kinit. Which of the principal is a user principal and which a service principal and if it makes a difference at all is completely up to the KDC. With AD 'samAccountName@AD.REALM' is the default and canonical principal, for hosts the samAccountName always ends with a '$' due to the NT and older heritage. You can add another user principal name in the userPrincipalName name, but only one since this LDAP attribute is a single-value attribute iirc. But even then 'samAccountName@AD.REALM' will still work.
Service principals are added to the default keytab /etc/krb5.keytab as well to make configuration more simple because many services will use it as the default location to lookup their principals too. Additionally in other Kerberos environments the KDC does not make this clear distinction between user and services principals. E.g. with FreeIPA you will only have a host/fully.qualified.name@IPA.REALM entry in /etc/krb5.keytab which can be used with kinit but is also used by sshd as service principal.
I can force realmd to create a userPrincipleName which maps to a user principal with the --user-principal flag, but what is correct? Samba defaults to creating a UPN of host/EXAMPLE@AD.EXAMPLE.COM, and adcli defaults to host/example@AD.EXAMPLE.COM (which isn't even in the keytab) if user-princpal=yes in /etc/realmd.conf, otherwise I have not figured out how to use defaults from the command line and the man page appears to be incorrect that a UPN is created by default. I can obviously specify host/example.ad.example.com@AD.EXAMPLE.COM. But I can't seem to cover all the entries that are created by default in the /etc/krb5.keytab nor am I even sure if I should, if I could.
I think this can be solved with the ticket you've opened.
Clarity here would be much appreciated. And good luck with IBM, I really hope it makes things better.
Thanks. I hope this help to clear it up a bit.
bye, Sumit _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Erinn Looney-Triggs -
Reinaldo Gomes -
Sumit Bose