6 Nov
2018
6 Nov
'18
11:24 a.m.
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(a)GAJENDRA.NET <mailto: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.
*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