SSSD and Kerberos

[Alexander Blair]

Hello,

I've been working with FC 16 and SSSD for about two days now trying to 
get SSSD to properly talk to our Kerberos server, and it seems to 
continually ignore the fact I've got it configured to do so at this 
time.  Tracking the logs has shown me nothing useful as of yet, and 
monitoring network traffic on the Krb server itself shows that there's 
no network communication happening.

I've even gone as far as to completely purge the working directory for 
it's caches, and force them to rebuild, restarting the box, nothing I've 
done so far seems to force SSSD to contact Krb for auth information, any 
ideas on where to take this would be most excellent.

I'm currently using SSSD 1.6.3 from the main FC repos.  I've gone though 
as much troubleshooting information as I can, but as there does not 
appear to be any errors in my krb5_child.log log, or much else that 
appears to be useful, so I'm a bit stumped.

/etc/sssd/sssd.conf:
[domain/domain]

ldap_id_use_start_tls = False
cache_credentials = True
ldap_search_base = dc=dc,dc=dc,dc=dc
krb5_realm = this.is.a.valid.realm
krb5_server = 192.168.100.100
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
ldap_uri = ldap://192.168.100.200/
krb5_kpasswd = 192.168.100.100
ldap_tls_cacertdir = /etc/openldap/cacerts

[sssd]
services = nss, pam
config_file_version = 2

domains = domain
[nss]

[pam]

/var/log/sssd/sssd_nss.log -- Debug level 4:
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [accept_fd_handler] (4): Client 
connected!
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): 
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): 
Requesting info for [user@default]
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups] (4): 
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups_search] (4): 
Requesting info for [user@default]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): 
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): 
Requesting info for [user@default]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): 
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): 
Requesting info for [user@default]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): 
Requesting info for [user] from [<ALL>]
(Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): 
Requesting info for [user@default]

Thank you,
Alexander Blair

[Stephen Gallagher]

On Dec 30, 2011, at 3:07 AM, Alexander Blair  wrote:
> Hello,
>
> I've been working with FC 16 and SSSD for about two days now trying to get SSSD to properly talk to our Kerberos server, and it seems to continually ignore the fact I've got it configured to do so at this time.  Tracking the logs has shown me nothing useful as of yet, and monitoring network traffic on the Krb server itself shows that there's no network communication happening.
>
> I've even gone as far as to completely purge the working directory for it's caches, and force them to rebuild, restarting the box, nothing I've done so far seems to force SSSD to contact Krb for auth information, any ideas on where to take this would be most excellent.
>
> I'm currently using SSSD 1.6.3 from the main FC repos.  I've gone though as much troubleshooting information as I can, but as there does not appear to be any errors in my krb5_child.log log, or much else that appears to be useful, so I'm a bit stumped.
>
> /etc/sssd/sssd.conf:
> [domain/domain]
>
> ldap_id_use_start_tls = False
> cache_credentials = True
> ldap_search_base = dc=dc,dc=dc,dc=dc
> krb5_realm = this.is.a.valid.realm
> krb5_server = 192.168.100.100
> id_provider = ldap
> auth_provider = krb5
> chpass_provider = krb5
> ldap_uri = ldap://192.168.100.200/
> krb5_kpasswd = 192.168.100.100
> ldap_tls_cacertdir = /etc/openldap/cacerts

Try dropping the trailing slash from the ldap_uri. I'm not sure if we properly trim that offhand. (I'm responding to this from vacation, so I don't have the source handy).

Can you confirm that 'getent passwd user' (where user is a valid LDAP username) returns the expected information?

