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

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

> 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).
> 
This would be a great idea, if all the directory service vendors were on
board.  My main problem with it is that I doubt active directory will ever
include this (Anyone from MS out there?).  
I am coming at this from an end users point of view; we already have the
entire infrastructure in place to manage our users/groups with active
directory, most sites already have this in place.  Additionally, AD provides
the necessary Kerberos infrastructure needed to run NFSV4.  A solution
should integrate Active Directory.  

It possible that you could stick the rpc mapping service on active
directory.  The question then becomes, how do you provide a mapping (or
association) between the mappings you are creating and the accounts within
active directory. I am hopping to provide a solution for that.

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

I am not sure about what you mean here and below.  From what I understand
about your RFC, I think we are talking about the same think.  Correct me if
I am wrong. 

You would have an external user [e-mail] and you call in your draft
an ESID.  You would then map them to an internal, account in active
directory a QISID, which then has the attribute for a MISID, the UID.  

I don't think this is true that it requires multiple lookups. If I am
querying active directory for the user account associated with a foreign
security principal.  I do one query for the account with the
altSecurityIdentites, then I get the user account, gid, and uid. I can then
cache this.

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

True, but is this necessary.  From what little I know, vendors are already
designing solutions to communicate with and LDAP directory store.  Why not
let the NFSv4 servers decide how they will cache the information.  

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

First, I don't understand how your solution allows for the changing of names
without some notification.  How do users get access to their old files
referenced by the UID, GUID without know how to map that user's new foreign
security identity to the old one?

Secondly, these events occur infrequently.  There is probably already some
administrative overhead associated with changing someone's security
identifier.  I don't think it's that much trouble to allow notification of
the change.

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

I think this would have to be a given.

> Cheers,
> 
> Nico
> --


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