Ldap+Nfsv4+kerberos *nix / *bsd puzzle. - openldap-technical

29 Nov 2011


      Hello group!
Looking for guidance on an ldap+NFS4+Kerberos puzzle in a mixed OS local 
environment.
Simple demo case, four computers on a little net.
box 1: Running openlap server, kerberos KDC, kadmin, lets say it's 
running freebsd, doesn't matter.  nfs server & client.
box 2: Linux box.   nfs server & client.
box 3: *bsd/Solaris box.  nfs server & client.
box 4:  misc user box, could be *bsd or *nix.
Networking:  Nfs4 secured with kerberos.  That means  No uid/gid numbers 
on the wire, only user@box.    NSS is active on all boxes, reaching out 
to the ldap server on box 1 for info for what is not in the local passwd 
file searched first.
Popular package X gets installed on box 2 and box 3.  Package X is a 
drop-root privilege package, has its own uid/gid!=0.  It is active on 
the net, might write log files or get data files via nfs on either of 
the other two computers in the setup.   The maintainers for package X in 
the *bsd world have chosen a different number for the uid / gid for the 
package X daemon than the maintainers for package X have chosen in the 
*nix world.   Those get written in the local passwd file on each system 
at package X install / download time.
Note:  Package X does _not_ get installed on the ldap server box #1, or 
box #4.   There is no entry in the #1 or #4 system's passwd file for nss 
to find for the daemon associated with package X.  nfsuserd via nss must 
find the package X user in ldap or the files will be unreadable or seem 
'owned' by nobody:nogroup on 1 or 4 if say config or log files 
edited/accessed from there.
Puzzle:  What should the posixAccount uidNumber and gidNumber value be 
in ldap for uid=packageXdaemon?
Alternatives:
1: Choose no entry, leave it out of the ldap db:  PackageXDaemon's files 
will be owned by nobody:nogroup on box 1.  Security Fail.
2: Choose  *nix for the uid/gid in the ldap database on box 1.  Fail:  
The files will be stored with a uid/gid that might collide with another 
account in the passwd database on the *bsd server.
3:  Choose *bsd for the uid/gid in the ldap database on box 1:  Fail: 
The *nix user on box 4's nfsuserid will get the bsd uid/gid from ldap 
which could create files not actually owned by something colliding in 
the *nix passwd database on box 4.
4: Instead storing all the users once under an ou=Account...  create 
ou=AccountBSD and ou=AccountNix, duplicate the whole account tree but 
vary the apropos uid/gid pair under each tree with all the other 
remaining equal, manage collisions when amending the database.   Not so 
pretty.
5: Edit the schema to replace uidNumber and gidNumber with uidNixNumber 
/ uidBsdNumber & etc. for gid.  Breaks code expecting standard uidNumber 
gidNumber in the default ldap schemas.
There are so many packages that could be X, you can imagine not wanting 
to have to qualify and patch all of them to use a common uid/gid 
number.  (And it gets even worse in a mixed nfs3 / nfs4 environment 
where uid/gid numbers actually go over the wire in some cases, and 
user@box in others, let's leave that to the side for now).
I'm leaning toward #5 to avoid storing all the other account information 
under two different trees.    But I'd prefer a scheme were there is a 
not-edited standard schema tree stored once under 'ou=Account' but with 
a different overlay for the uid/gid elements if looked up as AccountNix 
or AccountBsd.
I'm sure someone has done battle with this already, what's the right 
answer?
Thanks
Harry Coin