[Infrastructures] user management (mixing afs,ldap,kerberos)

[Joel Huddleston]

Quoting Rudy Gevaert <rgevaert@elis.ugent.be>:

[deletia]

> A better option is AFS.  And I'm now trying to get that to work.  But
> for AFS you need Kerberos.  And if I'm correct you still need
> something like NIS or LDAP (let us use LDAP).  How can you now easily
> manage Kerberos and LDAP?  For each LDAP user you need a Kerberos
> principal, right?

It sounds like you are trying to wrap your mind around Kerberos and some
slippery pieces are leaking out. Don't worry; this is not uncommon. I will do my
best to describe, as I understand it, how NIS, /etc/passwd, /etc/shadow, LDAP
and Kerberos are related and unrelated.

The combination of /etc/passwd and /etc/shadow answer a lot of questions related
to user accounts. Fundamentally, the most used part of the passwd file is NOT
the password, it is the username->uid mapping. Your password is only needed to
log in, but literally everything you do in UNIX requires your uid. When you want
to do something in the UNIX world, two essential questions must be answered:
"Who are you?" and "Now that I know who you are, are you allowed to do that?"
Most of the time, "Who are you?" is answered, for local access, with your uid
or, less commonly, gid. The trick in this comes when you wish to acces a
non-local, or network asset.

In the case of access to network resources, your uid or gid is not enough to
identify you and in any case is untrustworthy for that purpose. There are large
tomes out there that explain that last sentence better than I can. NIS and NFS
depend on a certain trustworthiness of uids. For this reason, they are
inherently unsecure.

Back to answering the next question, "Now that I know your are usernumber 55,
can you do that?" is usually answered by inspecting permissions bits in a file
inode. If you are the owner of the file, the owner bits are important. If you
are not the owner, but belong to the group of the file, the group bits are
important. In any other case, the other bits are important. So the system either
gets a "Yes" or a "No" response to your access and that is all.

With NIS and with the /etc/passwd,shadow files and some implementations of LDAP,
the question of "Who are you?" is answered in the same system as "What are you
allowed to do?" When you throw Kerberos in the mix, the question of "Who are
you?" is answered by Kerberos. Kerberos doesn't get into the details of whether
or not you are ALLOWED to do what you are trying to do. It just answers the
first half of the pair of questions.

So, if you are going to use Kerberos, you need something else to answer the
second question. That something else can be LDAP, Hesiod, NIS or even
/etc/passwd. These databases include the username->uid mapping that is needed
for local access along with fiddly little details like login shell and home
directory. Kerberos has NONE of that. To Kerberos you are two things and two
things only: your principle name and your password. (Don't get excited, yes I
know that there is also expiration time and policies and those sorts of things,
but they are all intimately connected with the password and have nothing to do
with an account.)

In answer to your question above, you need a Kerberos principle if you wish to
AUTHENTICATE.  UNIX requires that you have some form of /etc/passwd entry in
order to be logged in. Not every principle needs an /etc/passwd entry. A good
example of this are the principles that you use to admin the Kerberos database
itself. There are also host and service principles that do not have /etc/passwd
equivalents. You might also have an /etc/passwd entry for which there is no
principle. A good example of this is the "mail" account.

So, you don't need a principle unless you intend to authenticate and you don't
need an /etc/passwd entry unless you intend to own files or log in.

--
Joel Huddleston
eka joelh@cyberzod.com
"Try going to your local middle-school chess club, hand out crystal
meth and guns. That might be good practice." -- Pvt. Church ( when
asked how to prepare for ones first exposure to the Internet.)