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

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

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

On 11/06/2018 03:24 PM, Dan Cross wrote:
> Isn't that authorization?

Not really.

Authentication is proving that you are who you claim to be.  -  Show 
your drivers license to the bouncer.

Authorization is deciding if the authenticated entity is allowed to have 
access or not.  -  Is your name on the list of people allowed into the 
nightclub?

Access Control - The bouncer, allowing you in or physically barring you 
from entering.

Each is a discrete function.  They all work in close concert with each 
other.

> Not really. It provides the data that lets one perform a relatively weak 
> validation of e.g. a password, but it is not *itself* an authentication 
> protocol.

Fair enough.

> Older versions of Kerberos often included modified versions of popular 
> servers and their clients that had been modified to use the kerberos 
> protocol for authentication, and also often to encrypt communications.

I take it that you mean that the Kerberos software that was distributed 
also included an alternate telnet / rsh / etc daemon that took advantage 
of Kerberos.

> For example, the version of `telnet` that shipped with MIT kerberos back 
> in the day had an option that could be used to encrypt the data stream; 
> similarly with rlogin, et al.

*nod*

> I have a dim memory that the version of FTP might support encryption 
> for the control connection but not data connections (but I also might be 
> purely imagining that).

Maybe.  There has been a LOT of energy put into FTP.

> I'm guessing most of this stuff has been dropped from more recent 
> distributions

Likely.

> because...really...telnet?

~chuckle~

I supported multiple old Solaris 6 machines about 5 years ago that I 
still had to use telnet to connect to.

I feel like telnet as a service REALLY does need to go away.  That being 
said, I still find the telnet (or any NVT) client a valuable diagnostic 
tool.

> What I meant is that SSH supports a limited sense of checking whether 
> a given key matches and making a yea or nay decision based on that.

I'm not sure I understand what you're alluding to.  But that's getting 
off topic.  So I digress.

> Correct. `ypcat passwd` often gave you a bunch of hashed passwords in 
> field two of a stream 7th Edition /etc/passwd formatted entries.

I would have hoped that there would have been some intelligence to only 
return the record of the person requesting the information.  Or that the 
password field was redacted for other users.

I guess the ypcat binary could be augmented to do that filtering client 
side.  But that still leaves the underlying problem there for alternate 
NIS clients.

> I have, again, some vague memory that at some point this was changed so 
> that root on the localhost could get a shadow-style map, but normal users 
> couldn't see the password hashes. But I might totally be making that up, 
> and of course, it wasn't robust security since what went over the wire 
> wasn't encrypted and breaking root on a host could still get you all 
> the hashes on the network.

It's still subject to alternate ypcat impersonation binaries too.

> Contrast with Kerberos, where breaking root on a host doesn't compromise 
> much beyond that host (modulo leveraging that to steal user passwords 
> and the like).

ACK

> Ha! That's a hoot.

;-)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]