RE: LDAP/Kerberos user management

["John Green" <green@blueheronbio.com>]

Hi Marcus --

I'm definitely interested in your "uniqname" implementation.  I'm not sure
if the portability issue is a factor, but just as background info I'm
running MIT Kerberos 1.2.2 and openldap 2.0.23, RedHat7.2.  If you would
like to share this software, I'll be glad to do a little testing for you.

Thanks  --  John

-----Original Message-----
From: Marcus Watts [mailto:mdw@umich.edu]
Sent: Thursday, August 22, 2002 10:18 AM
To: Kerberos (E-mail)
Subject: Re: LDAP/Kerberos user management


"John Green" <green@blueheronbio.com> writes:

> Hi, I am trying to find a method for a principal automatically being
created
> in a Kerberos database while at the same time adding a corresponding entry
> to an LDAP database.  Has anyone heard of or is anyone using something
like
> this?  I have found some utilities for sale on the web (some might even
> work), just looking for alternatives.  I am trying to automate the
creation
> of username/password/ldap_entry/Kerberos_principal/customer_web_site,
which
> the customer will be able to accomplish without IT intervention from a
> common web site.

The usual solution for this would be to write some sort of special
purpose logic to do it.

Some ldap server implementations have back end hooks that could be used
to push directory information out to other servers.  That would work
for for populating principals.  That won't be directly helpful for
setting the password though.

There are a number of different kerberos implementations out there,
each of which has their own special unique administrative interface.
The interfaces are different enough that it would be hard to write
portable stuff to run on top of them.  Perhaps even more critically,
generally every organization thinks they have their own unique needs
for how entries are created, maintained, and deleted, and most
organizations are small enough that various ad hoc methods suffice.

Here at the University of Michigan, we have long used "uniqname" to
handle many of these problems.  Uniqname is a central server that
interfaces to kerberos, afs, and several external directories including
ldap.  Uniqname in turn distributes administrative rights - a uniqname
administrator works on behalf of some group (typically a department)
and has the right to create uniqnames on behalf of that group, and to
reset passwords for for that group, but not for others.  A uniqname is
per-individual not per-department, people who have multiple
affiliations can have a lifetime or "interest" set by more than one
group, and the individual can designate which groups they trust to
reset their password.  By default, a department that sets a lifetime
has no rights, so a rogue department can't just set a lifetime on every
uniqname on campus and steal everyone's identity.

Uniqname was originally designed to solve the distributed
administration problem, but today, we also use it to deal with
propagating directory information out to several services, including an
ldap directory.  Uniqname does not directly solve the "handing new
accounts out to people" problem, but it's obviously involved in the
process and, by virtue of being a real-time on-demand client-server
application, it definitely facilitates doing this kind of stuff.

Having a uniqname is only one part of what people traditionally think
of as a "computer account".  There are generally also authorization
issues (and we're working hard to train people to realize that having a
uniqname does not in itself mean "a current staff/student"), funding
issues (do they have the right to use national dial-up services?), an
email mailbox, and other resource issues (do they get an AFS home
directory?).  Actually, having an ldap directory entry is itself an
optional resource issue at UM, although in many ways it would have been
easier to define this as as something one has as long as one has a
uniqname (complicated internal politics, don't ask.)

We've actually had a number of different "front-end" systems in place
to hand out new uniqnames over the years.  At one point, most uniqnames
were being created by the sites monitors at the "campus computing
sites" using a special macintosh based client program.  At another
point, many uniqnames were created using a batch based process and
centrally supplied data.  Today, many uniqnames are being created using
a self-serve web server based front end (ie, upon admission, the
student pulls up a web page, supplies the appropriate initial
identification and authentication information, selects a password, gets
a uniqname, and receives computing services, including filespace,
email, and the ability to sign up for courses.)

I imagine you'll find virtually any large kerberos site has at least
some of the same problems, and very likely has tools that automate some
portion of account creation or management.  It is probably much more
common to have this run by staff as part of some batch process, rather
than run as an interactive real-time on-demand client/server type
application, though I'd love to hear of exceptions.  In general, I
think people have a very strong sense of "not invented here" about this
sort of stuff.  There are some very interesting genuine fundemental
security issues here, so, I don't know how much actual code sharing
you'll find.  We made uniqname available for a number of years, but
never found much excitement elsewhere over other places actually using
it.  We could certainly make what we're running today available, but it
would be pretty much on an "as is, has lots of crufty customization in
it" basis, because based on external demand we've found no reason to
worry about portability.

				-Marcus Watts
				UM ITCS Umich Systems Group
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
http://mailman.mit.edu/mailman/listinfo/kerberos