NIS used authenticated OK but nothing works

Greetings and Felicitaions

we have an NIS problem which would appear from googling that this has
been an FAQ. Shame it isn't a frequently answered question. :-)

We are running FC1, ypserv --version ypserv (ypserv) 2.8 ypbind
--version ypbind (ypbind-mt) 1.12 I setup NIS and users authenicate
up to a point (ie they can login) but once they are logged in, they
cannot access very much. It would appear that this is because their
uid is not being translated to a uname. Here is a short terminal
capture session (on a yp client) :-

[I have no name!@bart ahmeo04]$ id
uid=590 gid=100(users) groups=100(users)
[I have no name!@bart ahmeo04]$ ypmatch chris group
chris:x:500:
[I have no name!@bart ahmeo04]$ ypmatch 590 passwd.byuid
Can't match key 590 in map passwd.byuid. Reason: Internal NIS error
[I have no name!@bart ahmeo04]$ yppasswd
yppasswd: can't find the master ypserver: Internal NIS error
[I have no name!@bart ahmeo04]$

If I am logged in as root, the ypmatch command above works fine :-

[root@bart root]# ypmatch 590 passwd.byuid
ahmeo04:eq8ubhpZrFqSU:590:100:Ahmed Omar:/home/LISA/ahmeo04:/bin/bash
[root@bart root]# echo $PS1
[\u@\h \W]\$

When I ran ypserv in debug mode, the following messages were displayed
in response to the ypmatch command above (as the NIS authenticated
user) :-

ypproc_match(): [From: 192.168.0.7:32955]
domainname = "hgs.nis"
mapname = "passwd.byname"
keydat = "ahmeo04"
connect from 192.168.0.7
-> Ignored (not a valid source host)

I have used the makedbm command to dump out the contents of the db
file (on the server) and can see all of the data as it should be. So
in a nutshell, only root is to be able to resolve the passwd maps
through yp. No regular user has access to them and as a consequence
no one can change their password or indeed access any application that
needs to resolve a uid to a uname.

If anyone knows how to mend this, would they please let me know?

Thanks in advance
Martin Woolley
ICT Support
Handsworth Grammar School
Isis Astarte Diana Hecate Demeter Kali Inanna

On Mon, 18 Oct 2004 04:23:11 -0700, martin wrote:
> we have an NIS problem which would appear from googling that this has
> been an FAQ. Shame it isn't a frequently answered question. :-)

Sounds like you have things rather twisted up? I have setup NIS, NFS,
automounter on a number of systems and never seen anything like your case.

> We are running FC1, ypserv --version ypserv (ypserv) 2.8 ypbind
> --version ypbind (ypbind-mt) 1.12 I setup NIS and users authenicate
> up to a point (ie they can login) but once they are logged in, they
> cannot access very much. It would appear that this is because their
> uid is not being translated to a uname. Here is a short terminal
> capture session (on a yp client) :-
>
> [I have no name!@bart ahmeo04]$ id
> uid=590 gid=100(users) groups=100(users)
> [I have no name!@bart ahmeo04]$ ypmatch chris group
> chris:x:500:
> [I have no name!@bart ahmeo04]$ ypmatch 590 passwd.byuid
> Can't match key 590 in map passwd.byuid. Reason: Internal NIS error
> [I have no name!@bart ahmeo04]$ yppasswd
> yppasswd: can't find the master ypserver: Internal NIS error
> [I have no name!@bart ahmeo04]$
>
> If I am logged in as root, the ypmatch command above works fine :-
>
> [root@bart root]# ypmatch 590 passwd.byuid
> ahmeo04:eq8ubhpZrFqSU:590:100:Ahmed Omar:/home/LISA/ahmeo04:/bin/bash
> [root@bart root]# echo $PS1
> [\u@\h \W]\$
>
> When I ran ypserv in debug mode, the following messages were displayed
> in response to the ypmatch command above (as the NIS authenticated
> user) :-
>
> ypproc_match(): [From: 192.168.0.7:32955]
> domainname = "hgs.nis"
> mapname = "passwd.byname"
> keydat = "ahmeo04"
> connect from 192.168.0.7
> -> Ignored (not a valid source host)

Did you try running ypbind on the client machine(s) with debugging
enabled? Do you get the correct response to ypwhich? I would first check
that ypbind on the server machine can talk to its own ypserv. Then (once
verified) see if you can make another client machine work correctly.

