Re: [TUHS] YP / NIS / NIS+ / LDAP

[Arthur Krewat <krewat@kilonet.net>]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

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.


[-- Attachment #2: Type: text/html, Size: 2275 bytes --]