On 04/11/2013 08:44 AM, Stephen Gallagher wrote:

You shouldn't be seeing any delays at all for the local user during login, unless the initgroups() call for that user is taking a long time. The PAM stack should not be getting to pam_sss.so at all if it's properly configured. What version of SSSD are you running, on what distro? If it's Fedora/RHEL based, can I see /etc/pam.d/password-auth?

That thought had occurred to me (pam stack hierarchy).

I'm experimenting with this on two systems. On my Fedora 18 laptop, I'm running sssd-1.9.4-7.fc18; on my RHEL 6.4 workstation, it's sssd-1.9.2-82.4.el6_4. The password-auth file is identical on both systems with the exception of two lines:

Fedora:

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid>= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so

account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid< 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so

password requisite pam_pwquality.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so

session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so

RHEL 6.4

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid>= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so

account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid< 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so

session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so

Also, try the following experiment:

time id -G<localuser>

and show me the output.

On the Fedora laptop:

real 0m58.014s user 0m0.001s sys 0m0.007s

On the RHEL workstation:

real 0m58.012s user 0m0.001s sys 0m0.001s

/Harry

On 04/11/2013 09:10 AM, Stephen Gallagher wrote:

Ok, that definitely is showing where the problem lies. This strongly suggests to me that you have a user in your LDAP with the same name as on your local system. What's most likely happening is that the initgroups() call internally is walking through and processing all of the potential groups that username belongs to.

Can you check whether getent -s sss passwd<localuser>

Returns anything? If it does, you have an overlap and should probably resolve it on one side or the other.

Hmm, that command returns nothing on either system. And it still leaves the question of why pam_unix.so isn't catching the local account before pam_sss.so is invoked at all.

/Harry

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 databases.

Note that we normally *do not* recommend this option, here is a discussion of the why: https://bugzilla.redhat.com/show_bug.cgi?id=835612

Simo.

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.

/Harry

On 04/11/2013 10:45 AM, Jakub Hrozek wrote:

Can you remind me what that problem was? Were you getting some kind of transaction error?

Can you run the tool with: sss_useradd --debug-level 10 ?

That switch doesn't appear to exist on either of my systems (--debug-level for sss_useradd); running it on my Fedora 18 laptop to create a currently non-existing user returns "Transaction error. Could not add user."

Running it on my RHEL 6.4 workstation without any switches generated an error but I was able to complete it by specifying all the individual parameters (barring a grumble about my legacy choice of 500 as my uid - it preferred 1001, which I use for another manually created group.) Having done so, though, I don't see any advantage to using that over the local user. I appreciate that it's useful for testing purposes but if there are other advantages to having it they're eluding me (not unusual by any means ;-) ).

/Harry

On 04/11/2013 10:59 AM, Simo Sorce wrote:

Any reason why you need a local user at all ? (Just curious)

Simo.

This is mostly an artifact of having a different domain username (suttonh) than my Linux username (sutton). My last name felt a much more natural account name to use and I did so from the beginning of my Linux desktop use (now 14 years ago, hard to believe.) So it's largely intertia / force of habit that prevents me from migrating to a centralized account, but it's also experience, often painful, that makes me cautious about making what feels like a major change in how I've come to manage my computing environment.

An interim step for me would seem to be creating a LOCAL domain and moving my local (sutton) account into the sssd database / hierarchy.

/Harry

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sat 13 Apr 2013 04:18:25 PM EDT, Harry Sutton wrote:

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 databases.

Note that we normally *do not* recommend this option, here is a discussion of the why: https://bugzilla.redhat.com/show_bug.cgi?id=835612

Simo.

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?

The reason it doesn't succeed promptly is because initgroups() is meant to return the complete list of any group that the user belongs to. Just because the user is local, that does not mean that he cannot belong to network groups. (A classic example of this is companies keeping a 'dbusers' group stored in LDAP that references a user like 'oracle' that is created and maintained locally on each system).

The classic behavior of initgroups() is to try each and every database provided at the groups: line in nsswitch in order to determine if this user is a member of any groups in that database.

On recent Fedora systems, glibc has added a new syntax to allow you to add an initgroups: line in nsswitch.conf and specify that you want initgroups() to stop at the first match instead of trying all results. This feature is not present on Fedora prior to 17 or any shipping version of Red Hat Enterprise Linux. Also note: In Fedora 18 and later, glibc changed this to be the default behavior if the initgroups: line is unspecified, but this was a backwards-incompatible change, so authconfig is supposed to be reverting it to the classic behavior when it is used.