2

Recently we have bounded our Linux server to an AD domain. We are now able to do simple operations, as follows:

  1. Login to our Linux server with AD accounts (also via SSH)
  2. List and recognize our AD groups with the id command
  3. Create files, taking ownership on those files and another simple operations
  4. Create ACL's on the Linux server involving our AD users and groups

However, It seems that our users can not get access with groups other than their primary group.

Steps we have tried

Let's say that an AD user named foo is member of "group_A@domain.dom", "group_B@domain.dom" AD groups, and group_A defined as primary group. We expected that user foo will be able to access files that are own by group_A or group_B, but we have found that the user foo can not get access to files owned (or have permissions) assigned to group_B.

Therefore, our user is member of a lot of ad groups, but only the primary group is effective and can give our user an access on files in the Linux server. This phenomenon seems to occur across all our environment

What can we do to allow our AD users get access via all the groups they're member of and not only their primary group?

Technical Info

We are using Rhel7 Linux server, and we joined it to the windows domain with realm tool. We did not gave our users a POSIX attributes, and there is an auto ID mapping

Idan Tank
  • 27
  • 5

1 Answers1

0

Well....It seems that some of the files the users were trying to access were on an NFSv4 share.

When using an NFS share with sys authentication mount option, the NFS server "trust" the first 16 groups and not resolving by the domain [this is the "16 groups" problem - common problem in NFS since the protocol was presented way back in rfc5531 ].

So, the NFS server compare the 16 first user's gids to the gid that is assigned to the file the user is trying to access.

However, If the user is a domain user with a lot of nested groups, the Linux server not always resolving them in the same order. So, there is no way to ensure that some of the groups will be one of the first 16 user group (and thus will be applicable with NFS server terms), unless it's the user's primary group!

The way to bypass this:

  1. Changing authentication NFS method to something like Kerberos
  2. Turning off nested group support in the Kerberos linux client [sssd in our case] and making sure the permissions are done with the user's 1 group nesting level
  3. Maintaining unix attibutes in the Domain level foreach user

What we have done?

Since our NFS server was an ONTAP vserver, we could turn off the 16 group limit. But, when you do it in ONTAP the vserver no longer support automatically the first 16 groups - it tries to resolve all the groups by name service (LDAP/local ontap user/groups).

However, the netapp LDAP client is 'stupid' - it cannot do what sssd does. So, the ONTAP LDAP client (Defined in the nsswitch command) is doing a 'pure' LDAP. When it tries to translate a group/user, It's trying to search the LDAP Unix attributes assigned for the user/group in Active Directory. I have already asked NetApp about this...the development of SSSD client as Name service is not available

My Advice?

You have to reach a state where the Unix LDAP client of the Linux server and the NetApp VServer are acting by the same logic.

OR

Turn the Linux client working by Pure LDAP and maintain unix attrs for the groups you need

OR

Create a local PASSWD ontap file for the specific groups

Done

Idan Tank
  • 27
  • 5