On Wed, Jan 11, 2017 at 11:01:22AM +0100, Troels Hansen wrote:
> 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?
I guess this is because the last update on one server was done with data
from LDAP while the other used data from the Global Catalog. In general
missing data in the GC should not remove the data read from LDAP, there
is already https://fedorahosted.org/sssd/ticket/2474 to track this.
>
> 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?
We plan to allow to configure sub-domains individually in one of the
next releases, see https://fedorahosted.org/sssd/ticket/2599 .
In the meantime you might want to try id-overrides for users which have
/bin/false set as shell in AD?
HTH
bye,
Sumit
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
