[OpenAFS] AFS+KRB5+LDAP users management

[Marcus Watts]

Lukas Kubin <kubin@opf.slu.cz> writes:
> Is there a solution to help administrators do the users/groups management
> on site running $SUBJ?
> Now, when I do changes to any users' account, I have to do them on many
> places. Ie. in AFS protection server and others., Kerberos principals and
> LDAP user records.
> Do I really do it this way? Is there any tool simplifying this task? Or
> everybody running such site writes his own sync tools?
> Thank you.

Charles Clancy <security@xauth.net> replied:

> There is no magic tool.  Everyone has their own custom scripts for user
> management.  Others have created web interfaces for account management.
> 
> You could always use a Microsoft's Active Directory Server for your krb5
> and LDAP server, and then you'd have a nice GUI for most of the user
> administration.

Here at the University of Michigan, we use uniqname to for much of this
sort of thing.  The uniqname server does the synchronization, and
various tools that may be run from the command line, via web
interfaces, workstation gui interfaces, batch processing, or indirectly
via other services, sometimes by the user, departmental, or other
people interact with the uniqname server using UDP or RX.

People here would find a tool that only gave system administrators
access to change things via some not easily scriptable GUI to be pretty
nearly useless for most of the user administration things that get done
around here.  Way too many users, not enough centralized IT staff to
make such a thing scale.  It's much more important to us to have a
distributed tool that can mainly concentrate on authorization and
policy issues and can be used by other tools in turn.

I believe there are some perl modules that provides a low level
interface to afs (pt) & ldap at least.  Something similar for mit k5
kadm5 wouldn't be hard, although there are some nuisance issues.

It does seem to be rare to find more than one independent site that
shares any sort of common administrative code.  Everyone seems to have
their own idea how this should be done.  Hard to say if that's all
"NIH" (not invented here) or because the complexity of using a truely
general purpose solution would equal the complexity of using a
localized homebrew solution.  Many people do seem to have their own
strong opinions about how such things ought to be done.

				-Marcus Watts
				UM ITCS Umich Systems Group