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

[Nicolas Williams <[e-mail]>]

On Thu, Oct 09, 2003 at 08:11:07AM -0600, Wachdorf, Daniel R wrote:
> 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. 

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.

> 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

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.

> integrate the name mapping with Active Directory.  I am sure there will be
> proposals to store it in other Directories.

Perhaps.

> 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

It's not about faster.

> 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.

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.

> 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.

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
-- 

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