Re: [SSSD-users] Local account logins
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? /Harry ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
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. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid= 1000 quiet_success authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so broken_shadow account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_pwquality.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired 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. authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid= 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so broken_shadow account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired 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 -Glocaluser and show me the output. On the Fedora laptop: real0m58.014s user 0m0.001s sys 0m0.007s On the RHEL workstation: real0m58.012s user0m0.001s sys 0m0.001s /Harry smime.p7s Description: S/MIME Cryptographic Signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/11/2013 09:03 AM, Sutton, Harry (GSSE) wrote: On 04/11/2013 08:44 AM, Stephen Gallagher wrote: Also, try the following experiment: time id -G localuser and show me the output. On the Fedora laptop: real0m58.014s user 0m0.001s sys 0m0.007s On the RHEL workstation: real0m58.012s user0m0.001s sys 0m0.001s 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFmtjYACgkQeiVVYja6o6Ng4ACgr/s1SoT0o3g2DhMJhKtPCI1A xWQAnjSVCcBdbJBfOD3U8A0OgE8/Hlad =WbvW -END PGP SIGNATURE- ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
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 passwdlocaluser 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 smime.p7s Description: S/MIME Cryptographic Signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
On Thu, 2013-04-11 at 09:44 -0400, Sutton, Harry (GSSE) wrote: 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 passwdlocaluser 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. 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. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
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 smime.p7s Description: S/MIME Cryptographic Signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
On Thu, Apr 11, 2013 at 10:22:30AM -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. 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 ? ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
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. Any reason why you need a local user at all ? (Just curious) Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
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 smime.p7s Description: S/MIME Cryptographic Signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Re: [SSSD-users] Local account logins
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 smime.p7s Description: S/MIME Cryptographic Signature ___ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
