# NIS woes



## fullauto (Jan 21, 2013)

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.  


```
adduser
Username=test.account
Password=test
```

then issued this command:

```
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)


```
[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:


```
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
```


----------



## kpa (Jan 21, 2013)

I think you need to add this line as the last line to /etc/master.passwd, use vipw(8) to edit.


```
+:::::::::
```

And this as the last line in  /etc/group


```
+:*::
```

Reference:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-nis.html


----------



## fullauto (Jan 22, 2013)

I did


----------



## gordon@ (Jan 22, 2013)

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.


----------



## SirDice (Jan 22, 2013)

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.


----------



## pboehmer (Jan 22, 2013)

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.


----------



## SirDice (Jan 22, 2013)

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.


----------



## kpa (Jan 22, 2013)

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.


----------



## fonz (Jan 22, 2013)

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.


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 *l*users 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.


----------



## SirDice (Jan 22, 2013)

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 *l*users for having stupid passwords.


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


----------



## fonz (Jan 22, 2013)

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.


Does seasoning with some salt (see same article) help?


----------



## SirDice (Jan 22, 2013)

fonz said:
			
		

> Does seasoning with some salt (see same article) help?



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.


----------



## fonz (Jan 22, 2013)

SirDice said:
			
		

> It's better if nobody has access to the password hashes in the first place.


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.


----------



## SirDice (Jan 22, 2013)

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.


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


----------



## fullauto (Jan 22, 2013)

*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?


----------



## fonz (Jan 22, 2013)

fullauto said:
			
		

> Any suggestions on reading to help me impli[red]e[/red]ment this?



There's a section on Kerberos in the Handbook. It's a bit brief, but it should be enough to get you started.


----------



## gordon@ (Jan 23, 2013)

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.


----------

