Trusted system with NIS+ : synch issues?

[Barry O Flanagan]

Hi all,
I have a trusted system running 11.0 and this machine is also the root master of my NIS+ domain. Just wondering if anyone has come across the following :

I create a NIS+ user account, add to the passwd and cred tables. No problem - I can log in as the user and do whatever.

I then delete that user. Then I go to add in another user again, but with the same UID as the user I removed (yes I've checked that the original user was removed from the passwd and cred NIS+ tables). So I add the user to the passwd and cred tables as normal and set their NIS+ password and secret key the same. Then I force a password change for the user with a passwd -r nisplus -f .

Then I try to log in as the new user. I enter the password and it tells me my password has expired (as it should). Then it asks me to set my password and I enter it twice for verification, at which point it returns and says : Password information update failed
Login aborted due to no password.

At this point, the following pops up in syslog: NIS+ fatal error: 14

So my question is: is it enough to just remove the entries from the NIS+ passwd and cred tables when deleting a NIS+ user? Should the trusted system not synch with NIS+ details at this point? Is this a synch problem at all?

Help!
Barry

[Bill McNAMARA_1]

hey Barry,
give us an swlist -l product output.

Does it work if you don't use the same
GID as the removed user? If it does
I'd imagine there's some type of
sync push that has to take place.

I'll have a look around and see what I find.

Later,
Bill

[Bill McNAMARA_1]

There's a doc here that may help decode
error messages and give a little more on
troubleshooting.

http://docs.hp.com/hpux/pdf/B1031-90045.pdf

Later,
Bill

[Bill McNAMARA_1]

From that doc:
After a user has changed passwords, there may be a delay before the new password is propagated through the domain. This delay can be as long as many minutes, depending on the size of your domain. The problem will probably resolve itself if you wait, or you can issue the nisping org_dir command to force the servers to resynchronize.

Later,
Bill

[Barry O Flanagan]

Bob,

Tried adding, then deleting, then adding a new user with different group with the exact same effect.

Tried the nisping -Ca approach after I make any updates and while that does seem to propagate the changes to the NIS+ servers, the problem still exists afterwards.

I think it might be something more along the likes of NIS+ tables being updated fine, but the trusted system is keeping something it shouldn't. Does ttsynchd have anything to do with that?

The Installing and Administering Internet Services doc I have seen and it doesn't tell me what my "Fatal Error 14" is!

By the way, I've attached my swlist output by the way.

[Barry O Flanagan]

Adding a NIS+ user with a UID that has previously existed using SAM also fails with the same error.

[Barry O Flanagan]

Bill,

Sorry for calling you Bob! Typo on my part!

[Bill McNAMARA_1]

Have you logged a support call on this?
It seems that you patch level is right up
to date.
Command line syntax can't be an issue if
SAM and commandline do the same. I can
only assume either an initial setup error
or a bug.
I'm afraid I can't help you much more.. I'm
out of ideas, even though I'd like to
seeing as you're a fellow countryman!

Good luck with it.
Bill