Re: [nfsv4] New version of NFSv4 multi-domain access draft (

["William A. (Andy) Adamson" <[e-mail]>]

On Thu, Oct 7, 2010 at 12:19 PM, Everhart, Craig
<[e-mail]> wrote:
> Couple of things I wonder about here.
>
> The draft goes to some lengths to claim that an NFS server's use of
> "name@domainname" would be problematic because of difficulties keeping
> up with accounts ("a severe constraint"), and that servers "really ought
> not" store authz entities in that form.  While I don't agree with either
> of these, I don't think that my objections are material to the point of
> the draft.

OK

>
> Instead, if I'm reading correctly, this is a presentation about how to
> do ID mapping with 32-bit or 64-bit IDs, with name service assistance.

The intention is describe possible implementation strategies for all
combinations of ID mapping: large ID -> small ID, small ID -> large
ID, and large ID -> large ID when the large IDs are of different
formats. We have not finished this job.

> I think that the draft could make the point about the prevalence of such
> servers without needing to critique other representations.

No critique intended.

> Perhaps (but
> not _required_) the draft could deal with the interoperability of
> servers, some of which use integers for IDs and some which use
> name@domainname, in the kind of FedFS scenario you describe.

Yes, that is our intention.  BTW do you know of any file systems that
store name@domainname on disk?

>
> I eagerly await the 5.4.3 text, or even the plans.  What's a "domain" in
> this context?

The DNS Domain presented to a server in name@domain

> How does a server tell if it is in one?

Every NFSv4 server is in a domain, and needs to be able to return a
canonical name@domain for each local representation of a user or
group. (second bullet in section 3)

>  Does a client
> need to know?

Yes - to perform a setacl which sends name@domain on the wire.

> What is a "domain-local ID"?

>From section 4 :

      Domain-local ID: Most installations assign numeric, local
      identifiers to users and groups, using a namespace local to their
      domain.  We call this a domain-local ID.

> In section 5.2.1, what's the
> point to "assigning and publishing a unique ID to each DNS domain"?

To have a level of indirection between the on disk domain portion of
an ID and the actual DNS domain name to handle (admittedly rare) DNS
domain name changes. The reason to publish this is to allow remote
servers that are presented with the ID the ability to map back from
the numeric domain ID to the DNS domain name.

The windows SID does this.

> Isn't the DNS domain name good enough?

Mostly, as noted in section 5.2.


>
> Could we add an example to 6.2?  I can't tell if the first paragraph is
> a modest hole or a truck-sized hole.

Sure, or at least add more descriptive text about the different
possibilties  Section 7.1 describes an attribute for LDAP which is one
way to perform the mapping.  By 'hole' are you thinking a security
hole? (we should specify here that all mapping and name service
communications need to be over a secured channel).

-->Andy

>
>                Craig
>
>> -----Original Message-----
>> From: William A. (Andy) Adamson [mailto:[e-mail]]
>> Sent: Thursday, September 30, 2010 1:40 PM
>> To: NFSv4
>> Subject: [nfsv4] New version of NFSv4 multi-domain access draft (
>>
>> Hello
>>
>> I uploaded a new version of our internet draft "NFSv4 Multi-Domain
>> Access"
>>
>> http://www.ietf.org/id/draft-adamson-nfsv4-multi-domain-access-03.txt
>>
>> Please have a look and give us any feedback.
>>
>> There are a number of sections that need text. Here are some issues
>> that need discussion.
>>
>> 1)  NFSv4 is not the only potential consumer. NFSv3, and SFTP, for
>> example. Do we mention these and/or other potential consumers.
>>
>> 2) Section 5.4.3.  Resolving Domain Names to Domain IDs
>>
>> We need to have a common way to map Domain Names to Domain IDs.
>> Currently we have two suggestions
>> - Just use SIDs, first asking MSFT to allocate a suitable authority
>> for non-Windows domain SIDs.
>> - Store 96-bit numeric IDs
>>      a) cast those to domain SIDs later.
>>      b) define a non-SID large ID format
>>
>> 3) Section 6.1.2.  RPCSEC_GSS Authorization Context Credential Data
>>
>> Do we want to define a new "PAC" for multi-domain access for those
>> implementations that don't provide the Windows PAC, or just insist
>> upon the use of the Microsoft PAC.
>>
>> 4) General review of section 6.3.  User Group Membership Determination
>> - Do we depend upon 2307bis
>> - Do we require groups within groups
>>
>> 5) Do we need a section on service discovery.  Two potential methods:
>> - Use local methods (configuration, DNS SRV RR lookups, ...) to
>>   discover local domain's servers, then depend on LDAP referrals for
>>   discovering all other domains' s
>> - Use DNS SRV RRs much the way AD does.ervers.
>>
>>
>> -->Andy
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>