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

[Nicolas Williams <[e-mail]>]

On Thu, Oct 09, 2003 at 10:00:14AM -0600, Wachdorf, Daniel R wrote:
> > 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?).  

You can implement a mapper service that works with AD without having to
add the "active" hooks to AD that I described.  How?  I leave that as an
excercise for the reader :)

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

You have an infrastructure, but the it doesn't address the problem.

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

You use the QISID.  I again leave the details to the reader - I think I
know how.

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

No.  The QISID is the {internal ID from remote domain, remote domain}
tuple.

I.e., if I want to map "[e-mail]" to a UID in foo.com I:

 - if (!lookup "[e-mail]" in the foo.com directory cache)
   then
     - lookup "jane" at bar.com's user directory and get, say, UID 12345

     - if (!lookup {UID 12345, "bar.com"} in foo.com)
       then

	 - atomically assign the next available UID in foo.com[*], say,
	   54321, to

         {UID 12345, "bar.com"}

	 and record the assignment in the directory (to prevent
	 assignment of the same UID to any other user).

	 The assignment that is recorded [permanently] in foo.com's
	 directory is:

         {UID 12345, "bar.com"} <-> {UID 54321, "foo.com"}

         [*]  Possibly from a pool for that purpose.

       fi

     - lookup the length of time for which I can cache names from
       bar.com (this is the length of time for which the admins of
       bar.com promise not to reuse names after they become unused) and
       cache the following mappings for upto that much time:

       "[e-mail]" <-> {UID 54321, "foo.com"}

   fi

That's more or less the algorithm - simplified so I can present more
clearly what happens when the mappings aren't already established

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

When the "[e-mail]" <-> {UID 54321, "foo.com"} mapping expires then
"jane" has to be looked up again at bar.com to get the permanent mapping
index, {UID 12345, "bar.com"}.

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

My draft does not mandate the use of the mapper service.  It describes a
mapping algorithm/strategy and then it defines a protocol that can be
used to make it happen without having to monkey around with existing
directory services in ways that are very platform-specific.

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

Rename example:

 - "[e-mail]" gets mapped to, say, UID 54321 at foo.com

 - "[e-mail]" is renamed "[e-mail]", but her QISID,

   {UID 12345, "bar.com"}

   stays the same (i.e., "[e-mail]" changed names, but not UIDs)

 - so next time we have to map "[e-mail]" we first lookup "jane"
   at bar.com and get QISID {UID 12345, "bar.com"}, so we then lookup
   that QISID in foo.com and, lo and behold, there is an assignment
   already and so

   "[e-mail]" get mapped to UID 54321 at foo.com

Name reuse example:

 - now a new employee at bar.com gets hired and gets "jane" as her
   username (perhaps because her first name is "Jane", who knows)

   (The important thing is that this new "[e-mail]" not be created
    until after X amount of time, which is the max for which other
    domains are allowed to cache <name>@bar.com to QISIDs.)

 - to map "[e-mail]" we lookup "jane" at bar.com's directory and
   get, say, UID 432876, that is, QISID {UID 432876, "bar.com"}

   (Again, it is important that {UID 432876, "bar.com"} not have been
    used previously.)

    - now we assign a UID, say, 50000, from foo.com to {UID 432876,
      "bar.com"} and cache

      "[e-mail]" <-> {UID 50000, "foo.com"}


So, version -01 of my draft deals with renames and name reassignement.
With the caveat that:

 - trusted domains MUST NOT reuse internal IDs (not without fair
   warning)

 - trusted domains MUST NOT reuse names (ESIDs) for a certain amount of
   time after they are released, which amount must be published
   somewhere

   OR

   trusted domains MUST NOT publish that amount of time, and domains
   that trust them MUST NOT cache ESID<->mapped ISID entries.

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

Now try extending this overhead by requiring that all domains that trust
a given domain MUST be informed of name changes/reuse in the trusted
domain.

Should the notifications be synchronous?  (I.e., no name change/reuse
until all trusting domains are notified.)  If so, how can this scale?

Or should the notifications be lazy?  (I.e., change/reuse the name and
then tell the trusting domain - if this causes any problems for anyone,
oh well.)  If so, how can you justify this?



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

Which?  The last paragraph?  or the one before it?

I want you to agree that the foreign name change/reuse issue MUST be
addressed by any mapping proposal.  :)

Cheers,

Nico
-- 

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