NIS user passwd problem

[Alexey Borchev]

I've got ES45 & 5.1A pk3 with NIS and C2 security.
Moust of my users (couple hundreds of) are OK.
But one of users has a problem with password:
- When password is changed from Account Manager (on NIS Master) then it's valid on NIS cliens BUT not Master.
- When password is changed from by passwd from NIS Master, it's valid on NIS Master only.
- When password is changed from by passwd from NIS client, it's valid on NIS cliens BUT not Master. But in this password length limits (7-9 chars) are not met: system believes that password length should be 10-14 characters!

I've checked that:
- UserId present in /var/yp/src/passwd (ypcat passwd)
and only once.
- UserId present in /var/yp/src/prpasswd
and only once.
- UserId is not present in /etc/passwd on master neither client.
- authck -av report that database format ok OK, then uses all CPU forever (interrupted in 2 hours...)

If anyone have any ideas?

(I have last option to retire the account and create similar one.)

[Ralf Puchner]

check if yppasswd is running on master and client (/sbin/init.d/prpasswd restart).

be surce locahost entry exists within /etc/yp/securenets on master.

check if password files are inconsistent: /usr/sbin/pwck -sm

[Spider Boardman]

First, I'm sorry to have to say that Ralf's suggestions won't help, since one of them's dead wrong (prpasswd restart won't help NIS at all), and for the others you wouldn't have got as far as you report if those problems were part of the picture.

However, given what you do report, it's clear that getespwnam() for the user in question is coming from LOCAL data on the NIS master. Specifically, 'edauth -gL victim' on the NIS master will return an entry, but won't on the NIS clients.

As far as the password length restrictions using passwd on the NIS clients, those are (for pre-V5.1B and even pre-PK3 on V5.1B) almost always the province of that system's local /etc/auth/system/default file, as listed out with 'edauth -dd -g default'. (What that really means is that the default data is always local until you have nsswitch support. As long as the length restrictions are being defaulted, you'll see per-system variations in what they are because of that.)

So far as 'authck -av' hanging, there's a known problem with some versions, possibly only fixed in V5.1B PK3 (the nsswitch support again). Under some set of circumstances which I can't really remember any more (I re-did this part of the code over 6 months ago), having any sort of dupliate username in local and NIS data (possibly the /etc/passwd-style data, maybe the prpasswd-style data, maybe both) *could* cause getespwent() to loop, and thus bollix things like 'authck -p'. At some point such annoying little bugs will likely be fixed, but that one hasn't been done for V5.1A as yet.

[Alexey Borchev]

Hi, Spider!
You are absolutely right here!
On NIS Master, I've tried:
# edauth -gL zlomanos
zlomanos:u_name=zlomanos:u_id#671:u_pwd=nryC7P87iOGAI:u_succhg#1070865598:\
:u_pwdict=qc0NhYSNV8fDU,Jv4y9HdtmRGUA,ckHMT7PY.lS.A,pNJg8MZMW4snA,v0eT.Y
.d1OE1U:u_oldcrypt#0:u_suclog#1074860282:u_suctty=INET#134.65.188.230:\
:u_unsuctty=INET#134.65.188.230:u_unsuclog#1074860269:u_lock@:chkent:
# edauth -gN zlomanos
zlomanos:u_name=zlomanos:u_id#671:u_pwd=qCoK962pGBICI:u_succhg#1070865670:\
:u_unsucchg#1061451258:u_pwdict=XmM7CEPxRWzHs,5kfFQhWIV4uhsmOYbtMOcJw2,2
M4JowZvcGY4M,/amKcaHs1ZiTU,M5GRrtU602kq6:u_oldcrypt#0:u_suclog#1074776720:\
:u_suctty=INET#134.65.188.198:u_unsuctty=INET#134.65.188.230:u_unsuclog#
1072617270:u_lock@:\
:u_template=avon:chkent:
- So, there are two entries - local and NIS.
But I cannot see local zloamnos nither in /etc/passwd, nor in Account manager.
If there is any way to kill local zlomanos?

