FW: [nfsv4] Name Mappings for NFSv4 in Active Directory

["Wachdorf, Daniel R" <[e-mail]>]

Sorry, meant to send this to everyone.

First, I will work on getting an IETF draft of the document out.  

Second.  I think there are two areas of the problem. 1- How do the NFSv4
server/clients get the name mapping information. 2- Where is this
information stored?  

For the first part the RPC solution that you proposed works.  I do believe
that the caching of this information should be done by the NFSv4 server, not
by the RPC mapping service. 

However, the mappings need to co-inside with the user/group information
already in existence within the enterprise.  One way to do this would be
integrate the name mapping with Active Directory.  I am sure there will be
proposals to store it in other Directories.

Also, I think that direct communication between the NFSv4 server/clients and
Directory services is probably the best way to go.  Sure, communicated with
an RPC service that just stores the mappings will be faster, but if the RPC
service then has to communicate with a back end directory service, its
better to just have the NFSv4 servers talk directly to that backend
directory service.

As for the comment below, the Active Directory mapping solution could easily
allow the re-use of foreign security principals.  The altSecurityIdenties
attribute is multi-valued, so if a user changes their foreign identity, ie -
[e-mail] becomes [e-mail], you have an entry for
each of these within the altSecurityIdentites attribute.

-----Original Message-----
From: Nicolas Williams [mailto:[e-mail]] 
Sent: Wednesday, October 08, 2003 4:09 PM
To: Wachdorf, Daniel R
Cc: [e-mail]
Subject: Re: [nfsv4] Name Mappings for NFSv4 in Active Directory

On Wed, Oct 08, 2003 at 04:03:40PM -0600, Wachdorf, Daniel R wrote:
> I have seen that.  Is document describes a way of providing that same
> functionality (minus the communication piece) by placing this in active
> directory.
> This would allow:
> 	-foreign security principals to have group information associated
> with them.  You could add a foreign security principal into a local
> active directory group.

My draft does not address this one feature, but that's because the issue
is somewhat orthogonal to the mapping strategy itself - once you've
mapped foreign users you can make them members of groups in your domain
(yes, there be other details).

> 	-provides long term storage for a mapping of UID/GID to nfsv4 names.
> This is useful if file systems are replicated, or written to long-term
> backup mechanisms.
> 	-on the fly creation of UIDS/GIDS. (they would have be synchronized
> with the directory service).

Sounds good to me so far.

Of course, I'm interested in a solution that is not specific to
ActiveDirectory.

Besides that I'm curious as to how you address foreign domain user and
group name changes.  I solve the problem by making the permanent index
to foreign mappings be the tuple

{internal ID at foreign domain, foreign domain}

while counting on internal IDs not being reused without fair warning.


As an optimization my draft also allows for caching

user/group@domain <-> {foreign internal ID, foreign domain}

mappings for as long as a given name's foreign domain guarantees that a
name won't be reused.  I.e., if "[e-mail]" is renamed
"[e-mail]" then the old name ("[e-mail]") won't be
re-used for X amount of time, which time is the max for which we can
cache the "[e-mail]" mapping.


Nico
-- 


_______________________________________________
nfsv4 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4