No subject

-> name "nobody"
Mar 20 15:33:52 stalingrad rpc.idmapd[19602]: nfsdcb:
authbuf=oberkampf.msr-inria.inria.fr authtype=group
Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (group) id "501"
-> name "nogroup"

So name-based mapping appears to be working upside down here...

Here is my idmapd configuration:
[General]
Verbosity = 2
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = msr-inria.inria.fr

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

>     - with gss/krb5, you need a way to map kerberos principals to uid,
>     meaning idmapd with another method as nsswitch method. Otherwise, you'll
>     still need identical uids on both side. And properly-configured idmapd
>     seems to be useless (again).
> 
> 
> 
> ns_switch does not provide cross-realm name mapping, nor multiple
> RPCSEC_GSS principal mapping to the same local UID, both require extra
> ldap fields to be mapped. idmapd provides an api so that alternative
> mapping methods (ns_switch is one method) can be used.
Does nsswitch even allow a unique RPCSEC_GSS principal mapping to a
single UID, or is it impossible completly ?

And what does imply idmapd translation method exactly ? Simple existence
of user account on both side, or existence AND uid consistency ?

> here at the University of Michigan, I am a member of 2 Kerberos domains
> and an X.509 security realm. I can have 2 Kerberos names
> (andros at umich.edu <mailto:andros at umich.edu>, andros at citi.umich.edu
> <mailto:andros at citi.umich.edu>) and one SPKM3 x.509 name (something likd
> ou=US,ou=Michigan,ou=University of Michigan,cn=andros) all of which I
> need mapped to my local uid.
> 
> see
> http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html
> 
> and
> http://www.citi.umich.edu/projects/nfsv4/crossrealm/ASC_NFSv4_WKSHP_X_DOMAIN_N2ID.ppt
> <http://www.citi.umich.edu/projects/nfsv4/crossrealm/ASC_NFSv4_WKSHP_X_DOMAIN_N2ID.ppt>
> 
> for a complete explaination.
I'm not sure to understand everything, but at least if show some light
on the issue. BTW, there is a small typo (joe at arbitrary.domIAn.org) on
slide "local user: set ACL":

It appears to me than the lighter solution, in terms of what should be
configured on the client side, is to map on kerberos principal. This
just implies distributing keytabs and idmapd configuration, but avoid to
configure nss. On the other hand, it implies a LDAP server with secure
connection on server side, and umich_ldap translation method.

>     So basically, if you want to get rid of the need to have identical uid
>     on client and server, you need idmapping with another translation method
>     than nsswitch, meaning umich_ldap, which is still considered as
>     experimental (never tested it tough). Did I miss something ?
> 
> 
> 
> umich_ldap is experimental in that the schema used is not standardized.
> this is an open issue for NFSv4. note that NFSv4 itself is labeled
> EXPERIMENTAL in the kernel....
Indeed, thanks for the clarification.