[TUHS] YP / NIS / NIS+ / LDAP
Arthur Krewat
krewat at kilonet.net
Tue Nov 6 02:12:19 AEST 2018
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/5b3621a2/attachment.html>
More information about the TUHS
mailing list