No subject
Mon Mar 12 05:18:26 EDT 2007
Nobody-Group = nogroup<br><br>> - with gss/krb5, you need a way to map kerberos principals to uid,<br>> meaning idmapd with another method as nsswitch method. Otherwise, you'll<br>> still need identical uids on both side. And properly-configured idmapd
<br>> seems to be useless (again).<br>><br>><br>><br>> ns_switch does not provide cross-realm name mapping, nor multiple<br>> RPCSEC_GSS principal mapping to the same local UID, both require extra<br>
> ldap fields to be mapped. idmapd provides an api so that alternative<br>> mapping methods (ns_switch is one method) can be used.<br>Does nsswitch even allow a unique RPCSEC_GSS principal mapping to a<br>single UID, or is it impossible completly ?
</blockquote><div><br>no. only if your policy is to map rfc2307 name to say kerberos principal (strip the realm) which is done for AFS. ns_switch is insufficient for anything but the simplest NFSv4 domain.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And what does imply idmapd translation method exactly ? Simple existence<br>of user account on both side, or existence AND uid consistency ?</blockquote><div><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> here at the University of Michigan, I am a member of 2 Kerberos domains<br>> and an X.509 security realm. I can have 2 Kerberos names<br>> (<a href="mailto:andros at umich.edu">andros at umich.edu</a> <mailto:<a href="mailto:andros at umich.edu">
andros at umich.edu</a>>, <a href="mailto:andros at citi.umich.edu">andros at citi.umich.edu</a><br>> <mailto:<a href="mailto:andros at citi.umich.edu">andros at citi.umich.edu</a>>) and one SPKM3 x.509 name (something likd<br>
> ou=US,ou=Michigan,ou=University of Michigan,cn=andros) all of which I<br>> need mapped to my local uid.<br>><br>> see<br>> <a href="http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html">
http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html</a><br>><br>> and<br>> <a href="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
</a><br>> <<a href="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</a>><br>><br>> for a complete explaination.
<br>I'm not sure to understand everything, but at least if show some light<br>on the issue. BTW, there is a small typo (<a href="mailto:joe at arbitrary.domIAn.org">joe at arbitrary.domIAn.org</a>) on<br>slide "local user: set ACL":
</blockquote><div><br><br>have you red the above powerpoint? i suggest you turn on the 'notes' in the power point ......<br><br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It appears to me than the lighter solution, in terms of what should be<br>configured on the client side, is to map on kerberos principal. This<br>just implies distributing keytabs and idmapd configuration, but avoid to<br>
configure nss. On the other hand, it implies a LDAP server with secure<br>connection on server side, and umich_ldap translation method.<br><br>> So basically, if you want to get rid of the need to have identical uid
<br>> on client and server, you need idmapping with another translation method<br>> than nsswitch, meaning umich_ldap, which is still considered as<br>> experimental (never tested it tough). Did I miss something ?
<br>><br>><br>><br>> umich_ldap is experimental in that the schema used is not standardized.<br>> this is an open issue for NFSv4. note that NFSv4 itself is labeled<br>> EXPERIMENTAL in the kernel....<br>
Indeed, thanks for the clarification.<br><br></blockquote></div><br>
------=_Part_133668_11501672.1174404601687--
More information about the NFSv4
mailing list