[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
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
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
http://bugzilla.novell.com/show_bug.cgi?id=545724
http://bugzilla.novell.com/show_bug.cgi?id=545724#c4
Ludwig Nussel
http://bugzilla.novell.com/show_bug.cgi?id=545724
http://bugzilla.novell.com/show_bug.cgi?id=545724#c5
Jiri Bohac
http://bugzilla.novell.com/show_bug.cgi?id=545724
http://bugzilla.novell.com/show_bug.cgi?id=545724#c6
--- Comment #6 from Michael Calmer
http://bugzilla.novell.com/show_bug.cgi?id=545724
http://bugzilla.novell.com/show_bug.cgi?id=545724#c7
Jiri Bohac
http://bugzilla.novell.com/show_bug.cgi?id=545724
http://bugzilla.novell.com/show_bug.cgi?id=545724#c8
Michael Calmer
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
(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