Problem unlocking account on Trusted Host

[Eric Ladner]

I have an account on a machine that's configured as a NIS+ client and is also converted to a Trusted System.

The problem is that after I locked my account via to many login attempts, it won't allow me to unlock the account (either through SAM or /usr/sbin/modprpw -v USER).

I've checked the account on the NIS+ server and it's not locked, but if I do a /usr/sbin/getprpw USER on the client machine, it has a lockout=0001000 (too many login attempts) shown.

The curious thing is that it doesn't look like Tusted System is keeping the /tcb/files/auth entry in sync with NIS+. That's how the problem occured in teh first place, I believe. I had changed my password on the NIS+ server, then when logging in to that box that had been recently converted to Trusted System, it wouldn't take the new password. Also curious is that in another window I still have active, I can use sudo and it recognises the new password.

I've checkpointed and restarted the NIS+ server and the processes on teh NIS+ client.

Any thoughts?

[Wodisch]

Hi Eric,

have you tried "modprpw -x user" or "modprpw -k user"?
One of the two is for "root", but the other is to enable all the other users (I just cannot remember which one is what).

HTH,
Wodisch

[Michael Tully]

Wodisch is correct it is one of them: This one should work.
/usr/lbin/modprpw -k user

[Denver Osborn]

I think you need to look for ttsyncd to be running. It's used for syncing the nis+ passwd table w/ nis+ trusted table.

set TTSYNCD=1 in /etc/rc.config.d/comsec to start it at system boot.

man ttsyncd

Hope this helps,
-denver

[Eric Ladner]

/usr/lbin/modprpw fails. It doesn't report an error but returns an error code.

SAM reports that modprpw failed when trying to activate the user on the client.

ttysyncd is running on the NIS+ server. I tried to start it on the client just for kicks and it says rpc.nisd isn't running, so I assume it's a NIS+ server component, not a client agent or the like.

On a whim, I deleted the /tcb/files/auth entry for myself. This allowed me to log in and recreated the entry.

This seems like a synchronization issue between the NIS+ server and NIS+ client and Trusted Server not honoring the NIS+ namespace first before the /tcb entries.

Thanks for getting my brain going

Eric