ONTAP Discussions

AD security group causing file ownership errors on unix qtree

kennethpflum
7,459 Views

I'm not the storage admin at my company, so apologies if my terminology is off.  At my company users are able to access their Linux home dirs via a cfs share & dfs (and of course they're also sharedvia nfs).  This has been working fine, but we are moving to a different AD account setup which is causing problems.  There is a particular Active Directory security group called OSA that we have (an old group that was in place before the account changes); when a user is added to this group the Netapps assign root:bin ownership to any file/folders created in Windows.  When removed from this sec. group all new files are created with the correct uid:user ownership.  Below is some output from a 'wcc -s' on my account with and without being in the OSA sec. group.  As you can see, just by changing my AD permissions the NT to Unix name mapping goes all wonky, and it thinks I'm root.  We don't use the usermap.cfg file for account mapping.  I tried creating an entry but that didn't change anything.  We don't map accounts to each other explicitly, so I'm under the assumption that the NetApp just maps uid1 to uid1, and uid2 to uid2.  Oh, and the home dirs are in a unix security style qtree.

In OSA group:

(NT - UNIX) account name(s):  (DOMAIN\kpflum - root)
        ***************
        UNIX uid = 0
        user is a member of group daemon (1)

        user is a member of group adm (3)
        user is a member of group bin (2)
        user is a member of group daemon (1)
        user is a member of group linux (1007)
        user is a member of group mail (12)

        NT membership
                DOMAIN\kpflum

                DOMAIN\OSA

                DOMAIN\RWC

Removed from OSA group:

  (NT - UNIX) account name(s):  (DOMAIN\kpflum - kpflum)
        ***************
        UNIX uid = 4530

        user is a member of group user (150)
        user is a member of group linux (1007)
        user is a member of group linuxteam (12496)

        user is a member of group tech (3511)

NT membership
                DOMAIN\kpflum

                DOMAIN\RWC

If anyone has any ideas I'd be forever grateful.

1 ACCEPTED SOLUTION

adamfox
7,459 Views

Ok.  This is most likely because by default, if a windows user is a member of the local Administrators group on the NetApp controller, that user is automatically mapped to the UNIX root user.  The original idea behind this is that Windows Admins usually expect to be treated like admins (i.e. they can blast permissions, etc.) .So I'd be willing to bet that the OSA group in question is a member of the local Administrators group.

Assuming this is the cause, there are 2 ways to fix it.

1.  Remove the OSA group (or group that contains OSA) from the local Administrators group.

2. There is an option in ONTAP to turn off the feature that says "local Windows Administrators map to root".  The option is called wafl.nt_admin_priv_map_to_root.  If this option is set to off, then no mappings to root based on being in the local Administrators group occur.

Which way you deal with it will depend on your site's requirements.  Both are valid, and one isn't necessarily better than the other in all cases.

Hope this helps.

View solution in original post

3 REPLIES 3

adamfox
7,460 Views

Ok.  This is most likely because by default, if a windows user is a member of the local Administrators group on the NetApp controller, that user is automatically mapped to the UNIX root user.  The original idea behind this is that Windows Admins usually expect to be treated like admins (i.e. they can blast permissions, etc.) .So I'd be willing to bet that the OSA group in question is a member of the local Administrators group.

Assuming this is the cause, there are 2 ways to fix it.

1.  Remove the OSA group (or group that contains OSA) from the local Administrators group.

2. There is an option in ONTAP to turn off the feature that says "local Windows Administrators map to root".  The option is called wafl.nt_admin_priv_map_to_root.  If this option is set to off, then no mappings to root based on being in the local Administrators group occur.

Which way you deal with it will depend on your site's requirements.  Both are valid, and one isn't necessarily better than the other in all cases.

Hope this helps.

kennethpflum
7,459 Views
1.  Remove the OSA group (or group that contains OSA) from the local Administrators group.

2. There is an option in ONTAP to turn off the feature that says "local Windows Administrators map to root".  The option is called wafl.nt_admin_priv_map_to_root.  If this option is set to off, then no mappings to root based on being in the local Administrators group occur.

That's it! Thank you.

dmandell
7,459 Views

I have the same problem on a mixed qtree.

I Both turned off wafl.nt_admin_priv_map_to_root and removed all windows domain users and groups from the filers admin group.

I still have a problem that when a windows user creates a file on a unix permissioned folder that the permissions in unix show as root:bin

Any ideas?

Thanks!

Dana

Public