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

From: "Wachdorf, Daniel R" <[email-masked]>
Date: Thu, 9 Oct 2003 08:20:19 -0600

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 -
[email-masked] becomes [email-masked], you have an entry for
each of these within the altSecurityIdentites attribute.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 4:09 PM
To: Wachdorf, Daniel R
Cc: [email-masked]
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 "[email-masked]" is renamed
"[email-masked]" then the old name ("[email-masked]") won't be
re-used for X amount of time, which time is the max for which we can
cache the "[email-masked]" mapping.

Nico
-- 

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 9 Oct 2003 09:52:45 -0500

> by the RPC mapping service. 

Actually, the rpc mapping service is not the only way in which clients
might get at the mappings.  E.g., through the local directory. However,
I was not, and still am not, sufficiently satisfied that existing
directory services (e.g., LDAP) can adequately handle the mapping task
without adding "active" (to borrow an MS term) hooks to the directory
service.  Thus the mapper rpc, which I see as *part* of the directory
(who said a directory must use a single access protocol?
ActiveDirectory uses several).

Perhaps I should work on describing how to do this purely through LDAP,
but I needed something that was as complete as possible that I could use
to write an I-D with.

The main problem with mapping through the directory, again, is the need
to NOT use name@domain as the permanent index to the assigned UIDs/GIDs
- that's because otherwise dealing with user/group renaming / name reuse
becomes a hard problem (see rationale below).  So if you can't use
name@domain as the permanent index to the assigned UIDs/GIDs then how is
the directory to satisfy queries for name@domain?  That's where the
"active" hook I mentioned above comes in: the directory must check a
cache for name@domain, and if it misses then it must perform the lookup
for "name" at "domain"'s directory, get the permanent index to the
assigned UID/GID - the {foreign internal ID, foreign domain} tuple -
then lookup UID/GID and cache the remote lookup for some time.

> already in existence within the enterprise.  One way to do this would be

Of course.  The rpc protocol I propose does not preclude this - just
because it isn't what you think of as a directory service doesn't mean
that it can't be integrated with the directory service.

> proposals to store it in other Directories.

Perhaps.

> an RPC service that just stores the mappings will be faster, but if the RPC

It's not about faster.

> better to just have the NFSv4 servers talk directly to that backend

The RPC mapping service becomes part of the directory and can cache
results.  See above about how mapping name@domain does require
additional directory lookups, and not just once, and no matter how what
protocol/service the client uses to get at the mapping.

> each of these within the altSecurityIdentites attribute.

Ah, but you have to *know* when foreign names are changed/reassigned so
you can change your AD mapped entries accordingly.

There's the rub - if you have, say, fifty organizations "trusting" each
other by allowing their users/groups to be referenced by each others
ACLs and groups, how do you organize the necessary distribution of name
change/reassignment information from any one domain to all the others?
How reliable is this bound to be?

My take is that the most reliable way to deal with foreign name
change/reuse events is to not use foreign names as the permanent index
to the mappings.

Dealing with foreign name change/reuse events is crucial to the security
_and_ convenience of the mappings.  This is the critical problem to
solve here.

I tried to build a system for distribution of name change/reuse info in
version -00 of my draft, because I thought it would be better, easier to
use name@domain as a semi-permanent index to its assigned UID/GID.  In
the end I never did find the result satisfactory, nor did others within
Sun, so I switched to the approach in draft -01.

You have to address the same issue, and you may yet address it as I
did in version -00 of my draft (but without the RPC service?).  Not
addressing the issue, however, is hardly acceptable.  Banning name
changes is less acceptable still, though you may get away with banning
name reuse (though I find that unacceptable also).

Note that banning internal ID reuse is not only acceptable but even
common.  For example, ActiveDirectory itself strives to avoid RID
reuse, and many organizations have UID/GID no-reuse policies.  Version
-01 of my draft relies or internal ID non-reuse for security.

Cheers,

Nico
--