> I have used the makedbm command to dump out the contents of the db
> file (on the server) and can see all of the data as it should be. So
> in a nutshell, only root is to be able to resolve the passwd maps
> through yp. No regular user has access to them and as a consequence
> no one can change their password or indeed access any application that
> needs to resolve a uid to a uname.
>
> If anyone knows how to mend this, would they please let me know?

I would suggest that if you cannot diagnose your current setup, using
whatever tools you have, that maybe you should go back to the beginning
and carefully reinstall and reconfigure your yp server(s) and then try
setting up one yp client machine. When that is running, the others should
automagically just work.

BTW, I am not sure why you were trying to look up a uid using yp? I have
never had to do that. You should always be looking up user login ids and
using whatever uid comes back. Do you have inconsistencies between uids
and/or gids between machines? If so, you should fix that first.

--
Juhan Leemet
Logicognosis, Inc.

Juhan Leemet <(E-Mail Removed)> wrote in message news:<pan.2004.10.19.21.11.09.110908@logicognosis. com>...
> On Mon, 18 Oct 2004 04:23:11 -0700, martin wrote:
> > we have an NIS problem which would appear from googling that this has
> > been an FAQ. Shame it isn't a frequently answered question. :-)
>
> Sounds like you have things rather twisted up? I have setup NIS, NFS,
> automounter on a number of systems and never seen anything like your case.

In the past I've had it working on AIX without problems. The problems
I'm experiencing are on a Fedora FC1 system.

> Did you try running ypbind on the client machine(s) with debugging
> enabled? Do you get the correct response to ypwhich? I would first check
> that ypbind on the server machine can talk to its own ypserv. Then (once
> verified) see if you can make another client machine work correctly.

Yep and I get the same result. Everything works fine as root, anything
involving the use of the password file fails as a non-root user. As I
stated previously, several other people have reported this same
problem in the past. I haven't seen a resolution to this.

> I would suggest that if you cannot diagnose your current setup, using
> whatever tools you have, that maybe you should go back to the beginning
> and carefully reinstall and reconfigure your yp server(s) and then try
> setting up one yp client machine. When that is running, the others should
> automagically just work.

Been there, done that serveral times previously. It still doesn't
work.

> BTW, I am not sure why you were trying to look up a uid using yp? I have
> never had to do that. You should always be looking up user login ids and
> using whatever uid comes back. Do you have inconsistencies between uids
> and/or gids between machines? If so, you should fix that first.

I'm looking up a uid just as a test. I still get the failures on a
uname lookup. The are no inconsistances between uids and/or gids -
this should make no difference in any case as I am trying to get users
to authenticate against a central machine. My gut reaction is that
the PAM authentication is getting in the way. I think that this is
central to Linux security and I don't believe that you can remove it.
In a nutshell, it appears as though only root is able to resolve the
passwd maps through yp. *No regular user has access to them and as a
consequence no one can change their password or indeed access any
application that needs to resolve a uid to a uname. (eg open office,
abiword, koffice, etc, etc).
--
Regards
Martin Woolley
ICT Support
Handsworth Grammar School
Isis Astarte Diana Hecate Demeter Kali Inanna

On Wed, 20 Oct 2004 06:56:13 -0700, martin wrote:
> Juhan Leemet <(E-Mail Removed)> wrote in message news:<pan.2004.10.19.21.11.09.110908@logicognosis. com>...
>> On Mon, 18 Oct 2004 04:23:11 -0700, martin wrote:
>> > we have an NIS problem which would appear from googling that this has
>> > been an FAQ. Shame it isn't a frequently answered question. :-)
>>
>> Sounds like you have things rather twisted up? I have setup NIS, NFS,
>> automounter on a number of systems and never seen anything like your case.
>
> In the past I've had it working on AIX without problems. The problems
> I'm experiencing are on a Fedora FC1 system.

