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?