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.