[TUHS] YP / NIS / NIS+ / LDAP

[Grant Taylor]

On 11/05/2018 03:34 PM, Dan Cross wrote:
> You can use a modified `login` that will validate you against a KDC.

ACK

> The way it works is to set up a host key for the host you're logging 
> into; that is then used to authenticate the *host* to the KDC, which 
> then allows it to validate a user against the KDC and issue the user a 
> TGT at the same time. This works well for e.g. console and X logins.

That makes sense.

> Modifications have been made to e.g. SSH so that one can authenticate an 
> SSH session via GSSAPI, which usually wraps Kerberos. If I recall, 
> GSSAPI might be one of the lasting legacies of the DCE, though I may be 
> misremembering history.

*nod*

Generic Security Service Application Program Interface - The abstraction 
layer that (as far as I know) only had one service behind it.

> Security, in general, usually seeks to address five questions:
> 
> 1. Authentication - Is some entity who it claims to be?
> 2. Authorization - Is some entity allowed to perform some action?
> 3. Privacy - Can a third party snoop on a private conversation between 
> two entities?
> 4. Integrity - Can a third party alter communications between two 
> entities in an undetectable way?
> 5. Non-repudiation - Can it be definitively shown that some entity was a 
> party to some communication?

The 3rd A that I'm used to is "Access Control".  Is the requested action 
allowed given the above information.

