Credentials not restored from cache after auksd restart

[robberteggermont]

I just noticed that after a restart of auksd it does not correctly restore the credentials from /var/cache/auks in it's library. I'm having a hard time interpreting the log (auksd.log).

We're running the master branch. Any ideas/suggestions?

[hautreux]

During startup, the auksd daemon reads the content of the auks cache directory to load its internal cache of credentials.

To do that it iterates over all the auks_%id% files and

• extract the content of the file
• build a kerberos credential structure using the content
• get the local username associated to the kerberos principal (krb5_aname_to_localname)
• finish creating the "auks_cred" using the user and cred attributes (uid, gid, start/end times, ...)
• add the "auks_cred" to the internal hash table (xlibrary) using the uid as the key

From the log extract, it seems that all the files end up using the same key/uid when they are added to the hash table at startup. It sounds like the krb5_aname_to_localname function maps all the principal to the same local user, the one that is mapped to uid 408. That is strange. I have never seen that.

Are you using a flat /etc/passwd file or something like LDAP ?

Could you check your krb5.conf auth_to_local configuration as well as the nsswitch.conf and associated user/group configurations to see if everything is correct ? Are you using sssd with a particular krb5 configuration.

It may be a bug in auks, maybe in pwent management, but I am definitely not sure at that point.

[robberteggermont]

We use an Active Directory via SSSD. All seems to be working normally (usually).

Uid 408 is a local user, and certainly not related in any way to any of these credentials...

Luckily the problem went away as suddenly as it came (restarting auksd a day later all credentials were restored normally). But I'm unable to further diagnose at this moment.