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

> -----Original Message-----
> From: wurzl, mario [mailto:wurzl_mario@emc.com]
> Sent: Thursday, October 09, 2003 1:23 PM
> To: 'Wachdorf, Daniel R'
> Cc: nfsv4@ietf.org
> Subject: RE: [nfsv4] Name Mappings for NFSv4 in Active Directory
> 
> 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.

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.

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

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. 

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

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. 

> 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:drwachd@sandia.gov]
> Sent: Wednesday, October 08, 2003 5:35 PM
> To: nfsv4@ietf.org
> 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
> drwachd@sandia.gov
> Sandia National Laboratories
> System Security Research and Integration
> 505-284-8060
> 
> 
> 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4