> Kerberos is a authentication protocol.
> 
> LDAP, YP (retroactively named NIS after a lawsuit involving, I believe, 
> British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all 
> examples of directory services. To a first-order approximation, one 
> might think of a directory service as providing an oracle allowing one 
> to discover what entities exist in some domain.
> 
> Authentication protocols and directory services solve different 
> problems. Though in true Micro$oft-of-old fashion, AD sort of merged both.

I would argue that a directory including shadow information (like 
NIS(+)) does both too.

> Kerberos solves the authentication problem, but does not provide a 
> directory service nor does it solve the authorization problem (though 
> some "kerberized" services could use a library to consult a 
> user-provided file of ACLs mapping principals to privileges). On Unix, 
> "authorization data" includes things like your UID and the set of groups 
> you belong to (or more precisely, your process's UIDs and GIDs/groups). 
> Kerberos provided support for privacy via encryption libraries, and it 
> provided support for integrity via hashing/checksumming/signature 
> libraries. "Kerberized" versions of network services such as telnet, 
> FTP, rsh/rlogin/rcp etc all provided support for authentication via the 
> baseline Kerberos protocol as well as privacy and integrity via 
> connection-level encryption and checksumming.

I was not aware that Kerberos could provide privacy (encryption) for 
kerberized services.  I (naively) thought that Kerberos was 
authentication that other things could use to make access control decisions.

> Kerberos provided a replay cache, but otherwise provided only limited 
> support for non-repudiation via mutual authentication through the 
> KDC (that is, clients authenticated to servers, but servers also 
> authenticated to clients).

*nod*  I think NT4 domains and AD both had the same type of client to 
server mutual trust.  (At least for NT derived clients with machine 
trust accounts.)

> So while a KDC might tell you whether the principal connecting to your 
> SSH service is really "cross at GAJENDRA.NET <mailto:cross at GAJENDRA.NET>", 
> it won't tell you your UID, what shell you use, the path to your home 
> directory, what groups you are a member of, or what finger should say 
> for your real name.

*nod*nod*nod*

That's why the directory component is so important.  Somewhere to get 
all that other information.

> In its pure form, SSH provides support for limited authentication (via 
> public key cryptography and the wide distribution of public keys) and 
> limited authorization (via the `authorized_keys` file), privacy and 
> integrity.

I think that OpenSSH's certificate support extends that a bit.

> LDAP might provide you some mechanism to look up a user record that 
> provides those details; it may also provide some kind of hashed password 
> that a system can use to validate a password, but it won't do much 
> better than that. I suppose you could put an authorized SSH public key 
> into an LDAP directory in the same way you would put a hashed password.

I've always viewed LDAP as a directory that can have various content in 
it.  It then makes this content relatively easy to access.  What the 
content is is up to the content consumer.  Be it names, email addresses, 
shells, or password hashes.

> NIS was based on Sun RPC; as was mentioned earlier, anyone on a network 
> could bind to an NIS server and query it to get e.g., hashed password 
> file entries that they could run crack against. Nothing was encrypted.

Even if communications with the NIS server was encrypted, I'm not 
hearing anything that prevents an authenticated user from enumerating 
NIS.  Even if it was over encrypted channels.

> There was a system for a user to update his/her information in the NIS 
> database (e.g., this was how you changed your password or set your shell 
> or updated your office phone number...), but the "authentication" was 
> just checking your password; again nothing was encrypted, so a malicious 
> third party on your network could in theory mount a man-in-the-middle 
> attack against you and inject his/her own data into the transaction and 
> take over your account.

ACK

> NIS+ improved on this, but wasn't universally supported across systems 
> and we lost some useful NIS functionality: back in the NIS days, you 
> could supplement the contents of /etc/passwd with the NIS passwd maps, 
> but keep local overrides (e.g., for anyone not in the `@staff` netgroup, 
> set shell to `/sbin/nologin` on servers); perhaps there was a way to do 
> this with NIS+ but it felt very much like a binary thing: you were 
> either all in on NIS+ or not at all. Mixing and matching just wasn't as 
> easy as it had been. Also, the symmetric crypto was, I think, DES based 
> and as that fell apart I don't recall it getting much better. So unless 
> you were all Sun based (and many of us had heterogenous systems to worry 
> about; my shops supported Suns running SunOS 4 and Solaris 2, SGIs 
> running Irix, HP-UX machines, Alphas running OSF/1 then DEC Unix then 
> Tru64, DECstations running Ultrix, RS/6000's running AIX, RTs running 
> AOS, a few NeXTs, PCs running Linux *BSD and PCs running Windows and 
> Macs. Oh, and VMS on VAXen and Alphas. Yay. Elsewhere on campus we had a 
> mainframe running VM/ESA, a couple of Crays, some AS/400s; we also had a 
> few plan9 machines. We even had a PDP-10 running TOPS-10 at some point. 
> Good ol' YP cut across the widest swath of these so that's what we ran 
> the longest, but it was a more innocent time, network access was more 
> tightly controlled and it wasn't quite as dangerous to run something 
> like ypserv.

*nod*

> I thought for a while that LDAP would be the light and the way, but it 
> was really a lot more general than what I cared about just for Unix 
> system administration. Setting it up wasn't as easy as NIS, or even NIS+ 
> for that matter.

That's what I've gathered from a number of sources.  Which is why I've 
heard people avoid LDAP directly.  Or at least use something like 
Samba+Winbind or SSSD as an abstraction layer into LDAP+Kerberos.

> Netinfo came from NeXT and survived into Macos for a little while. It 
> was kind of neat but again the all-singing, all-dancing solution to the 
> world. No one else really used it.

Typical.

> Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed 
> the need for a directory service on DNS, which is already a distributed 
> directory service. You embedded relevant data into DNS TXT records, so 
> imagine doing a DNS query to look up a user's /etc/passwd entry: after 
> all, DNS already scaled and was well-proven Internet-wide. I don't know 
> that anyone ever really supported it, though.

I know that Red Hat Linux did have support for it.  One of my colleagues 
was a Hesiod maintainer for a while.

> So yeah. Kerberos is plenty fine for authentication for small to medium 
> sites (up to mid tens of thousands of users, I'd guess), but won't help 
> you distribute your authorization data. You need a directory service or 
> some other mechanism for that. Directory services will help you with 
> that, but usually don't do a great job at authentication, though they 
> may provide the means to distributed the data that other systems can use 
> for that. Of the directory services out there these days, LDAP seems to 
> have "won".

(Raw) LDAP and AD seem to be what I see the most of.  I've worked in a 
few shops that evolved their NDS into eDirectory with appropriate 
clients for other platforms.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/05a4fe0b/attachment.bin>