Okay, I'm seeing something in my logs that points to why I'm not authenticating with pam_sss.so, and it may be unique to our environment here at HP, although I suspect others will eventually have the same situation.
The issue, I think, is that we use email addresses as part of our uid (and dn) attributes, and the '@' sign is getting interpreted as part of a Kerberos realm identifier. In /var/log/secure, for example, I'm seeing " login: pam_sss(login:auth): system info: [Cannot resolve servers for KDC in realm "HP.COM"] ", while in /var/log/sssd/krb5_child.log for the same timestamp there's "[[sssd[krb5_child[16801]]]] [get_and_save_tgt] (0x0020): 977: [-1765328164][Cannot resolve servers for KDC in realm "HP.COM"]", while /var/log/sssd/ldap_child.log shows the correct realm, "[[sssd[ldap_child[16791]]]] [unpack_buffer] (0x1000): got realm_str: AMERICAS.CPQCORP.NET" from the /etc/krb5.keytab file.
So: is there something in pam_sss.so that needs to be 'fixed' to get around this problem?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/2013 11:04 AM, Sutton, Harry (GSSE) wrote:
Okay, I'm seeing something in my logs that points to why I'm not authenticating with pam_sss.so, and it may be unique to our environment here at HP, although I suspect others will eventually have the same situation.
The issue, I think, is that we use email addresses as part of our uid (and dn) attributes, and the '@' sign is getting interpreted as part of a Kerberos realm identifier. In /var/log/secure, for example, I'm seeing " login: pam_sss(login:auth): system info: [Cannot resolve servers for KDC in realm "HP.COM"] ", while in /var/log/sssd/krb5_child.log for the same timestamp there's "[[sssd[krb5_child[16801]]]] [get_and_save_tgt] (0x0020): 977: [-1765328164][Cannot resolve servers for KDC in realm "HP.COM"]", while /var/log/sssd/ldap_child.log shows the correct realm, "[[sssd[ldap_child[16791]]]] [unpack_buffer] (0x1000): got realm_str: AMERICAS.CPQCORP.NET" from the /etc/krb5.keytab file.
So: is there something in pam_sss.so that needs to be 'fixed' to get around this problem?
You can change the domain delimiter in SSSD with the re_expression option in the [sssd] section. By default it assumes "user@DOMAIN", but you can swap it out for something else. See the sssd.conf(5) manpage and search on 're_expression'.
On 04/10/2013 11:12 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/2013 11:04 AM, Sutton, Harry (GSSE) wrote:
Okay, I'm seeing something in my logs that points to why I'm not authenticating with pam_sss.so, and it may be unique to our environment here at HP, although I suspect others will eventually have the same situation.
The issue, I think, is that we use email addresses as part of our uid (and dn) attributes, and the '@' sign is getting interpreted as part of a Kerberos realm identifier. In /var/log/secure, for example, I'm seeing " login: pam_sss(login:auth): system info: [Cannot resolve servers for KDC in realm "HP.COM"] ", while in /var/log/sssd/krb5_child.log for the same timestamp there's "[[sssd[krb5_child[16801]]]] [get_and_save_tgt] (0x0020): 977: [-1765328164][Cannot resolve servers for KDC in realm "HP.COM"]", while /var/log/sssd/ldap_child.log shows the correct realm, "[[sssd[ldap_child[16791]]]] [unpack_buffer] (0x1000): got realm_str: AMERICAS.CPQCORP.NET" from the /etc/krb5.keytab file.
So: is there something in pam_sss.so that needs to be 'fixed' to get around this problem?
You can change the domain delimiter in SSSD with the re_expression option in the [sssd] section. By default it assumes "user@DOMAIN", but you can swap it out for something else. See the sssd.conf(5) manpage and search on 're_expression'. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFlgUkACgkQeiVVYja6o6PomwCeJLoFKRVgZh7QKJdwxRJIEk6b jXUAoIKooBrskgKtN0ifdHhtXAm2N/G6 =RpR7 -----END PGP SIGNATURE-----
Thanks, Stephen - I thought I had seen something like that in the man page, but I hadn't gone back to check. I'll test it out and get back to the list.
/HArry
On 04/10/2013 11:12 AM, Stephen Gallagher wrote:
You can change the domain delimiter in SSSD with the re_expression option in the [sssd] section. By default it assumes "user@DOMAIN", but you can swap it out for something else. See the sssd.conf(5) manpage and search on 're_expression'.
Okay, I think I still have the problem, in that the delimiter in both instances is the '@' sign. Even when I manually specify the domain portion (e.g., "re_expression = (?P<name>[^@]+)@AMERICAS.CPQCORP.NET") it continues to flag [Cannot resolve servers for KDC in realm "HP.COM"] in /var/log/secure. And although ldap_child.log references the correct domain (via the keytab file), krb5_child.log continues to show "Attempting kinit for realm [HP.COM].
I'm probably either missing the point of your suggestion, Stephen, or (just as likely) exposing my limited knowledge of regular expressions.
/Harry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed 10 Apr 2013 01:04:03 PM EDT, Sutton, Harry (GSSE) wrote:
On 04/10/2013 11:12 AM, Stephen Gallagher wrote:
You can change the domain delimiter in SSSD with the re_expression option in the [sssd] section. By default it assumes "user@DOMAIN", but you can swap it out for something else. See the sssd.conf(5) manpage and search on 're_expression'.
Okay, I think I still have the problem, in that the delimiter in both instances is the '@' sign. Even when I manually specify the domain portion (e.g., "re_expression = (?P<name>[^@]+)@AMERICAS.CPQCORP.NET") it continues to flag [Cannot resolve servers for KDC in realm "HP.COM"] in /var/log/secure. And although ldap_child.log references the correct domain (via the keytab file), krb5_child.log continues to show "Attempting kinit for realm [HP.COM].
I'm probably either missing the point of your suggestion, Stephen, or (just as likely) exposing my limited knowledge of regular expressions.
Yes, the regular expression syntax is complex. I'm not certain I understand all of the intricacies myself. I'm CCing Jakub Hrozek who can probably help more.
On Wed, Apr 10, 2013 at 01:04:03PM -0400, Sutton, Harry (GSSE) wrote:
On 04/10/2013 11:12 AM, Stephen Gallagher wrote:
You can change the domain delimiter in SSSD with the re_expression option in the [sssd] section. By default it assumes "user@DOMAIN", but you can swap it out for something else. See the sssd.conf(5) manpage and search on 're_expression'.
Okay, I think I still have the problem, in that the delimiter in both instances is the '@' sign. Even when I manually specify the domain portion (e.g., "re_expression = (?P<name>[^@]+)@AMERICAS.CPQCORP.NET") it continues to flag [Cannot resolve servers for KDC in realm "HP.COM"] in /var/log/secure. And although ldap_child.log references the correct domain (via the keytab file), krb5_child.log continues to show "Attempting kinit for realm [HP.COM].
I guess it is related to the content of the userPrincipalName in AD. The @HP.COM will be listed here. SSSD prefers the content of this attribute to generating the Kerberos principal based on the user and the realm name. But with AD it is a bit more difficult because the names listed in the attribute can have suffixes which are different from the Kerberos realm, making it difficult for the Linux client to find the right KDC.
As a short cut you can just set
ldap_user_principal = SomeAttributeNameThatDoesNotExists
in the domain section of sssd.conf. Then sssd cannot find a Kerberos principal on the server and build one based on the name and the realm. To be on the safe side you can add krb5_realm = AMERICAS.CPQCORP.NET to sssd.conf (if you not already have it).
The correct solution is https://fedorahosted.org/sssd/ticket/1842 where I'm current running some final tests before I send the patch to sssd-devel. So hopefully in the next sssd release you do not need the fix mentioned above.
HTH
bye, Sumit
I'm probably either missing the point of your suggestion, Stephen, or (just as likely) exposing my limited knowledge of regular expressions.
/Harry
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 04/10/2013 03:32 PM, Sumit Bose wrote:
I guess it is related to the content of the userPrincipalName in AD. The @HP.COM will be listed here. SSSD prefers the content of this attribute to generating the Kerberos principal based on the user and the realm name. But with AD it is a bit more difficult because the names listed in the attribute can have suffixes which are different from the Kerberos realm, making it difficult for the Linux client to find the right KDC.
As a short cut you can just set
ldap_user_principal = SomeAttributeNameThatDoesNotExists
in the domain section of sssd.conf. Then sssd cannot find a Kerberos principal on the server and build one based on the name and the realm. To be on the safe side you can add krb5_realm = AMERICAS.CPQCORP.NET to sssd.conf (if you not already have it).
The correct solution is https://fedorahosted.org/sssd/ticket/1842 where I'm current running some final tests before I send the patch to sssd-devel. So hopefully in the next sssd release you do not need the fix mentioned above.
HTH
bye, Sumit
That did the trick, Sumit - thanks a million. For the first time, I have sssd logins working directly.
Very nice, thanks again.
/Harry
sssd-users@lists.fedorahosted.org
-
Stephen Gallagher -
Sumit Bose -
Sutton, Harry (GSSE)