SSSD cache and shadow problem

Silencer0815 · #1 31st August 2010, 12:22 PM

Hi,

I have some problems with sssd. I set up some Fedora 13 machines and want to use ldap authentication.
This was set up with the command:
authconfig --useshadow --enablemd5 --enableldap --enableldapauth --ldapserver "xxx" --ldapbasedn "dc=xxx" --disablesysnetauth --disablecache --enablelocauthorize --update

That's working, basically, which means, I can log into the machines with the ldap credentials.
But: If for example I add an user to another group in the ldap database and log out and in again on the machines, the user there is not member of that group! So, somehow sssd seems to not refresh the local cache. This is also the case, if I shutdown the machines and startup again, even if there is a whole day between (I can't imagine that there is such a long refresh timeout set anywhere).

Another problem:
I also have shadow entries in the ldap database, e. g. for expiring accounts. But they seem to be ignored on the Fedora machines. Well, maybe this is also related to the above problem. I added the shadow entries afterwards, so if the machines just use their local caches, they also won't get the shadow entries.

Has someone had similar experiencies? I would really like to do this the usual way for setting things up, using authconfig, and not manually changing any config files.

See my config files at the bottom. Unfortunately in the sssd logfiles there isn't something usefull.

Cheers!

/etc/sssd/sssd.conf

PHP Code:


			
[sssd]

config_file_version = 2



sbus_timeout = 30

services = nss, pam



domains = default



[nss]

filter_groups = root

filter_users = root

reconnection_retries = 3



[pam]

reconnection_retries = 3



[domain/default]

cache_credentials = True

ldap_search_base = dc=xxx

krb5_realm = EXAMPLE.COM

chpass_provider = ldap

id_provider = ldap

auth_provider = ldap

debug_level = 0

ldap_uri = xxx

krb5_kdcip = kerberos.example.com

ldap_tls_cacertdir = /etc/openldap/cacerts

/etc/nsswitch.conf

PHP Code:


			
passwd:     files sss

shadow:     files sss

group:      files sss



hosts:      files mdns4_minimal [NOTFOUND=return] dns   



bootparams: nisplus [NOTFOUND=return] files



ethers:     files

netmasks:   files

networks:   files

protocols:  files

rpc:        files

services:   files



netgroup:   files ldap



publickey:  nisplus



automount:  files ldap

aliases:    files nisplus

---------- Post added at 01:22 PM CDT ---------- Previous post was at 11:32 AM CDT ----------

Another question: To make it easy... can I somehow disable sssd on Fedora 13 completely?
I tried authconfig .... --disablesssd --disablesssdauth but still sssd is used (instead of using ldap directly)

Cheers!

sgallagh · #2 31st August 2010, 12:37 PM

Quote:

Originally Posted by Silencer0815

That's working, basically, which means, I can log into the machines with the ldap credentials.
But: If for example I add an user to another group in the ldap database and log out and in again on the machines, the user there is not member of that group! So, somehow sssd seems to not refresh the local cache. This is also the case, if I shutdown the machines and startup again, even if there is a whole day between (I can't imagine that there is such a long refresh timeout set anywhere).

Please file a bug at bugzilla.redhat.com against sssd. This is not expected behavior.

Quote:

Originally Posted by Silencer0815

Another problem:
I also have shadow entries in the ldap database, e. g. for expiring accounts. But they seem to be ignored on the Fedora machines. Well, maybe this is also related to the above problem. I added the shadow entries afterwards, so if the machines just use their local caches, they also won't get the shadow entries.

Has someone had similar experiencies? I would really like to do this the usual way for setting things up, using authconfig, and not manually changing any config files.

Unfortunately, setting up password policy notifications is not a standard feature of authconfig. It's an advanced configuration setting and requires modifying the sssd.conf. You need to add the option ldap_pwd_policy = shadow as shown below:

PHP Code:


			
[sssd]

config_file_version = 2



sbus_timeout = 30

services = nss, pam



domains = default



[nss]

filter_groups = root

filter_users = root

reconnection_retries = 3



[pam]

reconnection_retries = 3



[domain/default]

cache_credentials = True

ldap_search_base = dc=xxx

krb5_realm = EXAMPLE.COM

chpass_provider = ldap

id_provider = ldap

auth_provider = ldap

debug_level = 0

ldap_uri = xxx

krb5_kdcip = kerberos.example.com

ldap_tls_cacertdir = /etc/openldap/cacerts

ldap_pwd_policy = shadow

This means that the shadow attributes other than the password must be readable by the user attempting to authenticate. These attributes are (by default):

shadowLastChange
shadowMin
shadowMax
shadowWarning
shadowInactive
shadowExpire

If your LDAP schema uses a different attribute for these entries, they can be customized with:

ldap_user_shadow_last_change
ldap_user_shadow_min
ldap_user_shadow_max
ldap_user_shadow_warning
ldap_user_shadow_inactive
ldap_user_shadow_expire

in the domain section of sssd.conf

Silencer0815 · #3 31st August 2010, 01:28 PM

Thanks, shadow is working now!
This helped:

Quote:

ldap_pwd_policy = shadow

But I was wrong with my suspicion that sssd does not update the cache. If I change for example a user's gecos field, log out and in again, finger shows the changed information. But this does not happen with the group information.
The groups are organized as "groups" in the ldap database. I set this up via the LDAP Account Manager. Could there be a problem? Maybe something not standard compliant as sssd would expect it?
Here's my groups definition from the ldap database.

Code:

dn: ou=groups,dc=csb
objectClass: organizationalUnit
ou: groups
structuralObjectClass: organizationalUnit
entryUUID: 20b8fde2-2925-102f-8e2d-39e23cac14d2
creatorsName: cn=Manager,dc=csb
createTimestamp: 20100721150521Z
entryCSN: 20100721150521Z#000003#00#000000
modifiersName: cn=Manager,dc=csb
modifyTimestamp: 20100721150521Z

Btw, if I change sss to ldap in the /etc/nsswitch.conf it works as expected. But as I said, if possible I'd like to avoid manually changing config files.

Thank you very much so far!

sgallagh · #4 31st August 2010, 02:40 PM

Quote:

Originally Posted by Silencer0815

But I was wrong with my suspicion that sssd does not update the cache. If I change for example a user's gecos field, log out and in again, finger shows the changed information. But this does not happen with the group information.
The groups are organized as "groups" in the ldap database. I set this up via the LDAP Account Manager. Could there be a problem? Maybe something not standard compliant as sssd would expect it?
Here's my groups definition from the ldap database.

As I said, please file a bug in Bugzilla. I suspect that there's a glitch in the code I recently wrote to speed up user logins. Previously, we were doing a slow lookup of every group that the user was a member of and adding it to the cache. This was causing very long delays through the login process, so I changed it so that we would only add the user to groups in the cache instead of looking the groups up. Given your explanation, I now suspect that I may have forgotten to also create new groups if this user is the first member of them that we've seen.

As a workaround in the meantime, you can add the option
enumerate = true
to the domain section of your sssd.conf. This will perform a one-time full lookup of all users and groups on the LDAP server and cache them (then check for changes regularly after that). This will guarantee that all of your groups are correct.

Silencer0815 · #5 31st August 2010, 03:02 PM

Thanks again!

The workaround enumerate = true seems to work.

Ok, I'll try to get it running on all machines with this workaround, then I'll file a bug report!