On 11/5/2018 2:24 AM, Mantas Mikulėnas wrote:

I'd like to hear more about the security issues.

Did NIS(+) ever encrypt it's communications?  (I'm not counting things
like IPsec transport.)

I'm fairly certain that it was possible to enumerate the directory or
otherwise scrape most (if not all) of it's contents.

There was `ypcat passwd`, wasn't there?

It was possible, unless you used a network filter on the server, to just ypbind to the server, and then you could ypcat all the maps. Not to mention that without specifying a server, it was a broadcast. So any YP server on the subnet would answer.

NIS+ was encrypted over the network, and needed a public key mechanism to authenticate clients. One of which was the server itself. With it's hierarchical architecture, it had a lot of flexibility.

I really never understood why people didn't like NIS+. It took an extra step or two to do certain things, but once scripted it was a fairly secure way of handling authentication and directory services. I added new maps to it to do custom .cshrc/.profile scripts using subsections in /usr/local/profile, and a few other customizations. Add it's compatibility mode for NIS/YP, and you could use it to serve not only Sun clients.

Operationally, it really was just NIS/YP but with a lot of whiz-bang features. In a deployment of a few hundred mechanical and electrical engineers, with about 50 actual workstations and servers I never had a problem with it. Permissions and other features were actually quite useful.

However, I must say, I kept the NIS/YP way of using flat files to regenerate the NIS+ maps each time they were edited. So I guess I cheated a little.

art k.