NIS in Fedora 13

[manojg]

Hi,

I am trying to setup NIS client in Fedora 13 which is already running NFS server just fine. Setup looks good: ypbind, rpcbind, portmapper are running, and also ypdomainname, ypwhich, domainname return me appropriate output. However, "ypcat user" has problem (returns No such map user_name. Reason: Internal NIS error) but other NIS clients running older Fedora have also same problem with ypcat although they are running fine. So, I don't think this is causing problem.

My problem is: somehow Fedora 13 could not get the map, and I could not login to this machine. During login it says invalid user and do not accept password.

Any idea will be appreciated.
Thanks.

PS: Firewall, selinux and NetworkManager are disabled completely.

[manojg]

It looks like it is getting the map also because ypcat passwd gives me user info. Simply, I can't ssh to this machine, it does not recognize the password or user name.

Any ideas?

[jpollard]

Have you checked the /etc/nsswitch.conf file?

The entries for passwd, shadow, and group need to have nis or it will not allow
the map to be used for logins.

[manojg]

Hi guys,

Yes, I have checked /etc/nsswitch.conf file, it is fine.

After hitting my head for many hours, I found a post and that solved the problem. It seems to me very stupid thing. The problem was the file /etc/shells . In fedora 13, there are following lines in /etc/shells file:

 /bin/sh
/bin/bash
/sbin/nologin

To work ssh with nis, there must tcsh and/or csh line also.

/bin/sh
/bin/bash
/sbin/nologin
/bin/tcsh
/bin/csh

Only adding these lines does not make sense if you do not have installed tcsh/csh. So, add these line and install tcsh/csh. In older Fedora (I have Fedora 8), /etc/shells has all these line, so ssh with nis was working fine.

I am not sure how ssh with nis depents on tcsh/csh, funny is't it?

Hope this will help others too.


Thanks.

---------- Post added at 09:57 PM CDT ---------- Previous post was at 09:34 PM CDT ----------

I realized that the requirement of tcsh/csh in /etc/shells is because user's default shell in NIS server is tcsh. So, ssh has to match not only user name and password but also the default login shell.

---------- Post added 2010-07-19 at 06:52 AM CDT ---------- Previous post was 2010-07-18 at 09:57 PM CDT ----------

Hi,

Does any body has some security tips for NIS? I have already created /var/yp/securenets.
I also saw on google about "passwd.adjunct" which gives encrypted passwd with ypcat passwd. Does anybody know how to setup this. I could not find by googling.

Thanks.

---------- Post added at 07:01 AM CDT ---------- Previous post was at 06:52 AM CDT ----------

Well, I found something but looks complecated: http://windowsecurity.com/whitepaper...rmerly_YP.html

[jpollard]

It is also out of date - (2002)...

Most of the procedure is already covered.

The main reason people are not using NIS anymore is that the NIS maps are
available to anyone on a host where that host is authorized to use NIS maps.

This means that any NIS map (including any with passwords) is visible.

[manojg]

Hi jpollard,

Yes, you are right. But somehow passwd and user name can be encrypted by using "passwd.adjunct". So, ypcat returns encrypted passwd. I am searching about this but have no idea yet.

[jpollard]

If you are referring to encrypted communications for NIS, then you are referring to
NIS+, and not NIS.

If you are still referring to NIS, then the communications are still not encrypted, and
creating a passwd.adjunct is still visible, but it takes just a little bit more effort as
the ypcat utility doesn't recognize the map "passwd.adjunct". The map is still
available, but now you have to write your own version of ypcat to retrieve it.

[manojg]

Ok, thanks.

In file /etc/sysconfig/authconfig, it has still USENIS=no option. I am wondering how ssh on NIS is working with this option?

[jpollard]

I'm not sure - I'd have to dig into the sources.

sshd used to use the getpwent function, which would return password entries from
any available source... The getpwent would combine the shadow and passwd entries
eliminating the the need to to it externally.

[SiliconSlick]

Originally Posted by manojg

Ok, thanks.

In file /etc/sysconfig/authconfig, it has still USENIS=no option. I am wondering how ssh on NIS is working with this option?

Not sure that is consulted unless authconfig is run manually. Looking at the man page for authconfig-tui --nostart (which is run by rc.sysinit), it implies that it might be used to determine whether ypbind should be run. I'm not sure but it might also be used to add "nis" to password line in /etc/pam.d/system-auth[-ac] (the line that also has shadow). The latter is needed in order for password changes to go to the NIS master (I think) but not needed to log in (IIRC). Not sure since I always just had cfengine add those as needed on our NIS systems and didn't deal with authconfig much.

SS