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

From: "Wachdorf, Daniel R" <[email-masked]>
Date: Wed, 8 Oct 2003 16:01:25 -0600

It could be, I have never submitted one before. I would probably make a few
changes to the way its worded before I did that.

-dan

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:56 PM
To: Wachdorf, Daniel R; [email-masked]
Subject: Re: [nfsv4] Name Mappings for NFSv4 in Active Directory

Is your document an I-D?  Will you submit it as an I-D?

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

---

From: "wurzl, mario" <[email-masked]>
Date: Thu, 9 Oct 2003 15:23:28 -0400

The unique purpose of the attribute 'altSecurityIdenities', is to enable
users from trusted realms, but not from trusted domains to access Windows
resources. It is not intended to be used for users of trusted Windows
domains, but for users from MIT realms, or non-trusted Windows domains.
The main problem with the use of 'altSecurityIdenities', is the need to
create a shadow account on the local domain for each trusted user. It means
administrative overhead, and duplication of accounts, which may lead to
security problems, and goes against policies in the large majority of
corporations, which do not want an user to have more than one account in the
Windows environment.

Real time creation of accounts by a server, may create a HUGE security
vulnerability in an organization. User accounts created by a server (NFSv4
or other), have potential access to the Windows resource on the forest where
the account has been created. System administrators have very little control
on dynamically created accounts.
Like the use of the 'altSecurityIdenities' attribute as described in the
document, dynamically created user accounts would be unacceptable from a
corporate policy point of view.
It also implies that Unix based NFS servers would have to implement the
mechanism to create Computer accounts in a Windows domain, which is quite
complex, and does not provide any value add to UNIX systems.

The document also mentions "SPNEGO protected Web pages".
SPNEGO is not a security mechanism, and therefore cannot protect any
resource. The only purpose of SPNEGO is to negotiate a security mechanism
under the GSSAPI.

What Microsoft calls PAC is the Kerberos Authorization Data Field, and
contains the user SID and the SIDs of the groups the user is a member off.
It may include groups from other domain in the forest that the user might be
a member off.

Mario

-----Original Message-----
From: Wachdorf, Daniel R [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 5:35 PM
To: [email-masked]
Subject: [nfsv4] Name Mappings for NFSv4 in Active Directory

I have been working with CITI on finding a way to use Active Directory to
use map NFSv4 names into active directory user accounts. I wrote a document
that describes a scheme to map NFSv4 names and authentication principals
into an Active Directory Domain.  
I would be interested in what the members of the list thought.  Thanks.

-dan

--------------------------------------
Daniel Wachdorf
[email-masked]
Sandia National Laboratories
System Security Research and Integration
505-284-8060

---

From: "Wachdorf, Daniel R" <[email-masked]>
Date: Thu, 9 Oct 2003 13:33:58 -0600

> From: wurzl, mario [mailto:[email-masked]]
> Sent: Thursday, October 09, 2003 1:23 PM
> To: 'Wachdorf, Daniel R'
> Cc: [email-masked]
> Subject: RE: [nfsv4] Name Mappings for NFSv4 in Active Directory
> 

I agree this is a problem with the approach.  I would be interested in
hearing other peoples approach to talking this problem.  I wrote the
document to explain a few discussions I had with Andy at the NFSv4conf. I
was hoping to open up some discussion to figure out how to integrate Active
Directory with NFSv4 with support for foreign realms.

> complex, and does not provide any value add to UNIX systems.

It's not that huge.  You can create the accounts and have them disabled, but
I do see the problems with it.  

I personally think all the accounts should be mapped before hand. I
understand that this may not be the best approach for everyone. 

> resource. The only purpose of SPNEGO is to negotiate a security mechanism
 
When I stated SPNEGO I meant "Windows Enabled Web Authentication"  We (my
group and sandia)frequently call it SPNEGO.  We use it to do Kerberos
authentication to web pages.