On 11/05/2018 09:12 AM, Arthur Krewat wrote:
> 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.

Duly noted.  Thank you for the explanation.

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

The encryption would thwart snooping.  But it doesn't sound like that 
would prevent a properly authenticated client from ypcating too much 
information.

> 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've heard a lot of people say they don't like something when they had 
something else that did what they needed / wanted (at the time) that 
required less work.  Occam's Razor / Parsimony....

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

Nice.

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

ACK

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

Work smarter, not harder.



-- 
Grant. . . .
unix || die