CDot GIDs empty

[oweinmann]

Hi,

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:

secd authentication show-creds -node GEDASAN-02 -vserver Corporate -win-name tuser

UNIX UID: tuser <> Windows User: A\tuser (Domain User)

GID: Domain Users

Supplementary GIDs: <None>

Windows Membership:

  A\Up ATEST De_Dt Da Lg (Alias)

  A\Up ATEST De_Dt Da Ug (Domain group)

User is also a member of Everyone, Authenticated Users, and Network Users

Privileges (0x80):

I guess the 7MTT should have transferred my options.ldap but something seems to be missing for the GIDs...

[bsnyder27]

Did you happen to ever get/discover an answer to this?

I'm seeing the same.

I'm using the AD-IDMU ldap client schema template (as I didn't make a copy and use it as "customiz-able")

I seem to have other attributes and such mapping a-ok with AD user accounts.  Just not getting the gids.

[oweinmann]

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.

[bsnyder27]

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.

[parisi]

bsnyder is correct.

memberUid is the way to do this presently.

Future releases will introduce RFC-2307bis schema support, which will allow extraction of GIDs in AD based on the "member" attributes, without needing memberUid.

oweinmann, please message me directly with any issues you have lingering and I will attempt to assist you the best I can. bsnyder27 can vouch for me.

[parisi]

For reference, TR-4073 covers LDAP with cDOT in depth:

http://www.netapp.com/us/media/tr-4073.pdf

[oweinmann]

Hi,

this is what I get on our filer:

GEDASAN::> vserver services ldap client show -vserver Corporate -fields schema  vserver   client-config

schema

--------- ----------------------------- ------------------------

Corporate LDAP_vfiler0_Corporate_conf_0 LDAP_vfiler0_Corporate_5

GEDASAN::> vserver services ldap client schema show -instance -vserver Corporate -schema AD-IDMU

                                    Vserver: Corporate

                            Schema Template: AD-IDMU

                                    Comment: Schema based on Active Directory Identity Management for UNIX (read-only)

         RFC 2307 posixAccount Object Class: User

           RFC 2307 posixGroup Object Class: Group

          RFC 2307 nisNetgroup Object Class: nisNetgroup

                     RFC 2307 uid Attribute: uid

               RFC 2307 uidNumber Attribute: uidNumber

               RFC 2307 gidNumber Attribute: gidNumber

         RFC 2307 cn (for Groups) Attribute: cn

      RFC 2307 cn (for Netgroups) Attribute: name

            RFC 2307 userPassword Attribute: unixUserPassword

                   RFC 2307 gecos Attribute: name

           RFC 2307 homeDirectory Attribute: unixHomeDirectory

              RFC 2307 loginShell Attribute: loginShell

               RFC 2307 memberUid Attribute: memberUid

       RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup

       RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple

ONTAP Name Mapping windowsAccount Attribute: windowsAccount

                        Vserver Owns Schema: false

And yes, memberUid is not set by default on Windows 2008 R2 Unix Identity Management. So how do you fix it? You write a script that populates the LDAP Attribute memberUid?

[bsnyder27]

That would be the best approach.  Should be easy to do with Powershell.

I'd provide you with a script if I had one, but we've just manually edited a small number of AD groups that needed this type of access for now which appears sufficient for us for now. 

Easy to test the outcome first by populating the memberUid attribute of one of you AD groups that tuser is a member of and rerunning your command:

secd authentication show-creds -node GEDASAN-02 -vserver Corporate -win-name tuser

[oweinmann]

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.

[parisi]

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.

http://www.netapp.com/us/media/tr-4073.pdf page 83ish

As I mentioned previously "Future releases will introduce RFC-2307bis schema support." I cannot reveal which release on this forum, so you'd want to discuss with your sales rep under NDA.

[oweinmann]

Hi,

in the following KB article,

https://kb.netapp.com/support/index?page=content&id=1012935

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.

