On Mon, Nov 5, 2018 at 4:00 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:

You can use a modified `login` that will validate you against a KDC.

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.

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.

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?

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.

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. 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). So while a KDC might tell you whether the principal connecting to your SSH service is really "cross@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.

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.

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.

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

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.

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.

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.

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.

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

        - Dan C.