Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
Best, Patrice
On Mon, 22 Feb 2016, Patrice Peterson wrote:
Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not any of the others. That one's the only one that's a userPrincipal by default (although you can choose *one* additional userPrincipal if you require).
You can test this on the command line as it's the only one kinit -k will work with:
# These work kinit -k SHORTHOST$ kinit -k SHORTHOST$@DS.LEEDS.AC.UK
# These do not work kinit -k host/fqdn kinit -k host/fqdn@DS.LEEDS.AC.UK
So I'm not entirely sold on your diagnosis being correct.
jh
On Mon, Feb 22, 2016 at 09:41:47AM +0000, John Hodrien wrote:
On Mon, 22 Feb 2016, Patrice Peterson wrote:
Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not any of the others. That one's the only one that's a userPrincipal by default (although you can choose *one* additional userPrincipal if you require).
You can test this on the command line as it's the only one kinit -k will work with:
# These work kinit -k SHORTHOST$ kinit -k SHORTHOST$@DS.LEEDS.AC.UK
# These do not work kinit -k host/fqdn kinit -k host/fqdn@DS.LEEDS.AC.UK
So I'm not entirely sold on your diagnosis being correct.
I agree with John here. Can you share your sssd.conf?
bye, Sumit
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On (22/02/16 11:48), Sumit Bose wrote:
On Mon, Feb 22, 2016 at 09:41:47AM +0000, John Hodrien wrote:
On Mon, 22 Feb 2016, Patrice Peterson wrote:
Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not any of the others. That one's the only one that's a userPrincipal by default (although you can choose *one* additional userPrincipal if you require).
You can test this on the command line as it's the only one kinit -k will work with:
# These work kinit -k SHORTHOST$ kinit -k SHORTHOST$@DS.LEEDS.AC.UK
# These do not work kinit -k host/fqdn kinit -k host/fqdn@DS.LEEDS.AC.UK
So I'm not entirely sold on your diagnosis being correct.
I agree with John here. Can you share your sssd.conf?
And also sssd domain log file and (*_child.log) https://fedorahosted.org/sssd/wiki/Troubleshooting
LS
I've come across the same issue in the last two weeks. here are the details of my situation and how I worked around it.
I'm trying to design an agnostic way to join both RHEL 6 and RHEL 7 to AD and have settled on adcli because it's available for both, realmd isn't for 6. In doing so I also wanted to Kerberize SSH and fought with it for quite some time until I discovered OpenSSH's proclivity to want lowercase 'host/...' in the principal. This is what I found. It all came down to the case of the word 'host' in the principals it creates in both the AD object and the keytab on the Linux host.
Adcli by default will create principals in the keytab and on the AD object itself with uppercase 'HOST/...' but that effectively disables SSH, if I did nothing else but change the case of the word 'host' in the AD object to be lowercase and match the case in the keytab I could get SSH and AD lookups to work.
I finally ended up playing with adcli command line options and found that I could have adcli create the principal in lowercase in both the keytab and the AD object by adding " --service-name=host" as an option. Name lookups work and SSH works, and I don't have to do anything special after the join to align principals. I'm not sure what the consequences of a lowercase 'host/...' in a Kerberos principal is, but this lets everything I need right now work for me.
I wondered if this was a bug or not, but I finally decided that because adcli creates the principals consistently, it's really SSH's issue not working with uppercase 'HOST/...' in principals that's the problem.
Todd
-----Original Message----- From: Lukas Slebodnik [mailto:lslebodn@redhat.com] Sent: Monday, February 22, 2016 5:07 AM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
On (22/02/16 11:48), Sumit Bose wrote:
On Mon, Feb 22, 2016 at 09:41:47AM +0000, John Hodrien wrote:
On Mon, 22 Feb 2016, Patrice Peterson wrote:
Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not any of the others. That one's the only one that's a userPrincipal by default (although you can choose *one* additional userPrincipal if you require).
You can test this on the command line as it's the only one kinit -k will work with:
# These work kinit -k SHORTHOST$ kinit -k SHORTHOST$@DS.LEEDS.AC.UK
# These do not work kinit -k host/fqdn kinit -k host/fqdn@DS.LEEDS.AC.UK
So I'm not entirely sold on your diagnosis being correct.
I agree with John here. Can you share your sssd.conf?
And also sssd domain log file and (*_child.log) https://fedorahosted.org/sssd/wiki/Troubleshooting
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Mon, Feb 22, 2016 at 01:39:58PM +0000, Mote, Todd wrote:
I've come across the same issue in the last two weeks. here are the details of my situation and how I worked around it.
I'm trying to design an agnostic way to join both RHEL 6 and RHEL 7 to AD and have settled on adcli because it's available for both, realmd isn't for 6. In doing so I also wanted to Kerberize SSH and fought with it for quite some time until I discovered OpenSSH's proclivity to want lowercase 'host/...' in the principal. This is what I found. It all came down to the case of the word 'host' in the principals it creates in both the AD object and the keytab on the Linux host.
Adcli by default will create principals in the keytab and on the AD object itself with uppercase 'HOST/...' but that effectively disables SSH, if I did nothing else but change the case of the word 'host' in the AD object to be lowercase and match the case in the keytab I could get SSH and AD lookups to work.
I finally ended up playing with adcli command line options and found that I could have adcli create the principal in lowercase in both the keytab and the AD object by adding " --service-name=host" as an option. Name lookups work and SSH works, and I don't have to do anything special after the join to align principals. I'm not sure what the consequences of a lowercase 'host/...' in a Kerberos principal is, but this lets everything I need right now work for me.
I wondered if this was a bug or not, but I finally decided that because adcli creates the principals consistently, it's really SSH's issue not working with uppercase 'HOST/...' in principals that's the problem.
As Patrice already mentioned the upper-case HOST/... is an issue in adcli which is fixed in recent version of adcli, see https://bugs.freedesktop.org/show_bug.cgi?id=84749 for details.
The lower-case version 'host/...' should be always used. I try to avoid saying that this is the right or correct version, becasue it is just an convention. According to the related RFCs Kerberos is case-sensitive which means that 'HOST/...' and 'host/...' are different principals from the Kerberos point of view. When a service is kerberized the client and the server side programs of the service must use the same principal and must not only use the same service name but the same case as well. Some services like ssh ('host/...') or ldap ('ldap/...') use lower-case service names while other services like dns ('DNS/...') or http ('HTTP/...') use upper-case service name.
That said the lower-case 'host/...' is mentioned in the Kerberos RFC 4120 in section 1.3 (http://tools.ietf.org/html/rfc4120#section-1.3). Although it is only a "might be derived from" I think it is a quite strong recommendation to use (host/...) for services to access the host directly like telnet and ssh.
Btw, if you switch to a newer version of adcli which uses host/... you might need to removed the host with 'adcli delete-computer ...' first. The reason is that AD treats Kerberos mostly case-insensitive (in contrast to the RFC) and might not recognise that the new version of adcli might want to change the principal to lower-case and keep using the upper-case version.
HTH
bye, Sumit
Todd
-----Original Message----- From: Lukas Slebodnik [mailto:lslebodn@redhat.com] Sent: Monday, February 22, 2016 5:07 AM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
On (22/02/16 11:48), Sumit Bose wrote:
On Mon, Feb 22, 2016 at 09:41:47AM +0000, John Hodrien wrote:
On Mon, 22 Feb 2016, Patrice Peterson wrote:
Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not any of the others. That one's the only one that's a userPrincipal by default (although you can choose *one* additional userPrincipal if you require).
You can test this on the command line as it's the only one kinit -k will work with:
# These work kinit -k SHORTHOST$ kinit -k SHORTHOST$@DS.LEEDS.AC.UK
# These do not work kinit -k host/fqdn kinit -k host/fqdn@DS.LEEDS.AC.UK
So I'm not entirely sold on your diagnosis being correct.
I agree with John here. Can you share your sssd.conf?
And also sssd domain log file and (*_child.log) https://fedorahosted.org/sssd/wiki/Troubleshooting
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Monday, February 22, 2016 8:35 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
As Patrice already mentioned the upper-case HOST/... is an issue in adcli which is fixed in recent version of adcli, see https://bugs.freedesktop.org/show_bug.cgi?id=84749 for details.
Glad to see it's fixed, though Redhat currently only has version 0.7.5-4 in Satellite for RHEL 7 and was built on 01-Jan-14, so this may exist in 7 still, I'm not Linux savvy enough to know/find out. I do see that RHEL 6's version, 0.8.0-1, was built on 17-Dec-15, but is not in my EPEL Server 6 channel. I checked on some of my hosts and they are indeed running 0.7.3 still.
I talked to our Satellite admin and he reminded me that we curate patches in our Satellite on a three-month schedule to allow large clusters of systems to remain patch consistent and provide enough time for them all to patch together. Satellite last updated 01-Dec-15, so just missed getting 0.8.0. It's due to sync again next Tuesday on 01-Mar-16, so I should have 0.8.0 on everything RHEL 6 before too long.
The lower-case version 'host/...' should be always used. I try to avoid saying that this is the right or correct version, becasue it is just an convention. According to the related RFCs Kerberos is case-sensitive which means that 'HOST/...' and 'host/...' are different principals from the Kerberos point of view. When a service is kerberized the client and the server side programs of the service must use the same principal and must not only use the same service name but the same case as well. Some services like ssh ('host/...') or ldap ('ldap/...') use lower-case service names while other services like dns ('DNS/...') or http ('HTTP/...') use upper-case service name.
That's consistent with what I observed.
That said the lower-case 'host/...' is mentioned in the Kerberos RFC 4120 in section 1.3 (http://tools.ietf.org/html/rfc4120#section-1.3). Although it is only a "might be derived from" I think it is a quite strong recommendation to use (host/...) for services to access the host directly like telnet and ssh.
Btw, if you switch to a newer version of adcli which uses host/... you might need to removed the host with 'adcli delete-computer ...' first. The reason is that AD treats Kerberos mostly case-insensitive (in contrast to the RFC) and might not recognise that the new version of adcli might want to change the principal to lower-case and keep using the upper-case version.
That's true, AD won't let you put two principals in the servicePrincipalName attribute because it considers them the same principal and complains that one with that name already exists. Adcli join will however increment the msDS-KeyVersionNumber attribute and remove all of the existing principals on the AD object and then add them back with whatever options you set, if you just do the join again, no delete required. On Linux, it will increment the knvo in the keytab so that it stays in step with the AD object attribute, and just add new principals to the keytab. I found myself with principals in my keytab at one point duplicated, one set had 'host/' the other had 'HOST/'. Adcli delete-computer may clean up the keytab for you too, I've not tried it though.
Todd
Todd
-----Original Message----- From: Lukas Slebodnik [mailto:lslebodn@redhat.com] Sent: Monday, February 22, 2016 5:07 AM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
On (22/02/16 11:48), Sumit Bose wrote:
On Mon, Feb 22, 2016 at 09:41:47AM +0000, John Hodrien wrote:
On Mon, 22 Feb 2016, Patrice Peterson wrote:
Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not any of the others. That one's the only one that's a userPrincipal by default (although you can choose *one* additional userPrincipal if you require).
You can test this on the command line as it's the only one kinit -k will work with:
# These work kinit -k SHORTHOST$ kinit -k SHORTHOST$@DS.LEEDS.AC.UK
# These do not work kinit -k host/fqdn kinit -k host/fqdn@DS.LEEDS.AC.UK
So I'm not entirely sold on your diagnosis being correct.
I agree with John here. Can you share your sssd.conf?
And also sssd domain log file and (*_child.log) https://fedorahosted.org/sssd/wiki/Troubleshooting
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Mon, Feb 22, 2016 at 03:31:53PM +0000, Mote, Todd wrote:
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Monday, February 22, 2016 8:35 AM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
As Patrice already mentioned the upper-case HOST/... is an issue in adcli which is fixed in recent version of adcli, see https://bugs.freedesktop.org/show_bug.cgi?id=84749 for details.
Glad to see it's fixed, though Redhat currently only has version 0.7.5-4 in Satellite for RHEL 7 and was built on 01-Jan-14, so this may exist in 7 still, I'm not Linux savvy enough to know/find out. I do see that RHEL 6's version, 0.8.0-1, was built on 17-Dec-15, but is not in my EPEL Server 6 channel. I checked on some of my hosts and they are indeed running 0.7.3 still.
It will be fixed in the next RHEL7 realease, ticket is https://bugzilla.redhat.com/show_bug.cgi?id=1061371.
About EPEL, adcli-0.8.0 is available, see https://dl.fedoraproject.org/pub/epel/6/x86_64/adcli-0.8.0-1.el6.x86_64.rpm but please note the typically the EPEL package will be retired when the RHEL package becomes available.
bye, Sumit
I talked to our Satellite admin and he reminded me that we curate patches in our Satellite on a three-month schedule to allow large clusters of systems to remain patch consistent and provide enough time for them all to patch together. Satellite last updated 01-Dec-15, so just missed getting 0.8.0. It's due to sync again next Tuesday on 01-Mar-16, so I should have 0.8.0 on everything RHEL 6 before too long.
The lower-case version 'host/...' should be always used. I try to avoid saying that this is the right or correct version, becasue it is just an convention. According to the related RFCs Kerberos is case-sensitive which means that 'HOST/...' and 'host/...' are different principals from the Kerberos point of view. When a service is kerberized the client and the server side programs of the service must use the same principal and must not only use the same service name but the same case as well. Some services like ssh ('host/...') or ldap ('ldap/...') use lower-case service names while other services like dns ('DNS/...') or http ('HTTP/...') use upper-case service name.
That's consistent with what I observed.
That said the lower-case 'host/...' is mentioned in the Kerberos RFC 4120 in section 1.3 (http://tools.ietf.org/html/rfc4120#section-1.3). Although it is only a "might be derived from" I think it is a quite strong recommendation to use (host/...) for services to access the host directly like telnet and ssh.
Btw, if you switch to a newer version of adcli which uses host/... you might need to removed the host with 'adcli delete-computer ...' first. The reason is that AD treats Kerberos mostly case-insensitive (in contrast to the RFC) and might not recognise that the new version of adcli might want to change the principal to lower-case and keep using the upper-case version.
That's true, AD won't let you put two principals in the servicePrincipalName attribute because it considers them the same principal and complains that one with that name already exists. Adcli join will however increment the msDS-KeyVersionNumber attribute and remove all of the existing principals on the AD object and then add them back with whatever options you set, if you just do the join again, no delete required. On Linux, it will increment the knvo in the keytab so that it stays in step with the AD object attribute, and just add new principals to the keytab. I found myself with principals in my keytab at one point duplicated, one set had 'host/' the other had 'HOST/'. Adcli delete-computer may clean up the keytab for you too, I've not tried it though.
Todd
Todd
-----Original Message----- From: Lukas Slebodnik [mailto:lslebodn@redhat.com] Sent: Monday, February 22, 2016 5:07 AM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
On (22/02/16 11:48), Sumit Bose wrote:
On Mon, Feb 22, 2016 at 09:41:47AM +0000, John Hodrien wrote:
On Mon, 22 Feb 2016, Patrice Peterson wrote:
Hey list,
I have joined a CentOS 7 host to an AD domain using a fairly new version of adcli (one of the versions that has this [0] bug fixed). In its keytab, this host has a service principal of the form 'host/fqdn@REALM' (i.e. lowercase). User lookups with SSSD don't work, and the SSSD log says "Client 'host/fdqn@REALM' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection."
However, if I use the 'old' adcli to join the node and create the keytab, it creates a service principal of the form 'HOST/fqdn@REALM'. With this keytab, I can do username lookups just fine.
Should this be considered a bug? Is there a way to make service principal lookups w/SSSD case insensitive? I would like to keep the lower-case principal names in my keytabs, because OpenSSH GSSAPI auth only works with those.
Thanks for any pointers!
SSSD with a normal AD joined machine would use the SHORTHOST$@REALM entry, not any of the others. That one's the only one that's a userPrincipal by default (although you can choose *one* additional userPrincipal if you require).
You can test this on the command line as it's the only one kinit -k will work with:
# These work kinit -k SHORTHOST$ kinit -k SHORTHOST$@DS.LEEDS.AC.UK
# These do not work kinit -k host/fqdn kinit -k host/fqdn@DS.LEEDS.AC.UK
So I'm not entirely sold on your diagnosis being correct.
I agree with John here. Can you share your sssd.conf?
And also sssd domain log file and (*_child.log) https://fedorahosted.org/sssd/wiki/Troubleshooting
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost ed.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Hi, thanks for taking the time to look at this!
The domain log file is pretty long at debug_level = 6, so I hope I've trimmed it down to the snippet that could be of interest (FQDN redacted):
(Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/fqdn, XD.UNI-HALLE.DE, 86400) (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD' (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [be_resolve_server_process] (0x0200): Found address for server xd-dc02.xd.uni-halle.de: [172.30.10.2] TTL 3600 (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 84 (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [child_sig_handler] (0x0100): child [24138] finished successfully. (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Client not found in Kerberos database], expired on [0] (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Mon Feb 22 21:22:12 2016) [sssd[be[xd.uni-halle.de]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed)
ldap_child.log (debug_level = 6, I hope—I set the debug level under the [sssd] and [domain/foo] sections. FQDN redacted):
(Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [main] (0x0400): ldap_child started. (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [become_user] (0x0200): Trying to become user [0][0]. (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [become_user] (0x0200): Already user [0]. (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/fqdn@XD.UNI-HALLE.DE] (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 'host/fqdn@XD.UNI-HALLE.DE' not found in Kerberos database (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [prepare_response] (0x0400): Building response for result [-1765328378] (Mon Feb 22 21:21:10 2016) [[sssd[ldap_child[23472]]]] [main] (0x0400): ldap_child completed successfully
This happens over and over.
-Patrice
Sure, it's pretty small:
[sssd] config_file_version = 2 services = nss, pam domains = xd.uni-halle.de
[domain/xd.uni-halle.de] id_provider = ad ldap_id_mapping = False ldap_schema = ad ldap_group_search_base = DC=xd,DC=uni-halle,DC=de ldap_user_search_base = DC=xd,DC=uni-halle,DC=de access_provider = ad
Thanks for the help!
Hi, thanks for replying!
While you're correct in that neither of the SPNs work, I can literally not do username lookups unless I have a SPN that starts with HOST/.
I just tried the following:
1. Using older adcli (which by default produces HOST/ SPNs) to re-join the host -> lookups are not working 2. Using newer adcli (which produces host/) to re-join the host -> lookups are not working, client exhibits error described in my initial e-mail 3. Using newer adcli to re-join, but add the "--user-principal=HOST/fqdn@REALM" option so that *both* SPNs are in the keytab) -> lookups are working
Every time, I made sure to stop SSSD before making any modifications, deleted /var/lib/sss/{db,mc}/*, and restarted SSSD afterwards. I will try to up the debug level and see what I can find, and I'll post my logfiles in reply to another mail in this thread.
In any case, thanks for telling me about kinit -k <NETBIOSname>!
-Patrice
On Mon, Feb 22, 2016 at 08:04:42PM -0000, Patrice Peterson wrote:
Hi, thanks for replying!
While you're correct in that neither of the SPNs work, I can literally not do username lookups unless I have a SPN that starts with HOST/.
I just tried the following:
- Using older adcli (which by default produces HOST/ SPNs) to re-join the host -> lookups are not working
- Using newer adcli (which produces host/) to re-join the host -> lookups are not working, client exhibits error described in my initial e-mail
- Using newer adcli to re-join, but add the "--user-principal=HOST/fqdn@REALM" option so that *both* SPNs are in the keytab) -> lookups are working
Please note that the principal you give with the --user-principal option is not a SPN (service principal name) but a UPN (user principal names). Only UPNs can be used to get a Kerberos TGT, i.e. can be used with kinit.
As you can see form the logs SSSD tries to use host/fqdn@XD.UNI-HALLE.DE to get a TGT. Since AD handles principal case-insensitive HOST/fqdn@XD.UNI-HALLE.DE will work as well as long as it is defined as UPN (I would expect that it will work the same if you use '--user-principal=host/fqdn@REALM'.
In general the default UPN is NetBIOSName$@REALM and SSSD will use it if a matching entry is in the keytab. But there are some restrictions to the NetBIOS name, e.g. only 15 characters are allowed and only a few special characters. Do you have and entry '...$@REALM' in the keytab? Does the name before the $ match the first part of the fully qualified host name of the client or is it truncated or special characters removed?
You you have a '...$@REALM' entry in the keytab which differs somehow from the hostname you can try to add this principal to sssd.conf with
ldap_sasl_authid = NetBIOSName$@REALM
where NetBIOSName$@REALM matches the entry in the keytab to tell SSSD to use this principal for kinit.
HTH
bye, Sumit
Every time, I made sure to stop SSSD before making any modifications, deleted /var/lib/sss/{db,mc}/*, and restarted SSSD afterwards. I will try to up the debug level and see what I can find, and I'll post my logfiles in reply to another mail in this thread.
In any case, thanks for telling me about kinit -k <NETBIOSname>!
-Patrice _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Mon, Feb 22, 2016 at 08:04:42PM -0000, Patrice Peterson wrote:
Please note that the principal you give with the --user-principal option is not a SPN (service principal name) but a UPN (user principal names). Only UPNs can be used to get a Kerberos TGT, i.e. can be used with kinit.
As you can see form the logs SSSD tries to use host/fqdn(a)XD.UNI-HALLE.DE to get a TGT. Since AD handles principal case-insensitive HOST/fqdn(a)XD.UNI-HALLE.DE will work as well as long as it is defined as UPN (I would expect that it will work the same if you use '--user-principal=host/fqdn@REALM'.
Yes, I just tried that and you were right. My mental model of host authentication was apparently completely wrong—I knew computers were basically "users" in AD, but I didn't apply this knowledge to this situation…
In general the default UPN is NetBIOSName$@REALM and SSSD will use it if a matching entry is in the keytab. But there are some restrictions to the NetBIOS name, e.g. only 15 characters are allowed and only a few special characters. Do you have and entry '...$@REALM' in the keytab? Does the name before the $ match the first part of the fully qualified host name of the client or is it truncated or special characters removed?
I do have 'Netbiosname$@REALM', but I had to make it different from the first part of the FQDN (i.e. it is 'HPC-login001' while the first part of the FQDN is 'login001', without the 'HPC'). I didn't even know that this could be a problem, so thanks again for putting me on the right path!
If you have a '...$@REALM' entry in the keytab which differs somehow from the hostname you can try to add this principal to sssd.conf with
ldap_sasl_authid = NetBIOSName$@REALMwhere NetBIOSName$@REALM matches the entry in the keytab to tell SSSD to use this principal for kinit.
That did the trick!
However, I still don't understand why setting this is necessary: Shouldn't SSSD 'see' that the account ending with '$@REALM' is the only computer account in the keytab and use it for obtaining a TGT? I know that MS requires the first part of the FQDN to be equal to the NETBIOS name [0], but it still seems weird to me that SSSD apparently doesn't infer the NETBIOS name automatically.
In any case, thanks for your explanations! This thread has definitely improved my understanding so far.
-Patrice
On Mon, Feb 22, 2016 at 09:47:49PM -0000, Patrice Peterson wrote:
On Mon, Feb 22, 2016 at 08:04:42PM -0000, Patrice Peterson wrote:
Please note that the principal you give with the --user-principal option is not a SPN (service principal name) but a UPN (user principal names). Only UPNs can be used to get a Kerberos TGT, i.e. can be used with kinit.
As you can see form the logs SSSD tries to use host/fqdn(a)XD.UNI-HALLE.DE to get a TGT. Since AD handles principal case-insensitive HOST/fqdn(a)XD.UNI-HALLE.DE will work as well as long as it is defined as UPN (I would expect that it will work the same if you use '--user-principal=host/fqdn@REALM'.
Yes, I just tried that and you were right. My mental model of host authentication was apparently completely wrong—I knew computers were basically "users" in AD, but I didn't apply this knowledge to this situation…
In general the default UPN is NetBIOSName$@REALM and SSSD will use it if a matching entry is in the keytab. But there are some restrictions to the NetBIOS name, e.g. only 15 characters are allowed and only a few special characters. Do you have and entry '...$@REALM' in the keytab? Does the name before the $ match the first part of the fully qualified host name of the client or is it truncated or special characters removed?
I do have 'Netbiosname$@REALM', but I had to make it different from the first part of the FQDN (i.e. it is 'HPC-login001' while the first part of the FQDN is 'login001', without the 'HPC'). I didn't even know that this could be a problem, so thanks again for putting me on the right path!
If you have a '...$@REALM' entry in the keytab which differs somehow from the hostname you can try to add this principal to sssd.conf with
ldap_sasl_authid = NetBIOSName$@REALMwhere NetBIOSName$@REALM matches the entry in the keytab to tell SSSD to use this principal for kinit.
That did the trick!
Great, good to know that it is working for you now.
However, I still don't understand why setting this is necessary: Shouldn't SSSD 'see' that the account ending with '$@REALM' is the only computer account in the keytab and use it for obtaining a TGT? I know that MS requires the first part of the FQDN to be equal to the NETBIOS name [0], but it still seems weird to me that SSSD apparently doesn't infer the NETBIOS name automatically.
I see your point. Currently the idea is that SSSD will work if tools like adcli or 'net ads join' will be used in the default mode where the NetBIOS name is based on the first component of the FQDN. If you want to join with a different NetBIOS name you have to tell the tool and SSSD explicitly about it. But I agree that for SSSD's AD provider using a '$@REALM' principal, if there is only one, from the keytab would be a better fallback to try than the current 'home/FQDN@REALM' fallback.
Feel free to open a RFE ticket on https://fedorahosted.org/sssd/ about this.
In any case, thanks for your explanations! This thread has definitely improved my understanding so far.
Glad I could help.
bye, Sumit
-Patrice
[0] https://msdn.microsoft.com/en-us/library/cc246064.aspx _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
I'm going to reply to self here since I found out something interesting: If I join a Fedora 23 host with the new adcli (resulting in the lower-case host/ SPNs) and use my sssd.conf [0], lookups work!
I suspected the problem was fixed somewhere between SSSD versions in CentOS 7.2 (1.13.0) and Fedora 23 (1.13.3), so I had a look over the release notes, but I couldn't find anything related to my problem…
[0] https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
John Hodrien -
Lukas Slebodnik -
Mote, Todd -
Patrice Peterson -
Sumit Bose