I'm currently trying to migrate from 7Mode to CDot using 7MTT. After a few problems with 7MTT I'm now finally able to successfully initiate a cut over. After the cut over accessing files / folders with Unix security is not working as expected. If a user is not the owner of a file / folder he is not able to access it from windows using CIFS. I assume the problem is related to the filer not being able to pull the GIDs of a User from AD:
Yes we got a very unsatisfying answer from NetApp saying that this is not implemented (yet???) in CDot. We had so many trobule moving from Cluster Mode to CDOT that we will consider to move away from NetApp.
I have just discovered how to make this happen for you if you're interested. At least it appears to have worked for me.
Assuming you have a similar setup to ours with leveraging AD, you need to take a look at the ldap client schema applied to your SVM 'Corporate'
We are just using the AD-IDMU as-is.
> vserver services ldap client show -vserver Corporate -fields schema ## This will show you the LDAP schema applied to your SVM
> vserver services ldap client schema show -instance -vserver Corporate -schema AD-IDMU ## prints out all of the fields showing you which AD attributes the schema is mapping to.
The line to note from the second command is "RFC 2307 memberUid Attribute: memberUid"
The memberUid attribute was not populated for any of our groups and CDOT had no idea what auxiliary groups any of my domain users were a member of as a result...at least according to the 'secd authentication show-creds' command
We have experienced most of our pain in permissions between unix and windows in our transition to CDOT and I will say that documentation on the matter is VERY scattered or lacking for a great portion of it.
Yes, maybe that would be the best approach. I thought about that too, but to be honest I really think that NetApp should start implementing this as a feature. If it was working on 7Mode I would expect it to work on CDot too. Worst part was having support looking into the issue and they really had no clue what wasn't working. So since we have the new Netapp, only thing we can use it for is NFS datastores for VMware.
In TR-4073, I cover how to add "aux groups" to Windows LDAP. Basically, you double click the group and go to UNIX attributes. Then click "add" to add LDAP users. This populates the memberUid field in the schema.
which has a few copy & paste errors, and is basically misleading, it reads:
Configuring a VServer for LDAP using Microsoft Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 (Identity Management for UNIX):
The article claims that it should work fine as long as your are using IDMU and not Vintela or MS SFU. But this is not correct. I tried to set it up, but supplementary GIDs are empty. So hopefully this will be really fixed in the next 8.3 release.
This is what it says for Vintela and MS SFU:
Note: For secondary groups to work for mssfu35, once a group is UNIX-enabled, use a tool like ADSIEdit and modify the memberUid attribute of the group to add the username of the user to the group. ADUC cannot be used to complete this task.
Supplementary GIDs are empty likely because you do not have memberUid set in your LDAP schema.
The schema used for IDMU is a template in cDOT. It leverages the exact attributes used with Microsoft's IDMU implementation.
Vintela and MS SFU use very different schema attributes than IDMU, thus you would need to use different schema templates than IDMU. The vendor's recommendation would override whatever recommendation you see in KB or TR.
Supplementary GIDs work fine in cDOT.
For example, this user has several supplementary GIDs (this was done on 8.2.1):
So, parisi, on a unix client is this or should this be reflected in a 'getent group' command?
> getent group nested - does this have user 'test' as a member given your above configuration? because ours does not
In our case, NFS honors the groups that get mapped through our SSSD config simply through typical AD group membership.
Windows access behavior is as parisi mentioned. If user is member of an AD group set as Gid of the file/directory then access is denied, BUT populating the user in the memberUid attribute provisions the access needed.
So accessing directory based off of Gid ownership by an AD group...
from Windows (SMB) - user must be in the memberUid attribute of the AD group
from Unix (NFSv3 or NFSv4) - user needs to be member of the AD group (member attribute) though we're leveraging SSSD against our AD. Not certain if it comes into play for idmap, but I'm guessing it does based on the expected result of getent commands.
Hence, I was completely confused by this as I expected SMB access to reference the member attribute and the UNIX access to reference the memberUid attribute of the AD group. It appears my logic was wrong.
yes memberUid is the only way to go currently. We use winbind instead of SSSD which can resolve user group memberships via RFC2307-bis. I will try to put together a script that automatically adds members of group to the memberUid attribute. Since we are using nested groups, and only assign GIDs to the local groups to not hit the NFS 16 group limit, this is not so easy but seems doable with Powershell and Quest AD cmdlets. Rumors say RFC2307-bis will be included in 8.3.
I discovered another Problem. Under 7mode we use the option "cifs.nfs_root_ignore_acl". This option is no longer available under Cdot. Problem is that the workaround proposed to us by NetApp imposes a security problem.We should set a username mapping for root => DOMAIN\\Administrator and controll root access using access policies. I tested this, but unfortunately the usermapping overrules the export policy. So every root user on a linux system is mapped to DOMAIN\\Administrator and has full access to the nfs share. I don't know if that is by design, but this is a big problem.