P.S.
Sorry for late answer - I've almost given up the forum... But Your remark "I re-did this part of the code over 6 months ago" means it's right forum :-)))!

[Spider Boardman · Accepted solution]

Alexey,

I'm not sure whether you're saying you want to remove the account now entirely, or whether you just want to reduce to a single copy so that authck won't loop. For the latter, and given your earlier description of having the user in the NIS map properly, you want: 'edauth -rL zlomanos'. If you want to remove it entirely, use that same command followed by 'edauth -rN zlomanos', assuming that you've already removed it from the /var/yp/src/passwd file. [If not, then 'userdel -D -x distributed=1 zlomanos' is what you want for removing that account from NIS completely.]

If I'm missing the point, maybe the above will at least help you see where....

[Alexey Borchev]

Thanks alot, it rezolved the problem.

If there any way to checkup for other doulbed accounts?
Preferably oter from looking at every user manually...
I suspect that some combination of

ypcat passwd | awk ...| edauth -gL

might do the trick...

[Spider Boardman]

First, note that the existence of two separate auth.db files for the local users means that duplication can happen within the 'local' set. It's rare that this matters, but it can happen. With that said, though, the following lists the duplicated account names for me:

(edauth -gL1t ; edauth -gN1t) |
sort -t: -k 1,1 |
awk -F: '{if (n == $1) {print p; print}; n=$1; p=$0}' |
cut -d: -f1 | uniq

That last line's processing can obviously be changed to whatever you desire -- it's the part through the awk invocation which is getting the list of records for duplicated names.

[Alexey Borchev]

OK. Dear all, here I've tried to sum up topic:
I've got: ES45 Tru64 5.1A pk3 - NIS Master
AS1000 Tru64 5.1B pk2 -NIS Client. C2 enhanced security is configured on both systems.

There is a NIS user zlomanos.
This user in NOT found in /etc/passwd, only in /var/yp/src/passwd

The command which shows it (On NIS):

# edauth -gN zlomanos
zlomanos:u_name=zlomanos:u_id#671:u_pwd=EnIAn6ZvDKny2:u_succhg#1075998645:\
:u_unsucchg#1075812838:u_pwdict=OF3UKXUqcqNss,qCoK962pGBICI,XmM7CEPxRWzH
s,5kfFQhWIV4uhsmOYbtMOcJw2,2M4JowZvcGY4M:u_oldcrypt#0:u_suclog#1075998696:\
:u_suctty=INET#134.65.188.198:u_unsuctty=INET#134.65.188.198:u_unsuclog#
1075993163:u_lock@:\
:u_template=avon:chkent:

BUT sometimes Unix creates LOCAL prpasswd entry for him:
# edauth -gL zlomanos
zlomanos:u_name=zlomanos:u_id#671:u_pwd=*:u_succhg#0:\
:u_oldcrypt#2:u_unsuctty=INET#134.65.188.198:u_unsuclog#1075998989:u_num
unsuclog#1:\
:u_lock@:u_flogins#11:chkent:

Once there is a local prpasswd enrty, systems matches password againt local entry, not NIS one.
The situation can be fixed by killing local entry:
# edauth -rL zlomanos

There is a spell, which can detect all doubled prpasswd entries:
#(edauth -gL1t ; edauth -gN1t) | sort -t: -k 1,1 | awk -F: '{if (n == $1) {print p; print}; n=$1; p=$0}' | cut -d: -f1 | uniq
(Special thanks to Spider Boardman)

As far as I noted, Tru64Unix tends to create local prpasswd entries in 2 cases:
0) The doubled prpasswd entries was seen both on NIS master and NIS client
1) When on NIS master I am canging someone's password:
#passwd username
- sometimes it works well, sometimes makes the copy.

2) When a user tries to log in into NIS slave server, while NIS master is down.