Updating protected password database

[Jim Poplawski]

Folks,
We have an HPUX application that talks to our custom workstation application to get the userid/password. the program then checks the password by encrypting it and comparing the encrypted string to that of the encrpyted password stored on the server. The user does not do an actual login to HPUX. That works fine.
We need to update the functionality so that we can lock the account after the required number of bad attempts.
So…we've written a test program that reads protected password stuff using the getprpwent() system call. The program then increments the fd_nlogins counter and writes the entire entry back using the putprpwnam system call. This does not work, the retry count is not udpated. To insure that the program is not "flakey" I revised it to update the fd_max_tries counter and it works fine.
Any ideas why the fd_nlogins counter wouldn't update?
thanks!
Jim

[Court Campbell]

Can you past the line of code that updates fd_nlogins?

[A. Clay Stephenson · Accepted solution]

I had to go look in my comments of some code I have that makes calls to putprpwnam() and I did find exactly your behavior when trying to reset fd_nlogins. The call would return a non-zero result (which for some whackball reason means ok in sharp contrast to almost all functions) but the fd_nlogins value would be unchanged. There was a wrinkle. If the field, u_numunsuclog#N, in the actual tcb files was present THEN the value would be updated. However, if the field was not already in the file (which is the default if there have been no bad logins) then the value would not be written to the file.

[Jim Poplawski]

So what you're saying is that if the field doesn't exist, we need to set both to get it to work, correct?

[A. Clay Stephenson]

I don't know what you mean by "both". The field "u_numunsuclog#count" in the /tcb/file/auth/x/xusername corresponds to the fd_nlogins inside a pr_field struct.

Start by manually inserting "u_numunsuclog#0" into the file to set the value at zero and see if your routine doesn't then work as expected. Your final version will probably have to invoke sed, Perl, or some really ugly C to parse this entry and insert the needed field.

You should note that this is one of the fields that the modprpw command does not allow to be updated so there appears to be some method to this madness.