[Bug 545724] New: useradd foo; passwd foo doesn't work if kerberos is used
http://bugzilla.novell.com/show_bug.cgi?id=545724 Summary: useradd foo; passwd foo doesn't work if kerberos is used Classification: openSUSE Product: openSUSE 11.2 Version: Milestone 8 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: mc@novell.com ReportedBy: mmarek@novell.com QAContact: qa@suse.de Found By: --- On a system with ldap and kerberos, pam-config sets the following in /etc/pam.d/common-password-pc: password requisite pam_pwcheck.so nullok cracklib password [default=ignore success=1] pam_succeed_if.so uid > 999 quiet password sufficient pam_unix2.so use_authtok nullok password sufficient pam_krb5.so password required pam_ldap.so try_first_pass use_authtok The line with pam_succeed_if skips the pam_unix2 module for users with uid > 999. However, /etc/login.defs has UID_MIN 1000 so local users created with useradd will by default have a uid > 999: # useradd foo; passwd foo Changing password for foo. Kerberos 5 Password: passwd: User not known to the underlying authentication module # id foo uid=11065(foo) gid=100(users) groups=100(users),33(video) The log message in the pam-config repository was r151 | mcalmer | 2008-08-29 12:27:36 +0200 (Pá, 29 srp 2008) | 14 lines * release version 0.59 * src/mod_pam_unix2.c: skip password change for uid > 999 in case of krb5 is used. .. what was the reason for this change? What's the correct way of creating local users with useradd now? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 User mc@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=545724#c1 Michael Calmer <mc@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Michael Calmer <mc@novell.com> 2009-11-12 04:49:59 MST --- Kerberos is typically used with network users (e.g. LDAP, sometimes NIS). This is what we support. You can still add "System users" uid < 1000. All other are handled via kerberos. System users are created using "--system|-r". See "man useradd". If you want a different behaviour, you need to create your own pam configuration. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 User prusnak@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=545724#c2 --- Comment #2 from Pavol Rusnak <prusnak@novell.com> 2009-11-12 14:02:56 CET --- Confirmed that "useradd -r works". Thanks! Couldn't this be documented somewhere? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 User prusnak@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=545724#c3 --- Comment #3 from Pavol Rusnak <prusnak@novell.com> 2009-11-12 14:09:10 CET --- But we just figured out that users added with "useradd -r" have shell set to /bin/false, which needs to be changed (or overriden when creating the user). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 http://bugzilla.novell.com/show_bug.cgi?id=545724#c4 Ludwig Nussel <lnussel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lnussel@novell.com --- Comment #4 from Ludwig Nussel <lnussel@novell.com> 2009-11-25 15:57:04 UTC --- What was the previous behavior? I suppose it preferred local users (that's why there's sufficient pam_unix2)? What's wrong with that? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 http://bugzilla.novell.com/show_bug.cgi?id=545724#c5 Jiri Bohac <jbohac@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jbohac@novell.com, | |jkosina@novell.com --- Comment #5 from Jiri Bohac <jbohac@novell.com> 2009-12-03 11:30:32 UTC --- But (to repeat Michal Marek's question from Comment #1), what was the reason for adding the "pam_succeed_if" line in the first place? Is it to prevent pam_krb5 from asking again for the password? Can't use_first_pass be used for that? This is a major annoyance. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 http://bugzilla.novell.com/show_bug.cgi?id=545724#c6 --- Comment #6 from Michael Calmer <mc@novell.com> 2009-12-03 11:49:10 UTC --- Thinks about what happens if you want to use kerberos together with nis. You need pam_unix2 for system user like root. You need NIS to have uidnumber, gidnumber, shell, etc. pam_unix2 can authenticate nis user and can do password change for nis user. Let's say you have set the NIS password to "*" and authenticate. pam_unix2 would ask for the password and check it against the NIS password. => no match Next module is pam_krb5. There you have a match and you are logged-in. Now you want to change the password. pam_unix2 is asking for the old password and check it. => no match Next module is pam_krb5. There is a match and you get the password change ticket. The password workflow execute the stack twice, the second run update the password. So the second run started. pam_unix2 is called again. A new password is entered and pam_unix2 change it "IN NIS". Now you login again. pam_unix2 is called first and check the password => match, you are logged-in and wonder, why you do not have a ticket. This is the reason why I skip pam_unix2 completely for uid > 999 if kerberos is used. Yes, I am sure, that there are 1000 other possible configurations which take care of all such situations. I selected this one :-) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 http://bugzilla.novell.com/show_bug.cgi?id=545724#c7 Jiri Bohac <jbohac@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #7 from Jiri Bohac <jbohac@novell.com> 2009-12-03 13:41:29 UTC --- So, If I understand it correctly: You are trying to make sure that pam_krb5 is called during authentication. We need local-only users (e.g. root) to be able to log in But if the user is in both the local (or NIS or whatever processed with pam_unix), we want pam_krb5 to be called to create the ticket. And to do this you: 1) devise a hackish policy that mandates the passwords in the local (processed with pam_unix) database to be invalid so that pam_unix in the common-auth stack fails and pam_krb5 is called 2) to maintain the invalid passwords in the local database you put a hack in common-passwd to prevent pam_unix from setting the passwords. You do this based on the uid, which is a really weak indication of what database the user password should be maintained in. Come on, I hope I must have misunderstood something! This obviously needs to be solved in the common-auth stack. If the capabilities of the existing pam modules are not sufficient (harldly the case), they need to be extended. I am sure most will agree that this two-layer hack is not the right way to solve the original problem of making sure pam_krb5 is called for authentication. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 http://bugzilla.novell.com/show_bug.cgi?id=545724#c8 Michael Calmer <mc@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #8 from Michael Calmer <mc@novell.com> 2009-12-04 16:10:25 UTC --- (In reply to comment #7)
So, If I understand it correctly:
You are trying to make sure that pam_krb5 is called during authentication. We need local-only users (e.g. root) to be able to log in But if the user is in both the local (or NIS or whatever processed with pam_unix), we want pam_krb5 to be called to create the ticket.
I think, if you decided to use kerberos, you use it for all accounts except system accounts like root. Other configurations are mostly used for short tests and debugging. We here internally do this/ need this often, that's true. But in production I don't think this is very often the case.
And to do this you: 1) devise a hackish policy that mandates the passwords in the local (processed with pam_unix) database to be invalid so that pam_unix in the common-auth stack fails and pam_krb5 is called
Wrong. First pam_unix is called, than pam_krb5. If no password is given in /etc/shadow or nis for the user, pam_unix will of cause fail. This is the way pam works.
2) to maintain the invalid passwords in the local database you put a hack in common-passwd to prevent pam_unix from setting the passwords. You do this based on the uid, which is a really weak indication of what database the user password should be maintained in.
I skip pam_unix in the password section in case of uid > 999. That's correct. I do this to prevent, that a user with a kerberos account accidentally set the password in nis or /etc/shadow.
Come on, I hope I must have misunderstood something!
This obviously needs to be solved in the common-auth stack. If the capabilities of the existing pam modules are not sufficient (harldly the case), they need to be extended.
Every pam module see only his enviroment and task. It doesn't know anything about other modules. The only data it has, is the username it should work on, and all data it can get with it (e.g. getent passwd <user>). Kerberos is only designed for providing username/password equivalent. It does not have the other required values which makes a linux user complete. (uidnumber, guidnumber, gecos, home, shell) So these values must come through a different source(e.g. /etc/passwd, nis, ldap). Part of the list of entries describing a linux user is also a password field. This is the problem. There is a source which also have a password field. In case of kerberos is used, this field should be set to "*", that no authentication against this source can be successful. The current configuration prevent now a changing of this password by a policy using the only value we have in pam, the uidnumber of the user. You are invited to provide a different solution for the pam configuration. The tool we wrote to create a configuration which should work for most users of our distribution is pam-config. You can think about a new concept how the configurations can be setup. Please think also about all the other modules which needs support, e.g. pam_ldap, pam_winbind, pam_mount, etc . Before you provide a different concept, please test it with different clients, valid and invalid data. login, gdm, kdm and ssh should work and for password changing the passwd tool and the gnome and kde equivalent. You can write patches and send it to us via buildservice. I will close this again as invalid. It works like expected. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=545724 http://bugzilla.novell.com/show_bug.cgi?id=545724#c9 --- Comment #9 from Jiri Bohac <jbohac@novell.com> 2009-12-04 17:43:33 UTC --- (In reply to comment #8)
(In reply to comment #7)
And to do this you: 1) devise a hackish policy that mandates the passwords in the local (processed with pam_unix) database to be invalid so that pam_unix in the common-auth stack fails and pam_krb5 is called
Wrong. First pam_unix is called, than pam_krb5. If no password is given in /etc/shadow or nis for the user, pam_unix will of cause fail. This is the way pam works.
Sure, this is how it works. But the goal is to use pam_krb5 during authentication. Doing that by putting pam_unix as sufficient prior to pam_krb5 and mandating that all users must have an empty/invalid pssword in /etc/shadow (or NIS) is what I called a hackish policy. What you really want is something along the lines of this pseudocode: if (pam_unix succeeds) { //prevent network timeouts when network is broken if (system user) return OK call pam_krb5 as optional //to get the ticket } else call pam_krb5 as required I believe this could be done with something like this in common-auth (but I'm not an expert on this, maybe I'm wrong): auth [success=ok default=2] pam_unix auth [default=ignore success=done] pam_succeed_if.so uid < 1000 quiet auth [default=1] pam_krb5 auth required pam_krb5 .. continue with other modules
2) to maintain the invalid passwords in the local database you put a hack in common-passwd to prevent pam_unix from setting the passwords. You do this based on the uid, which is a really weak indication of what database the user password should be maintained in.
I skip pam_unix in the password section in case of uid > 999. That's correct. I do this to prevent, that a user with a kerberos account accidentally set the password in nis or /etc/shadow.
But what is accidental about that? Having a correct password in /etc/shadow is not something that should break things if common-auth is done right. In fact, it is an advantage for cases when the kerberos server is down. Sure, common-password needs to be written in a way that does not fail if the user does not exist in the local/NIS database, but that's trivial.
This is the problem. There is a source which also have a password field. In case of kerberos is used, this field should be set to "*", that no authentication against this source can be successful.
Authenticating against this source is nothing wrong. You just need to make sure you get the kerberos ticket anyway. Something I hopefully achieved in my suggested common-auth above.
I will close this again as invalid. It works like expected.
Obviously not by everyone. I don't want to be annoying by going into a never ending REOPEN-INVALID battle. But please, think about it ;-) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com