<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<body text="#000000" bgcolor="#FFFFFF">
On 11/5/2018 2:24 AM, Mantas Mikulėnas wrote:<br>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">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.
<pre wrap="">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. <br>
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
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.<br>
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
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.<br>