[Freeipa-users] Different cache on 2 IPA servers

[Troels Hansen]

Hi, we have just seen a weird issue, which I need some advice on. 

We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients connected. 

A little story of what we experienced. 
We had a AD user which sometimes couldn't log in to a server, because his shell was being set to /bin/false by SSSD. 

"sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and restarting SSSD sometimes led to the users having a correct shell set, but still, after some hours most likely having his shell being set back to /bin/false. 

We discovered that when the clients was connected to one IPA server the shell was set to /bin/false and when connected to the other, the shell from SSSD, default_shell was set. 

This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA serveres, and there we discovered that on one server a loginShell was set whilst it wasn't on the other. 

ldapsearch the user on the AD servers had the loginShell: /bin/false 

However, one IPA server still had an idea that loginShell wasn't set. 

sss_cache -E on the IPA server correcthe the issue. 

This attribute have been on the user for ages, so do anyone have any idea of how this can happen? 

sssd config and everything about the serveres are the same. Also, SSSD cache config.ldb contained the same values on both servers. 


Second question. The reason for the loginshell being set on some users is that they used to be 
Hi, we have just seen a weird issue, which I need some advice on. 

We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients connected. 

A little story of what we experienced. 
We had a AD user which sometimes couldn't log in to a server, because his shell was being set to /bin/false by SSSD. 

"sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and restarting SSSD sometimes led to the users having a correct shell set, but still, after some hours most likely having his shell being set back to /bin/false. 

We discovered that when the clients was connected to one IPA server the shell was set to /bin/false and when connected to the other, the shell from SSSD, default_shell was set. 

This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA serveres, and there we discovered that on one server a loginShell was set whilst it wasn't on the other. 

ldapsearch the user on the AD servers had the loginShell: /bin/false 

However, one IPA server still had an idea that loginShell wasn't set. 

sss_cache -E on the IPA server correcthe the issue. 

This attribute have been on the user for ages, so do anyone have any idea of how this can happen? 

So, the actual error was that the user was actually allowed to log in but as we discovered the actual reason, the question is, why the cache isn't updated and contains different content on the IPA servers. 

sssd config and everything about the serveres are the same. Also, SSSD cache config.ldb contained the same values on both servers. 


Second question. The reason for the loginshell being set on some users is that they used to be QAU, which enabled the UNIX attributes on the user, and disabling the user in QAS sets the shell to /bin/false. 
So, what we would really like is to override if a user have a shell in AD, by setting "ldap_user_shell = something-false" on the IPA servers, but this isn't inherited to sub-domains? 

Can disabling shell's be accomplished somehow else? 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170111/ec2ea62f/attachment.htm>