rights management

[Michael Fair]

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

It's good to hear I'm not alone and that I
really am understanding Kereros' specific/limited
role in the system.  Thank you very much for your
clarifications and comments.

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


No, it's not necessarily a problem, but to follow the analogy,
the door makers have a standardized hole size for deadbolts
and door knobs, and key and key ring manufacturers have agreed
that there should be a hole in the key so that end users can
put their keys on key rings to help manage them and the hinges
on the doors are standardized heights in the door frame for
hanging them.

The point I'm driving at is that is that while I see no
problem for Kerberos being just an authentication platform,
some standardized methodology for creating an entire IAAA
environment that utilizes Kerberos should be developed.

For instance, if the KDC is only going to provide Authentication
information, then perhaps the KDC should not be treated as
the authoritative source for principals.  Perhaps instead
some other system should be used as the authoritative source
and Kerberos is an authentication service within that
other system (perhaps not all principals need authentication,
they just need identification) and the KDC should actually
query this other system to verify a principal exists and
is authorized to be authenticated (AKA the account is active
and not disabled).  Further, the Kerberos standard should be
extended and presented in such a way that it expects to be
subordinated to some other larger authorization system.

It seems to me that Authentication is merely the first step
in an Authorization scheme.  I cannot think of a time where I
would care about the identity of a principal outside of the
case where I am trying to authorize them for something.  It
seems to always be the case that before you go checking whether
or not this principal is authorized, you need to find out if
this principal is who they claim to be and the only time you
care about this person being who they claim to be is when you
are about to go find out if they are authorized.

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

But for this to be effective all my other applications would
need to use an agreed upon authorization method for storing
data into authorization backend wouldn't they?

I mean I suppose each app could just roll their own, but
then we've each application having to make their own storage
formats, no standardized way for creating easy admin tools
where users/groups can be listed and shuffled around.

You get the potential for separate identifiers since one
app decides it's going to use the UID of the principal
where another app decides it's going to use the fully
qualified kerberos ID DOMAIN/principal and yet another
app decides just to use the local principal name, and
yet some other app developed by a guy who really hasn't
figured it all out yet decides to use his own principal
names requiring a mapping scheme to be set up because
he had no tools for testing existence/status of principals.

Further, everyone of them either uses the local Unix
group ID or ends up rolling their own group methodology
so none of the applications can take advantage of a
centralized set of groups.

I really hope I'm completely wrong here and have misunderstood
something really basic and important that makes none of
the above true.  I've seen people say "just use LDAP" but
I don't think any of them have actually set up fine grained
controls where their Kerberos principals can be put into
groups and where the same set of principals/groups can be
granted/denied permissions to print to specific printers,
access certain directories on filesystems, access certain
network file shares, access certain folders in the IMAP
mail store, and access other services (web/ftp/etc) in a
centralized way where if a principal is added/removed from
the system (or even just added/removed from a group (if the
service even supports groups)), the administrator doesn't
have to go to every single service and tell it that the user
now exists, or no longer exists.

Sure if you remove the user from the KDC they can no longer
get a ticket for the services, but the ACL information
(aka cruft) is still there.  God forbid a well ACLed employee
should get married and change their principal name.
It'd be great if the administrator could just go in and
say "principal X is now known as principal Y and principal Y
principal X is now an alias for principal Y" - but those
kinds of semantics don't seem to exist in the current schemes...
(Granted that in my example simply adding an alias to the
 existing principal would be easier,  but that's not always
 the case.)

Am I really missing something or is this really the current
"state of affairs"?



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

Right, it's that "(with the OS providing a general access-control
framework)" piece that I can't find an Open Source equivalent of.
Some people have suggessted that a system _possibly could_ be
implemented using PAM, but no one seems to really know exactly how.



> > 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.
<snip>
> Of course the service needs code which can do this.

And it still doesn't seem to do anything other than
a Boolean yes/no (as opposed to read/write/execute
for instance), or it has to provide it's own principal
tree and manage yet another independent copy of each
principal that it has a special ACL for (making
adding/removing/modifying principals a major PITA).

I suppose this also reinforces my earlier semi-conclusion
that Kerberos should really just be viewed as an authentication
service within the domain but that even it is a subordinate
part to a larger authorization system.



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

OSS also saves a poor guy like me from having to pay $900 to have
a home network based on linux. ;)

Well for the time being I decided to skip on stuff like automatic
service announcement/discovery and the Windows registry where you
can have per user/per application/per machine/per domain type
configuration options stored.
I'm also not trying to build something interoperable with MS AD
(I'll leave that for the brilliant folks over at the Samba project).

I'm just a relatively new guy to Kerberos who was expecting an
Authorization system to compliment the authentication system
but all I've found so far is that each application has to do
a "roll your own" authorization scheme.


I guess the worst part is that I feel like I'm whining,
complaining, or otherwise just stupid because the need
seems so obvious to me that I'm assuming that it just
has to be there because I know I'm not the first one
to bump up against this problem.  I can live with whatever
the "state of affairs" is, I might even be able to help
contribute to some project to help improve things, but
at the moment, I feel like I don't really know what the
authoritative "state of affairs" in regards to standardized
Kerberos compatible Authorization schemes is.


Thank you very much for your support/responses.  I truly
appreciate them and am supplementing what I've learned so
far with them.  So I am learning here and hope that I can
get that understanding of what the options/state of affairs
is so I can move forward rather than wandering around in
a state of confusion.

-- Michael --