PowerScale OneFS: GIDs are Not Assigned Properly to Mapping Tokens After a OneFS Upgrade

Following upgrades to OneFS, a user's mapped GID may not be assigned correctly, resulting in access issues for impacted users. The GID in this scenario is expected to be pulled from a non-AD provider such as LDAP through a mapping rule. The affected rule is using the 'insert' operator to pull the primary group identity into the token of the AD user.

For example, a mapping rule such as below would insert a group into the identity of the AD user in the mapping token.

ninetenonethree-1# isi zone zones list -v
                       Name: System
                       Path: /ifs
                   Groupnet: groupnet0
              Map Untrusted:
             Auth Providers: lsa-ldap-provider:TESTLDAP, lsa-activedirectory-provider:TESTDOMAIN.LOCAL, lsa-local-provider:System, lsa-file-provider:System
               NetBIOS Name:
         User Mapping Rules: TESTDOMAIN\* &= * [], TESTDOMAIN\* += * [group,break]
       Home Directory Umask: 0077
         Skeleton Directory: /usr/share/skel
         Cache Entry Expiry: 4H
Negative Cache Entry Expiry: 1m
                    Zone ID: 1

Administrators observe that the GID for the LDAP group is now listed as supplementary in the mapping token. Per the mapping rule, it is expected to be the primary group of the user.

ninetenonethree-1# isi auth mapping token testdomain\\testuser
                   User
                       Name: testuser
                        UID: 10000
                        SID: S-1-5-21-2828724323-430878434-1842076698-53601
                    On Disk: 10000
                    ZID: 1
                   Zone: System
             Privileges: -
          Primary Group
		       Name: TESTDOMAIN\domain users <<<<<<<<< Primary group is pulled from AD, which is not expected in this scenario
                        GID: 1000002
                        SID: S-1-5-21-2828724323-430878434-1842076698-513
                    On Disk: 1000002
Supplemental Identities
                       Name: testgroup <<<<<<<<< Per the mapping rules this should be the primary
                        GID: 3500
                        SID: S-1-22-2-3500
                       Name: Users
                        GID: 1545
                        SID: S-1-5-32-545
                       Name: Authenticated Users
                        SID: S-1-5-11

The AD provider is configured with assume-default-domain enabled:

ninetenonethree-1#  isi auth ads view TESTDOMAIN.LOCAL -v | grep -i assume     
Assume Default Domain: Yes

Code enhancements for a caching issue with Alias names while assume-default-domain is enabled were corrected on impacted code. Due to the LSASS cache architecture, the correction resulted in group mappings from non-domain accounts not working as intended.

Impacted code levels are as follows, and include all subsequent patches after those specified below for that version:

• OneFS 9.5.1.5
• OneFS 9.7.1.10
• OneFS 9.10.1.3
• OneFS 12.0.0.0 and all versions above

To encounter this issue, the following must be true:

1. An Active Directory (AD) provider is configured on the cluster, with 'assume-default-domain' enabled.
2. A user-mapping rule on the access zone with the AD provider is set with the 'insert' group mapping referencing a non-AD group.

If both of these are not true, then a different issue is being experienced and Dell Support should be engaged to investigate.

Administrators may either disable assume-default-domain, or adjust mapping rules to have the appropriate domain prefix if assume-default-domain must remain enabled.

For adjustments to mapping rules, the 'insert group' mapping must be modified.

The domain prefix for the secondary providers is as follows, with the name of the local provider of a zone shown as below:

LDAP: LDAP_USERS\
NIS: NIS_USERS\
File: UNIX_USERS\
Local: <local domain>\

For the example from before, modify the mapping rule to explicitly call out the LDAP provider domain. It is recommended to delete the old mapping rules before adding the new ones.

ninetenonethree-1# isi zone zones modify system --user-mapping-rules="TESTDOMAIN\* &= LDAP_USERS\* []"; isi zone zones modify system --add-user-mapping-rules="TESTDOMAIN\* += LDAP_USERS\* [group]"

Validate the applied changes:

ninetenonethree-1# isi zone zones list -v
                       Name: System
                       Path: /ifs
                   Groupnet: groupnet0
              Map Untrusted:
             Auth Providers: lsa-ldap-provider:TESTLDAP, lsa-activedirectory-provider:TESTDOMAIN.LOCAL, lsa-local-provider:System, lsa-file-provider:System
               NetBIOS Name:
         User Mapping Rules: TESTDOMAIN\* &= LDAP_USERS\* [], TESTDOMAIN\* += LDAP_USERS\* [group,break]
       Home Directory Umask: 0077
         Skeleton Directory: /usr/share/skel
         Cache Entry Expiry: 4H
Negative Cache Entry Expiry: 1m
                    Zone ID: 1

Flush the mapping cache:

ninetenonethree-1# isi auth mapping flush

You can check the mapping token for the user to confirm if the group is properly mapped. The LDAP group is now listed as the primary group for the user, showing that the mapping rules are working.

ninetenonethree-1# isi auth mapping token testdomain\\testuser
                   User
                       Name: testuser
                        UID: 10000
                        SID: S-1-5-21-2828724323-430878434-1842076698-53601
                    On Disk: 10000
                    ZID: 1
                   Zone: System
             Privileges: -
          Primary Group
                       Name: testgroup <<<<<<<<< The LDAP group is now properly showing up as the primary group
                        GID: 3500
                        SID: S-1-22-2-3500
                    On Disk: 3500
Supplemental Identities
                       Name: TESTDOMAIN\domain users <<<<<<<<< No longer listed as primary
                        GID: 1000002
                        SID: S-1-5-21-2828724323-430878434-1842076698-513
                       Name: Users
                        GID: 1545
                        SID: S-1-5-32-545
                       Name: Authenticated Users
                        SID: S-1-5-11

For more on mapping rule operators, see: user mapping identities across authentication provider operators