Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

I hope to clarify by example others can duplicate where the pressure 
comes from to have the local account name for service X to have 
principal X/box.domain.com and the local user name to be X.

Kindly consider this freebsd 8 example.   It has applicability here in 
that the chain to heimdal is: slapd/ldap can rely on cyrus-sasl, sasl 
can rely on gssapi, and gssapi can rely on heimdal in freebsd.   (Such a 
chain  has a 'swallow the camel' feeling for those trained to deplore 
overhead).

In /usr/ports/security/cyrus-sasl2/work/cyrus-sasl-2.1.25/sample  
running on box.domain.com

We'll look at the table below for details, but here's the script:

login as $A, verify credentials are $B, connect to the above then run

./server -s $C -m GSSAPI

login as  $D on another screen, verify the credentials are $E connect to 
the above then run

./client -s $F -m GSSAPI  box.domain.com

when asked, put in for an authorization id: $G

--check whether auth will be successful.

Results:

1. A=C=F=foo D=bar and B=foo/box.domain.com E=G=bar@REALM authentication 
successful.
2. All as above except A != foo , (I tried root even, checking 
everything else) ->authentication fails.

Perhaps this is seen as a bug or design flaw but here and now to secure 
the wire I have to live with it.

So all the ldap servers must have local user ldap and principal 
ldap/box.domain.com.  Ditto nfs, ditto nscld.  Ditto local products 
offering services (to be) secured through these facilities.   I regret I 
gave the impression that clients were similarly restricted universally.  
In my world local accounts running servers may act also as clients of 
remote services.  (Lots of gear, lots of daemons, few admin staff, few 
'general users').

Notice ldap has a blinding array of plugins, no doubt some few could 
reasonably be expected to need access to files mounted on other boxes.

Having been forced to adopt the aforementioned username <-> principal 
naming convention, which seemed no great burden,  I saw no good reason 
why every process that is presumed not to be interactive and so 
requiring client-box-specific keytabs to be able to access nfs shares or 
off-box services ought not follow the same convention.

The above is one pressure.   Adding to that pressure in a related but 
different way:

Indeed in further support it happens in my world it is useful and 
commonplace, to make it an option to isolate what human users or daemon 
accounts do to a certain class of data on box Y to box Y and the 
server.  To not make available to users of certain data/services 
(including NFS) what they did on box Y available via box Z (not the 
server, while daemons on the server have access to all under the same 
user account).   This has the advantage that if a client box gets root 
compromised or is struck by sunspots and just makes a big mess,  and the 
misdoing person/process gets access to all the keytabs and so can act in 
any way as that box over the net, nevertheless the damage potential is 
contained.   Tell the world that box's keytabs and between net monitors 
and these protections, damage is minimal.   NFS supported this nicely 
pre-heimdal-kerberos.  Administratively a few principal rekeys and a new 
box is up and running without even needing to regain physical access to 
the dubious one.  Hence the value we saw in nfs4's principal name on the 
wire (to include the box and not uid:gid) and authentication, and the 
krb5i advertised ability to thwart 'man in the middle' attacks.

I worry that world readable maps identifying which principals get mapped 
to which users makes it impossible for admins to allow trusted users to 
maintain their own, while at the same time world readable maps make 
targeting easier in the manner of credentials caches before randomizing 
the names.

It is a reality of my work that having crafted patches that now allow 
kerberos to secure the wire no matter the form of the principal name and 
to allow ldap to run as non-root using only /etc/krb5.conf I have to 
become only an occasional lurker.

I hope my experience helps you craft a better future, kindly overlook my 
personal offenses.  Too tired to have been typing sometimes I think.

Harry

(Please if possible do not include me in private replies going forward.  
I will look in on the list from time to time as I can.)