Best Regards,

Oliver

[parisi]

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):

::*> diag secd authentication show-creds -node ontaptme-rtp-01 -vserver parisi -unix-user-name test -list-id true -list-name true

UNIX UID: 10001 (test) <> Windows User: S-1-5-21-3413584004-3312044262-250399859-1251 (DOMAIN\test (Domain User))

GID: 513 (Domain Users)

Supplementary GIDs:

  10011  (ldifde-group)

  10012  (nested)

Windows Membership:

  S-1-5-21-3413584004-3312044262-250399859-1118     DOMAIN\testgroup (Domain group)

  S-1-5-21-3413584004-3312044262-250399859-513     DOMAIN\Domain Users (Domain group)

  S-1-5-32-545     BUILTIN\Users (Alias)

User is also a member of Everyone, Authenticated Users, and Network Users

Privileges (0x80):

In the TR listed in this forum, I cover how to leverage supplemental groups in LDAP.

http://www.netapp.com/us/media/tr-4073.pdf page 83ish

Nothing needs to be fixed for 8.3 in this case; you just need to ensure the schema template is configured properly to query LDAP for the correct attributes.

[bsnyder27]

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

Oliver,

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.

[parisi]

Correct.

The "member" attribute is a component of RFC-2307bis, which is not supported in cDOT yet. That support is coming in a future release. Until then, memberUid would need to be used.

[oweinmann]

Hi,

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.

[parisi]

I cannot confirm nor deny such rumors on this forum.

If you contact a NetApp sales rep and get NDA, you can get this information.

As for cifs.nfs_root_ignore_acl, this is indeed a limitation and will be coming in a future release.

What is the use case for cifs.nfs_root_ignore_acl in your environment?

[oweinmann]

I understand.

We have a script that creates a folder structure on our filers. It sets owner and group under Unix and therefore needs root access. We have two machines on our network that are explicitely allowed Super User access.

[parisi]

Well, one workaround would be to create a Windows user named "root" (or really, any other user) for the UNIX user "root" to map to. If using "root" as the Windows user, no need for name mapping rules.

Then add that Windows user's ACL to the folders you need to modify. That way, root is not "administrator" across the board and you can control access through ACLs until the option is added to cDOT.

[oweinmann]

Ok, this is a bit better but at the end you have all machines root accounts having the same access level (which is full) in this case. Only a handful of users have root access but still not a good solution in terms of security. I guess at the moment we will have to wait for the next release. I have now put together a powershell script that automatically adds the members to the memberuid attribute.

[parisi]

Well, with the export policy rules, you control whether those clients can access the mount at all via client match. If the clients are not in the rule list, they don't get access.

If you still desire access to these clients and are trying to "squash" root to anon, you wouldn't be able to do this, as the mapping would take precedence and the NTFS ACL controls access, not the mode bit. You could always create different Windows users for these "real" root accounts to avoid the scenario, but then you'd just be going down the rabbit hole.

Hopefully your supplementary GIDs are showing up for you now that you have added the memberUid.

[oweinmann]

parisi wrote:
Well, with the export policy rules, you control whether those clients can access the mount at all via client match. If the clients are not in the rule list, they don't get access.
If you still desire access to these clients and are trying to "squash" root to anon, you wouldn't be able to do this, as the mapping would take precedence and the NTFS ACL controls access, not the mode bit. You could always create different Windows users for these "real" root accounts to avoid the scenario, but then you'd just be going down the rabbit hole.
Hopefully your supplementary GIDs are showing up for you now that you have added the memberUid. 

Yes, that is exactly what I have experienced. Name Mappings overrule export policies.

I tested the script in a test ad environment and yes the NetApp now lists the extra GIDs. On our production environment it runs for more than 15 minutes. We have over a 1000 groups of which 186 are unix enabled. I will try to have the script just change one testing group for now and try a migration with 7MTT.