NIS woes

fullauto

fullauto

I am trying to setup an NIS domain to handle the user accounts on the network.
I have a master NIS server named hermes and a slave server named kif and a client named hubert.
I went through and performed the instructions in the FreeBSD Handbook.

After I got it all 'running', I created a user account on hermes (NIS-M) to test if it was all working.

Code: 
adduser
Username=test.account
Password=test

then issued this command:
Code: 
cat /etc/master.passwd | grep test >> /var/yp/master.passwd
cd /var/yp
make

Everything updated and the push to kif (NIS-S) even worked save the shadow files...
I then issued this on the Client machine (hubert)

Code: 
[ROOT@hubert]/etc/rc.d-> ypcat master.passwd | grep test
test.account:$1$QcSCj.tA$TyxLNeyr2YhZNGzLBVxBE0:1011:1011::0:0:Test Account:/home/test.account:/bin/csh



But when I try to log into hubert with the account I am refused.
Any pointers?

Auth.log says:

Code: 
Jan 21 15:46:01 hubert sshd[32737]: error: PAM: authentication error for illegal user test.account from 192.168.1.2
Jan 21 15:46:01 hubert sshd[32737]: Failed keyboard-interactive/pam for invalid user test.account from 192.168.1.2 port 55983 ssh2
 
Try running % id -P test.account. Does it return anything? You might need to check /etc/nsswitch.conf to ensure that it is using compat with nis as the compat sourcetype.
 
Is this for testing purposes or is it supposed to go in production? If it's the latter I strongly advise you NOT to use NIS. If you want a centralized account database I suggest you use LDAP (combine it with Kerberos if you want).

NIS has a couple of major drawbacks, like every user being able to get all usernames AND passwords from the NIS server.
 
Are you limiting user/group access in your sshd_config? Since the error message lists "illegal" user as opposed to "invalid" user, it would appear that the account is found, but something about the account is causing SSH to reject it.

FWIW, we've been using NIS for a bit over 13 years now. We talked about moving to LDAP a couple of years ago, but it was decided that it wasn't worth the trouble. Between migrating user account information and updating account interface scripts, it was hard to justify the change when we had a perfectly running system. Just like everything else, it has it's place.
 
Although it was good 13 years ago, keep in mind that cracking passwords has become infinitely easier. I can easily get a list of all your accounts, including passwords. Shove those in a cracker with rainbow-tables and I can guarantee you 90% of the passwords will be found within minutes.

With LDAP you can put an ACL on the passwords so this enumeration isn't possible.
 
I second what SirDice is saying. NIS can only be used in a completely secured environment where all the hosts in the network are 100% trusted. Even then it's a finicky system, doesn't scale well and isn't really robust. It's time to put it to rest and move on to LDAP.
 
SirDice said:
I can easily get a list of all your accounts, including passwords [red](password hashes)[/red]. Shove those in a cracker with rainbow-tables and I can guarantee you 90% of the passwords will be found within minutes.
Click to expand...
I'm not too sure about the 90%, that seems an awfully high hit rate unless an archaic hash (e.g. classic DES) is being used and/or the user base contains an awful lot of users who deserve to be called lusers for having stupid passwords. I do agree with the underlying sentiment. though: NIS has outlived its usefulness in large-scale environments where perhaps not every user can be trusted. That definitely includes universities. However, I do believe it's still suitable for small(er)-scale (trusted) private environments in which setting up LDAP just isn't worth the trouble.

Just my two (euro)cents though.
 
fonz said:
I'm not too sure about the 90%, that seems an awfully high hit rate unless an archaic hash (e.g. classic DES) is being used and/or the user base contains an awful lot of users who deserve to be called lusers for having stupid passwords.
Click to expand...
Yes, I should have mentioned password hashes. But it doesn't really matter what the hash is (DES isn't a hash by the way), rainbow-tables calculate all possible hashes beforehand. After that it's a simple lookup in a table to see what the password would have been. And yes, you can crack passwords in minutes, even complex ones.

http://en.wikipedia.org/wiki/Rainbow_table
 
SirDice said:
rainbow-tables calculate all possible hashes beforehand. After that it's a simple lookup in a table to see what the password would have been.
Click to expand...
Does seasoning with some salt (see same article) help?
 
fonz said:
Does seasoning with some salt (see same article) help?
Click to expand...

It should, yes. But I wouldn't rely on it too much. Cracking progresses quite fast, they've already started using GPUs to increase the speed even further. It's better if nobody has access to the password hashes in the first place.
 
SirDice said:
It's better if nobody has access to the password hashes in the first place.
Click to expand...
That is of course "a truth like a cow" (to crappily paraphrase a Dutch expression ;)).

[edited to add]
I thought that the password hash exposure problem of NIS had already been fixed, but it's been a while since I last had to deal with NIS directly so I might be (read: probably am) mistaken.
 
fonz said:
[edited to add]
I thought that the password hash exposure problem of NIS had already been fixed, but it's been a while since I last had to deal with NIS directly so I might be (read: probably am) mistaken.
Click to expand...
It could be but I don't think so. It's been a few years since I last encountered NIS during a security audit. Needless to say, it wasn't fixed there :e
 
Sounds to me...

Like I should be useing Kerberos. Not sure what that is or how it's implimented, but if it will allow me to have a centralized machine to control user accounts, and is more secure it sounds right for me!

Any suggestions on reading to help me impliment this?
 
You can use NIS to be your directory service without any passwords (ie, all locked accounts) and just used some other authentication mechanism. LDAP is a PITA to setup, NIS is simpler from that point of view.
 
You must log in or register to reply here.
Back
Top