[OpenAFS] converting Kaserver and protection server to working with LDAP

[Marcus Watts]

Eddy Czitrom <Eddy.Czitrom@ness.com> writes:
> I am currently working on a project based on OpenAFS for Linux, and one of
> our goals is to make OpenAFS work with LDAP for user management.
> The general idea is to change the user management methods in the kaserver
> and protection server like addUser,deleteUser etc. to corresponding LDAP
> functionality.  
> I am concerned about the possibility that by doing so I will damage other
> abilities of the OpenAFS or impair its stability.
> I welcome any comments that can illuminate this issue.

Leif Johansson <leifj@it.su.se> wrote to info-afs 14 March 2001 asking
for something much like this, and this is what I wrote back then:
 
> In no particular order, here are some of the issues that might
> arise:
> 	efficient replication (not sure how this works in openldap)
> 	Openldap tracks groups in groups by DN, so changing names
> 		is *real* painful.
> 	pt works with:
> 			keberos (k4) user names.
> 			group names (looks like either k4 names, or
> 				k4.name:k4.name)
> 			vice IDs.
> 		You'd need to map all of these into
> 		appropriate attributes.  Entries without
> 		viceIDs would lose.  [ Fileservers store viceIDs
> 		in acls. ]
> 	You'd have to provide a pt RPC (rx) interface, including
> 		especially getcps and friends.  That's what
> 		all the cache managers currently deployed expect,
> 		so if you want to play, you have to provide it too.
> 	Not sure how openldap performs under load.  Performance
> 		could be an issue.

I was wrong in the above in that the cache manager itself doesn't
talk PT.  Lucky you.  However, the cache manager does know about viceIDs and
ACLs, expects there to be a 1-1 mapping between AFS viceIDs and Unix
UIDs, and expects ACLs to contain a list of viceIDS (which are actually
manipulated using the "fs sa" and "fs la" commands.)  Breaking this means
you won't be compatible with vanilla AFS (interoperability may be
a problem.)

Basically, your ldap directory is going to need to contain the following
attributes:
	name aka "kerberos name".
	ViceID aka UID
	many-many relationship between user viceIDs and group viceIDs.
and the following operations:
	pr_NameToId
		map name to ID
	pr_IdToName
		map ID to name
	pr_GetCPS
		given ID, map into list of group IDs (and userID)
		one is or is a member of.
Users and groups share the same name and ID space.
ptserver gives groups negative viceIDs; I don't know if openafs
knows this.  There are more operations - which you should support if
you also want the AFS "pts" command to work.

You have several basic plans: you could teach fileserver how to talk ldap
natively, or you could (as Sam Hartman <hartmans@MIT.EDU> suggests)
write a ptserver to ldap translator.  In theory, either will work,
since the cache manager doesn't make any PT calls.  However, a pt
translator does mean you could run vanilla fileserver code, which
could be very help in terms of not introducing new instability issues
by mixing libraries which may not "play nice" with each other
("libdes.a" is a good example - try building one binary that uses
ssleay, transarc afs, and MIT k5 1.0)

One basic issue: ldap uses TCP.  PT uses RX.  Threading may be
interesting, especially at start-up when doing name resolution
and ldap bind.  TCP has more start-up overhead, & interesting limits
on the number of simultaneous connections allowed.  If you botch
things badly, the filserver will appear to mysteriously hang as
calls to ptserver stall.  This is bad.

Changing DN's in openldap is real painful.  Russ Allbery <rra@stanford.edu>
recommends that you not include any user visible names in the DN.
At Stanford, they apparently use a machine generated unique ID in the DN.
Possibly the viceID could work in DNs.

Here at UM, searching for all the groups of which a user is a member is
"expensive" - ie, it's slow.  I am not sure how this is stored inside
openldap, but this could be a crucial performance bottleneck, because
the fileserver likes to do getcps a lot.

A completely different way to go might be to provide an ldap front-end
for ptserver & kaserver.  There are some obvious nasties to sort out
in terms of authentication and security.

If you're thinking of replacing kaserver with openldap, my first
thought would be to use k5 instead.  You don't want to stay with
DES anyways, so you really shouldn't be deploying new DES-only code.

There is an interesting opportunity or pit-fall (depending on how you
look at it) with K5.  K5 provides an "enc-authorization-data" field in
the ticket.  DCE and MS both use this (I *believe*) to store the
equivalent of "getcps" info.  This can save work for the fileserver
because it can just grab it from the ticket and doesn't need to ask
ptserver.  MS's implementation is evil because it's undocumented (or
may as well be, rumour has it you can read it if you first sign
something promising not to use it.)  An additional evil is that by
storing authentication and authorization data in one single big
monolithic database, it becomes a complex and vulnerable target which
is impossible to prove secure.  DCE's implementation is probably less
evil, but makes it impossible to use a vanilla MIT K5 server (which has
no hooks to generate authorization data.)  If you're insisting that
you use ldap to store passwords & group membership, you may not be
bothered by not being able to use a vanilla MIT k5 server.

				-Marcus Watts
				UM ITCS Umich Systems Group