I have installed the revised pam module, pam-0.72-34, which was modified to tolerate an aging string from an NIS password file. That works fine. However, I have discovered another NIS password related problem. If the user's password is longer than 8 characters, it will not authenticate. This problem only occurs if the password entry is retrieve via NIS. If you create a local account for the same user with the same encrypted password string, it authenticates fine.
What are you using for an NIS server? How is it storing its passwords?
We are using an HP-UX NIS server. It uses the stock DES encryption routine and the encrypted passwords are stored in the password field, followed by a comma and a 4 character aging string. Is that what you needed to know?
The standard DES-based crypt() discards characters after the eighth in a password, so if anything you should be seeing odd successes with any password which shares the same first eight characters. When you run "getent passwd username" for the user, do you see the hashed password in the second colon-separated field? Does it match the result of running python -c 'import crypt;print crypt.crypt("password","salt")' ("salt" should be the first two characters of the hashed version of the password)?
getent and the python command you gave give identical encryption strings, except that the getent passwd field includes the aging string.
Hmmm. Are there any messages in /var/log/messages or /var/log/secure that relate to the user's login attempts?
There are no messages in /var/log/secure, but the following appears in /var/log/messages after a failed attempt with long password: Dec 4 07:21:37 crashl PAM_unix[19873]: authentication failure; (uid=0) -> vmsetup for login service Dec 4 07:21:39 crashl login[19873]: FAILED LOGIN 1 FROM vulcan FOR vmsetup, Authentication failure vmsetup is the user name I am using to trouble shoot this problem, as you can see. One other thing. There is a noticeable delay of 2-3 seconds during the login before it is rejected. That may not indicate anything, because it takes just as long to reject a deliberately mistyped password. For what it is worth, vmsetup, with this same 9 character password, can login to a Redhat 6.2 box without a problem. I appreciate your prompt responses! Thanks.
OK, I have done some sleuthing in the pam source code. In the function _unix_verify_password in ../pam-0.72/modules/pam_unix/support.c, the problem arises at line 642 where the code calls bigcrypt to set pp. I have been using a test user "vmsetup" with the password "iluv2ski2". bigcrypt generates a 24 character string "/NGilKAa2YNnodPe3kn5qaaY" and passlen gets set to 24. However, the password utilities on HP-UX generated the following "/NGilKAa2YNno,o6BN", which, as you can see, matches what came from bigcrypt up to 13 characters. After that, the NIS/HP-UX password contains the comma and aging string. Since passlen was set to 24, it tries to compare apples and oranges. For another user, with a 7 character password, the NIS password and the bigcrypt password were both 13 characters long. After that, in the NIS password, comes the aging string. But since bigcrypt generated only 13 characters in that case, the strncmp matches. I haven't located bigcrypt in the source code yet. I am not sure if it is doing the wrong thing, or if the logic for setting passlen should be altered to set it based on the password retrieved from the password file by getpwnam. What do you think?
OK, here is some more data. I took the aging string off on the NIS password for vmsetup. Now bigcrypt generates the exact same 13 character encryption as in the password file. So, somehow the logic in bigcrypt is being thrown off by the aging string in the "salt" passed to it.
Is there some reason this bug has been ignored since December 5th? I have a suggested change to bigcrypt.c that I can send you if anyone is interested.
I've done some research and determined that the function it's modeled after (Tru64's crypt16() function, which I assume is DEC's C2 algorithm) returns a longer crypted string. So both systems are doing what they're supposed to do, but bigcrypt() is just the wrong algorithm to use when checking passwords with HP/UX.
But it seems to me that the PAM module has no idea where the password entry it is looking at came from, NIS or local file. Assuming that a comma is only ever used to delimiit an aging string, I would think that that is the only clue the PAM module would get that might suggest a different algorithm needs to be used. What is happening now is that the comma makes the salt long enough that bigcrypt thinks it needs to do another "chunk". Checking for the comma and replacing it with a null prevents that confusion.
The salt length is used to determine whether or not to truncate the password before passing it to crypt(). If it's 13, the password is terminated at 8 characters, and bigcrypt() returns the same result as crypt(). If it's not 13 the password is not terminated, and because you have a 9-character password, bigcrypt() returns more data than you want. The standard crypt() and md5crypt() mechanisms are not supposed to allow commas in salts, and they don't generate commas on output, so terminating the crypted string at the first comma (after the 13th character, in case some broken scheme or salt is being used) would probably work here. I've put a pam-0.73-2 out in http://people.redhat.com/nalin/test/ which implements this change. Please see if it solves the problem.
Sorry, no. It fails if the user with the 9 character password types all 9 characters. It you just type 8 characters of the password, you can login.
Ah, found an error in my attempt to fix it (was comparing the first character of the salt, not the one where the comma would be if there is one). I'm almost certain that the version of 0.73-2 that's now in the test/ directory (I didn't bump the release number this time around) will fix this.
That did it. Thanks.
Thanks!