Very Computer

We have a Sun server 5.6 with NIS running on it.

The task was to allow a user to log in to the machine.

He couldn't tunnel in to this machine, because he kept
getting prompted for the NIS password.  I couldn't change
it remotely either.  So, I just drove over to the site,
and logged on as root.

I thought, just delete him, and then recreate him,
which I did with admintool.  There was no entry
in either the /etc/passwd, or /etc/shadow files.

However, this guy was a ghost.  A dispuid revealed him,
along with a whole bunch of the other dead names.

Then, while logged in as root, I used the su command
to change to this supposedly extinct user.  And I
was logged in as him, with the extinct UID!  What's
going on here?

# su rich
$ id
uid=1004(rich) gid=101(dba)

But, yppasswd didn't work.  (Perhaps I should have:
su - rich )

$ yppasswd
yppasswd:  Changing password for root
passwd(SYSTEM):  root does not exist
Permission denied

We want to delete all traces of this guy, and
recreate him in the normal manner, without any nis+.
How can I do it?

Thanks,

Argosy

Sent via Deja.com http://www.deja.com/
Before you buy.

I'm new to monitoring unix newsgroups.  I've only been a sys admin for a
little more than a year, but I had the SAME problem when I first took
control of a couple of servers that were running Solaris 2.5.1 and using
NIS+.  Someone who left our office, but who had stayed with another part
of the organization, told me that I had forgotten to delete her
account.  But, I definitely did delete the account.

Then I experimented with my personal account and the same thing
happened.  Even though I had deleted the account and there was no entry
for me in /etc/passwd and no entry in /etc/shadow files, I was still

Well, to make a long story, short NIS+ had everything to do with it.  To
make matters worse, my Department of Defense organization uses a special
interface that enhances security and helps ensure that the thousands of
systems in our classified network will appear and behave the same way,
but this special interface (they call it DII COE ... maybe you've heard
of it) just makes things a little more complicated for the sys admin.
It's great for the users, but not for me.

Let me get to the point.  If you're using NIS+, I think you should begin
with doing a:
    niscat passwd.org_dir

If you're running yp, find the correct command to do the equivalent.

That should display the NIS+ password file and I suspect that you'll see
an entry for your "ghost" accounts.  If you don't find an entry there
for those accounts, I'm lost and completely unable to help.

If there is indeed an entry for the "ghosts," you need to run the
appropriate commands to get them out of the NIS+ passwd file.  I think
you'll need the "nistbladm" command or the yp equivalent.  I don't
remember the exact syntax, but you want to use the "-r" option to remove
the entry for each of the "ghost" accounts.

That ought to prevent them from logging in, but you may have a slightly
bigger problem.  Apparently, admintool is not touching your NIS
environment when you remove accounts.  I have the same problem myself,
apparently because I'm using our account manager utility improperly, or
it's buggy.  We don't use admintool.  Consequently, although you've
deleted the UNIX part of the account (passwd and shadow file entries),
you haven't removed their NIS credentials.  That would permit the
deleted users to continue logging into your system.

Therefore, you need to perfect some procedure to remove accounts that
will also cover your NIS tables, otherwise, you'll continue to have the
problem.

Please let me know how this turns out.  I'd like to know if I helped set
you in the right direction.

Tony
______________________________________________