MIT KDC & multiple admins for subsets of principals

[greg@enjellic.com]

On Mar 2,  8:58am, "Matthew J. Smith" wrote:
} Subject: MIT KDC & multiple admins for subsets of principals

Hi Matt, hope the day is going well for you.

>   We have roughly 70,000 principals in our KDC (MIT 1.4), including
> ~8,000 employees.  These employees belong to multiple
> departments/schools across the University.  We are looking to give
> access to the appropriate admins from certain departments to change the
> password for their subset of users.  This may mean that one admin should
> be able to change passwords for 30 principals, another for 400
> principals, etc, while our central IT should continue to be able to
> change all 70,000.
> 
>   The central case is easy, of course, using admin principals and ACLs
> of the form "*/admin at REALM *".
> 
>   There seem to be two approaches to give out access the way we want:
> 1)  A custom application (web) using an "all access" */admin principal
> to talk to the KDC.  The app controls individual access internally
> (perhaps using LDAP).
> 
> 2)  Generate a rather complex ACL file as part of our regular user
> provisioning, explicitly listing each admin principal and all the
> principals it has access to.
> 
>   I prefer keeping access control as close to the KDC as possible (#2),
> but would having such a large ACL file cause a performance hit (or other
> negative impact ?) ?

For the readers of the SASL/GSSAPI thread, a classic authorization
problem....... :-)

Given my druthers I would tend to mess with complicated ACL files as
little as possible.

I implemented a web-based strategy somewhat similar to yours a while
back.  I wrote an application in C which was used by a WEB application
to implement password changes by users for themselves as well as by
administrators for other personnel.

The application used our authorization system to make a decision on
whether or not the IID (external identifier) for the administrative
support person was authorized to execute password changes.  The
application is written against the MIT administrative API so its all
one binary which is attractive.

The authorization decision was yes/no but since it goes to LDAP to
answer the authorization question it would certainly be trivial to
return a multi-valued attribute containing the list of principals
which an administrator is allowed to modify.  Since you would be
granting departmental administrators full password modification rights
you would need to block their access to kadmin facilities directly if
you wanted absolute control over their actions.

You are certainly welcome to the code if you would like to use it as a
starting point.

You had indicated a desire to be close to the KDC.  I can also offer a
somewhat more powerful approach in that venue.

I wrote a plug-in architecture for the MIT krb5kdc/kadmind system
which allow them to be functionally extended with shared library
plug-ins.  The kadmind plug-in currently implements storage of raw
passwords, ala AD, within the database.  It wouldn't be a stretch to
implement a hook within this framework to poll LDAP for a list of the
identities which a principal with administrative rights could execute
changes against.

Its a bit more invasive but certainly the most correct approach.  I
could even be tempted to spend a bit of time on this if there was some
interest in it.

> Any feedback is appreciated - thank you,
> -Matt

Hope the above is helpful.

Good luck with your project.

}-- End of excerpt from "Matthew J. Smith"

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"Samba was detected as "Samba" by WinNT 4.0 Workstation and PageMaker 6.5
was slow like hell. Now I managed to have it detected as "WinNT 4.1 Server"
and it's much faster."
                                -- (Ein Schelm, wer Boeses dabei denkt)