[TUHS] YP / NIS / NIS+ / LDAP

[Dan Cross]

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

> On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> > Let the client handle authentication via Kerberos
>
> I don't know enough about Kerberos (yet) to know if it would be possible
> for a login process to communicate with the KDC and get a TGT as part of
> logging in, without already being logged in.
>
> My ignorance is leaving me with a priming problem that seems like a
> catch 22.  You can't login without shadow information or TGT.  But
> traditional (simpler) kinit is run after being logged in.  So ... how do
> you detangle that?  The only thing that I can come up with is that the
> login process does the kinit functionality on the users behalf.
>

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.

I can see how NIS(+) sans-shadow could still be useful.  I can also see
> how LDAP could be a close approximation / replacement for NIS(+) in this
> case.
>

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/1232b935/attachment.html>