OK, I should bow out then... no experience with Fedora. I have used NIS
and NFS (with automounter) on (Slackware? I don't remember), RedHat,
Mandrake, and (most recently) SuSE, besides my constant Solaris.

>> Did you try running ypbind on the client machine(s) with debugging...
> Yep and I get the same result. Everything works fine as root, anything
> involving the use of the password file fails as a non-root user...

Bizarre!

>> I would suggest... carefully reinstall and reconfigure your yp...
>
> Been there, done that serveral times previously. It still doesn't work.

OK, sorry, I wasn't trying to be insulting.

>> BTW, I am not sure why you were trying to look up a uid using yp? ...
>
> I'm looking up a uid just as a test. I still get the failures on a
> uname lookup. The are no inconsistances between uids and/or gids - this
> should make no difference in any case as I am trying to get users to
> authenticate against a central machine. My gut reaction is that the PAM
> authentication is getting in the way. I think that this is central to
> Linux security and I don't believe that you can remove it. In a
> nutshell, it appears as though only root is able to resolve the passwd
> maps through yp. *No regular user has access to them and as a
> consequence no one can change their password or indeed access any
> application that needs to resolve a uid to a uname. (eg open office,
> abiword, koffice, etc, etc).

Odd, is Fedora use of PAM that much different from the others (Solaris,
SuSE Linux, etc.)? Sounds like it might be a Fedora specific problem?

BTW, if you are using standard NIS, then even though you are
authenticating against a central machine (NIS server) the authentication
is actually being done locally, using ypbind supplied info (fetched from
ypserv on the central machine). Dunno if that subtlety makes a difference?
Is there some permissions problem locally? Unless you are using Kerberos?
Then you would be authenticating centrally, but it is no longer NIS.

I have nothing to add. Bowing out. Sorry to waste your time & bandwidth.

Another thought: maybe do "rpm -V" on all the nis related packages, to
make sure that nothing has gotten corrupted. Have you "hardened" machine?

--
Juhan Leemet
Logicognosis, Inc.

SOLVED!
Problem is caused by these lines in the /etc/ypserv.conf :-
# Host : Domain : Map : Security
#
# * : * : passwd.byname : port
# * : * : passwd.byuid : port
To quote from Sarup 'You should do this [un-comment them] otherwise
any user on the network can say "ypcat passwd" and see the entire
password database exported by the NIS server, including the encrypted
password. However, root on the client machines will be able to view
the encrypted password.' The comments from the /etc/yp.serv file state
that the above lines '...when uncommented, will give you shadow like
passwords. Note that it will not work if you have slave NIS servers in
your network that do not run the same server as you.' This all implies
that this is the way to go, BUT if you do then an unprivaledged user
cannot access the password map file and so their uid cannot be
translated to their uname.
--
Regards
Martin Woolley
ICT Support
Handsworth Grammar School
Isis Astarte Diana Hecate Demeter Kali Inanna

On Thu, 21 Oct 2004 07:32:26 -0700, martin wrote:

> SOLVED!
> Problem is caused by these lines in the /etc/ypserv.conf :-
> # Host : Domain : Map : Security
> #
> # * : * : passwd.byname : port
> # * : * : passwd.byuid : port
> To quote from Sarup 'You should do this [un-comment them] otherwise
> any user on the network can say "ypcat passwd" and see the entire
> password database exported by the NIS server, including the encrypted
> password. However, root on the client machines will be able to view
> the encrypted password.' The comments from the /etc/yp.serv file state
> that the above lines '...when uncommented, will give you shadow like
> passwords. Note that it will not work if you have slave NIS servers in
> your network that do not run the same server as you.' This all implies
> that this is the way to go, BUT if you do then an unprivaledged user
> cannot access the password map file and so their uid cannot be
> translated to their uname.

Hmm, must be a Linux'ism? I don't see any /etc/ypserv.conf on Solaris.

My understanding was that to address the security ascpects of NIS and NFS
one should implement secure RPC (and then NIS and NFS ride on top). Then
you also want to restrict access in /var/yp/ypsecurenets (Solaris
location). I have not done that (yet) but I have read posts from people
who have. I am not sure how to protect against a root user on a "rogue
machine". I guess that is a "physical security" issue? How would a rogue
machine get on your network? Do you have to list machines explicitly? My
own private LAN does not have this problem (I guess depending on WEP?), so
I have not pursued this potential problem further. Was going to look at
secure RPC, just to see what is involved (short of putting up NIS+).

p.s. I did experience some weirdness of ypserv on Linux slave NIS servers,
fed from my master Solaris server. Seemed that if/when one of my Solaris
used the Linux ypserv, then it could not resolve internet DNS addresses.
Hmm, the Linux ypserv seemed to interfere with the fallback from NIS to
DNS. Not sure if that is supposed to be handled by ypserv? Didn't have
time/energy to fool with it, so I switched to use only Solaris ypserv.

--
Juhan Leemet
Logicognosis, Inc.