The way SSSD works is that it will only use the auth_provider for authentication if the user is found in the matching id_provider. This prevents information leaks by sending passwords to unrelated servers. So the first step is to ensure that the user is found in LDAP.
> [sssd]
> services = nss, pam
> config_file_version = 2
>
> domains = domain
> [nss]
>
> [pam]
>
> /var/log/sssd/sssd_nss.log -- Debug level 4:
> (Fri Dec 30 01:46:35 2011) [sssd[nss]] [accept_fd_handler] (4): Client connected!
> (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
> (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups] (4): Requesting info for [user] from [<ALL>]
> (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups_search] (4): Requesting info for [user@default]
> (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
> (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
> (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
>
> Thank you,
> Alexander Blair
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Alexander Blair]

Hello,

I got a chance to work on this/look into this, and getent passwd user is 
returning the expected results with sssd on, and nothing with sssd off, 
as should be expected.  The addition or removal of the / on the ldap URL 
had no results on my testing.

I tacked strace's onto the various processes as I was authenticating, 
and verified that it did contact the ldap server, and was able to get 
all the ldap related data.  I have also verified that the server can 
contact the Kerberos server at this time via kinit after a su <user> -, 
where <user> is a user that only exists in the ldap directory, so it 
appears that it's something with SSSD not properly contacting the Krb 
server, I'm unable to track exactly how it should be doing this, so any 
suggestions would be appreciated, and I'm happy to provide any 
additional information I can about our setup related to this.

Thank you,
Alexander Blair

On 12/31/2011 07:14 AM, Stephen Gallagher wrote:
> On Dec 30, 2011, at 3:07 AM, Alexander Blair  wrote:
> > Hello,
> >
> > I've been working with FC 16 and SSSD for about two days now trying to get SSSD to properly talk to our Kerberos server, and it seems to continually ignore the fact I've got it configured to do so at this time.  Tracking the logs has shown me nothing useful as of yet, and monitoring network traffic on the Krb server itself shows that there's no network communication happening.
> >
> > I've even gone as far as to completely purge the working directory for it's caches, and force them to rebuild, restarting the box, nothing I've done so far seems to force SSSD to contact Krb for auth information, any ideas on where to take this would be most excellent.
> >
> > I'm currently using SSSD 1.6.3 from the main FC repos.  I've gone though as much troubleshooting information as I can, but as there does not appear to be any errors in my krb5_child.log log, or much else that appears to be useful, so I'm a bit stumped.
> >
> > /etc/sssd/sssd.conf:
> > [domain/domain]
> >
> > ldap_id_use_start_tls = False
> > cache_credentials = True
> > ldap_search_base = dc=dc,dc=dc,dc=dc
> > krb5_realm = this.is.a.valid.realm
> > krb5_server = 192.168.100.100
> > id_provider = ldap
> > auth_provider = krb5
> > chpass_provider = krb5
> > ldap_uri = ldap://192.168.100.200/
> > krb5_kpasswd = 192.168.100.100
> > ldap_tls_cacertdir = /etc/openldap/cacerts
>
> Try dropping the trailing slash from the ldap_uri. I'm not sure if we properly trim that offhand. (I'm responding to this from vacation, so I don't have the source handy).
>
> Can you confirm that 'getent passwd user' (where user is a valid LDAP username) returns the expected information?
>
> The way SSSD works is that it will only use the auth_provider for authentication if the user is found in the matching id_provider. This prevents information leaks by sending passwords to unrelated servers. So the first step is to ensure that the user is found in LDAP.
> > [sssd]
> > services = nss, pam
> > config_file_version = 2
> >
> > domains = domain
> > [nss]
> >
> > [pam]
> >
> > /var/log/sssd/sssd_nss.log -- Debug level 4:
> > (Fri Dec 30 01:46:35 2011) [sssd[nss]] [accept_fd_handler] (4): Client connected!
> > (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> > (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
> > (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups] (4): Requesting info for [user] from [<ALL>]
> > (Fri Dec 30 01:46:35 2011) [sssd[nss]] [nss_cmd_initgroups_search] (4): Requesting info for [user@default]
> > (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> > (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
> > (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> > (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
> > (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [user] from [<ALL>]
> > (Fri Dec 30 01:46:37 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [user@default]
> >
> > Thank you,
> > Alexander Blair
> > _______________________________________________
> > sssd-devel mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Jakub Hrozek]

On Tue, Jan 03, 2012 at 01:13:53AM -0600, Alexander Blair wrote:
> Hello,
>
> I got a chance to work on this/look into this, and getent passwd
> user is returning the expected results with sssd on, and nothing
> with sssd off, as should be expected.  The addition or removal of
> the / on the ldap URL had no results on my testing.
>
> I tacked strace's onto the various processes as I was
> authenticating, and verified that it did contact the ldap server,
> and was able to get all the ldap related data.  I have also verified
> that the server can contact the Kerberos server at this time via
> kinit after a su <user> -, where <user> is a user that only exists
> in the ldap directory, so it appears that it's something with SSSD
> not properly contacting the Krb server, I'm unable to track exactly
> how it should be doing this, so any suggestions would be
> appreciated, and I'm happy to provide any additional information I
> can about our setup related to this.
>
> Thank you,
> Alexander Blair

How did you configure your PAM stack? Usin authconfig or manually? Does
/var/log/secure show any errors related to pam_sss (and does it show
that pam_sss was consulted?)

You can also try setting debug_level = 10 in the [domain/domainname]
section of sssd.conf, restarting sssd and checking for any Kerberos errors.

[Alexander Blair]

On 01/03/2012 04:07 AM, Jakub Hrozek wrote:
> On Tue, Jan 03, 2012 at 01:13:53AM -0600, Alexander Blair wrote:
> > Hello,
> >
> > I got a chance to work on this/look into this, and getent passwd
> > user is returning the expected results with sssd on, and nothing
> > with sssd off, as should be expected.  The addition or removal of
> > the / on the ldap URL had no results on my testing.
> >
> > I tacked strace's onto the various processes as I was
> > authenticating, and verified that it did contact the ldap server,
> > and was able to get all the ldap related data.  I have also verified
> > that the server can contact the Kerberos server at this time via
> > kinit after a su<user>  -, where<user>  is a user that only exists
> > in the ldap directory, so it appears that it's something with SSSD
> > not properly contacting the Krb server, I'm unable to track exactly
> > how it should be doing this, so any suggestions would be
> > appreciated, and I'm happy to provide any additional information I
> > can about our setup related to this.
> >
> > Thank you,
> > Alexander Blair
>
> How did you configure your PAM stack? Usin authconfig or manually? Does
> /var/log/secure show any errors related to pam_sss (and does it show
> that pam_sss was consulted?)
>
> You can also try setting debug_level = 10 in the [domain/domainname]
> section of sssd.conf, restarting sssd and checking for any Kerberos errors.
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

The PAM stack was originally done in authconfig, and I have verfied that 
it's properly setup to allow SSSD to auth.  I have monitored the SSSD 
processes directly and have confirmed that PAM is contacting it for 
authentication verification.

Setting it into debug 10 has done nothing, as it's not dropping anything 
into the krb log files.

[Jakub Hrozek]

On Tue, Jan 03, 2012 at 07:23:46PM -0600, Alexander Blair wrote:
> On 01/03/2012 04:07 AM, Jakub Hrozek wrote:
> > On Tue, Jan 03, 2012 at 01:13:53AM -0600, Alexander Blair wrote:
> > > Hello,
> > >
> > > I got a chance to work on this/look into this, and getent passwd
> > > user is returning the expected results with sssd on, and nothing
> > > with sssd off, as should be expected.  The addition or removal of
> > > the / on the ldap URL had no results on my testing.
> > >
> > > I tacked strace's onto the various processes as I was
> > > authenticating, and verified that it did contact the ldap server,
> > > and was able to get all the ldap related data.  I have also verified
> > > that the server can contact the Kerberos server at this time via
> > > kinit after a su<user>  -, where<user>  is a user that only exists
> > > in the ldap directory, so it appears that it's something with SSSD
> > > not properly contacting the Krb server, I'm unable to track exactly
> > > how it should be doing this, so any suggestions would be
> > > appreciated, and I'm happy to provide any additional information I
> > > can about our setup related to this.
> > >
> > > Thank you,
> > > Alexander Blair
> >
> > How did you configure your PAM stack? Usin authconfig or manually? Does
> > /var/log/secure show any errors related to pam_sss (and does it show
> > that pam_sss was consulted?)
> >
> > You can also try setting debug_level = 10 in the [domain/domainname]
> > section of sssd.conf, restarting sssd and checking for any Kerberos errors.
> > _______________________________________________
> > sssd-devel mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> The PAM stack was originally done in authconfig, and I have verfied
> that it's properly setup to allow SSSD to auth.  I have monitored
> the SSSD processes directly and have confirmed that PAM is
> contacting it for authentication verification.
>
> Setting it into debug 10 has done nothing, as it's not dropping
> anything into the krb log files.

Sorry, I wasn't clear enough. The debug logs should show up in
/var/log/sssd/sssd_domainname.log Also /var/log/sssd/krb5_child.log
might of interest because that's where the process that actually gets
the TGT logs into.

[Alexander Blair]

On 01/03/2012 07:23 PM, Alexander Blair wrote:
> On 01/03/2012 04:07 AM, Jakub Hrozek wrote:
> > On Tue, Jan 03, 2012 at 01:13:53AM -0600, Alexander Blair wrote:
> > > Hello,
> > >
> > > I got a chance to work on this/look into this, and getent passwd
> > > user is returning the expected results with sssd on, and nothing
> > > with sssd off, as should be expected.  The addition or removal of
> > > the / on the ldap URL had no results on my testing.
> > >
> > > I tacked strace's onto the various processes as I was
> > > authenticating, and verified that it did contact the ldap server,
> > > and was able to get all the ldap related data.  I have also verified
> > > that the server can contact the Kerberos server at this time via
> > > kinit after a su<user>  -, where<user>  is a user that only exists
> > > in the ldap directory, so it appears that it's something with SSSD
> > > not properly contacting the Krb server, I'm unable to track exactly
> > > how it should be doing this, so any suggestions would be
> > > appreciated, and I'm happy to provide any additional information I
> > > can about our setup related to this.
> > >
> > > Thank you,
> > > Alexander Blair
> >
> > How did you configure your PAM stack? Usin authconfig or manually? Does
> > /var/log/secure show any errors related to pam_sss (and does it show
> > that pam_sss was consulted?)
> >
> > You can also try setting debug_level = 10 in the [domain/domainname]
> > section of sssd.conf, restarting sssd and checking for any Kerberos 
> > errors.
> > _______________________________________________
> > sssd-devel mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> The PAM stack was originally done in authconfig, and I have verfied 
> that it's properly setup to allow SSSD to auth.  I have monitored the 
> SSSD processes directly and have confirmed that PAM is contacting it 
> for authentication verification.
>
> Setting it into debug 10 has done nothing, as it's not dropping 
> anything into the krb log files.
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

Hello,

Just wanted to note that I cleared this up.  It turns out that the 
hostname that was in use, while it resolved properly for the box itself, 
SSSD was unable to resolve this properly, along with an error in the pam 
setup, requiring UID's over 1k, was causing the KRB systems to not 
trigger the auth, but no particular errors to this extent were filed, 
just tracking it back worked.

Sorry for the inconvenience,
Alexander Blair

[Stephen Gallagher]

On Tue, 2012-01-10 at 17:49 -0600, Alexander Blair wrote:
> Hello,
>
> Just wanted to note that I cleared this up.  It turns out that the 
> hostname that was in use, while it resolved properly for the box itself, 
> SSSD was unable to resolve this properly, along with an error in the pam 
> setup, requiring UID's over 1k, was causing the KRB systems to not 
> trigger the auth, but no particular errors to this extent were filed, 
> just tracking it back worked.
>
> Sorry for the inconvenience,

Thanks for letting us know that you sorted it out.