rights management

Mark H. Wood mwood at mhw.ULib.IUPUI.Edu
Mon Mar 3 09:09:16 EST 2003


"Michael Fair" <michael at daclubhouse.net> wrote:
> This is always one aspect of Kerberos that still
> confuses me and I was wondering if someone could
> clear it up for me.

You are not unique in this respect.

> In any given domain (domain.dom for instance), there
> will be a set of users and groups (similar to a
> Windows Domain).  If you are using a network
> authentication system like Kerberos, you are almost
> certainly trying to create a system where the
> definition of users and groups for your domain
> is centralized.

True.

> I agree that the services themselves are the best
> place to actually handle authorziation instead of
> just denying a ticket to the service, but from
> what I can tell there's no way for the service
> to consistenly attach/hook in to the KDC principals
> list, and from what I can tell Kerberos V doesn't
> support any kind of group creation mechanism.
> 
> Is Kerberos destined to remain just an authentication
> architecture and designed to just be part of some
> other system when it comes to the needs of most network
> environments in regards to user/group/service management?

Would that be a problem?  Why?  We don't have a problem with the fact
that the people who build our locks don't also build our doors and
walls.

> For instance, I have IMAP email, file servers, printers,
> ftp servers, LDAP servers, and client workstations.
> Each of these systems could benefit from associating
> Access Controls to Kerberos Principals, but from
> what I can tell Kerberos provides no standardized
> way for those services to get help in managing those
> ACLs from the Kerberos system.

Directory services play very well with Kerberos, and are designed to
provide storage for groups, access control, etc.  If you have LDAP
running, you have a directory server and that is one good place to
centralize authorization.

> I guess all this means is that I end up agreeing with
> the MS AD and DCE camps that believe a truly useful
> system is going to provide all of Identification,
> Authentication, Authorization, and Accounting systems.
> (Accounting = logging / tracking who is using what)

Notice how Microsoft's AD does it:  authentication is done using
Kerberos, attributes of principals are kept in a directory and served
up via LDAP, and authorization is the responsibility of each object
type (with the OS providing a general access-control framework).  (The
accounting bit is kind of mysterious and haphazard but can be made
useful.)

> Are there any Open Source solutions for implementing
> a total package solution (where total package is both
> Authentication and Authorization - I'll figure out
> the others later)?

A number of people are using Kerberos+OpenLDAP.  Services can be made
to piggyback on the directory's authorization mechanism:  client
presents a proxiable ticket for the service; the server probes for
access to the directory object which represents it, using the client's
ticket; if the directory grants access to the server object then the
service grants access by the client.  (I have *not* done this myself
(yet!) so I could be mistaken about some aspects of the process, but I
think the basic idea is sound.)  Of course the service needs code
which can do this.

It's possible to use OpenLDAP alone, if you don't mind depending on
exchange of plaintext or hashed passwords (perhaps wrapped in a TLS
session, but then you need OpenSSL or something like it).  Adding SASL
gives you a few more options (and one of them is the way to integrate
Kerberos 5, via GSSAPI).

> Assuming there is a simple solution, please forgive
> my fustration.  I thought it would be a relatively
> straight forward process - use Open Source tools to
> build an MS AD like infrastructure.... I've just
> been bumping into road blocks all over the place,
> most of which are centered around no centralized
> system for authorization data storage/retrieval.

Building something vaguely like ADS is not too hard, but there are a
lot of separate pieces.  Building something interoperable with ADS is
a much larger task, but even that appears doable.  The OS advantage is
that you get to *see* how your system is secured and managed, instead
of depending on a magical black box.

-- 
Mark H. Wood, Lead System Programmer   mwood at IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".


More information about the Kerberos mailing list