On 04/11/2013 10:59 AM, Simo Sorce wrote:
On Thu, 2013-04-11 at 10:22 -0400, Sutton, Harry (GSSE) wrote:
> On 04/11/2013 09:55 AM, Simo Sorce wrote:
>> Because the PAM stack is completely separate from the NSS stack,
>> although we suggest people to not do this normally you can use an option
>> in nsswitch.conf to avoid falling through NSS modules during the
>> initgroups call to avoid paying the penalty for local users.
>> The option is called 'initgroupss', where you can list files and sss as
>> Note that we normally *do not* recommend this option, here is a
>> discussion of the why:
> Thanks, that works as a workaround. If I can get an answer to my earlier
> question about sss_aduser in a LOCAL domain I'll consider migrating
> completely to sssd for local and domain logins, at which point I can
> remove this modification to nsswitch.
Okay, so I think my response was
premature; it turns out that I had
disabled sssd temporarily, and that's why it appeared that making this
change had removed the undesirable behavior.
But when I re-enabled the sssd daemon, the time delay in logins
returned. And further reading of the bug you referenced still leaves me
uncertain as to why this feature would be causing delayed local logins,
primarily because the local user account and network user account are
mutually exclusive: there is no network user account named 'sutton'
(verified after joining the domain with 'getent passwd sutton') and
there is no local user account named 'suttonh'.
The local (sutton) user is, by long-standing Red Hat tradition, the only
member of the group 'sutton', while the network (suttonh) user is a
member of the 'domain users' group. So if the initgroups line in
nsswitch has 'files' as the first choice, and the group 'sutton' exists
in the local /etc/group file, why isn't it succeeding promptly?