Configuring ID mappings in IDMU
To configure ID mappings in Microsoft Identity Management for UNIX (IDMU), do the following the steps. This procedure applies to Windows Server 2012 R2 and preceding versions.
These steps apply to Windows Server up to and including Windows Server 2012 R2 versions, which have IDMU. Because IDMU was removed starting Windows Server 2016, see instructions on editing RFC 2307 attributes in Configuring ID mappings in Active Directory Users and Computers for Windows Server 2016 (and subsequent) versions.
Typically it is a good idea to configure all the required ID mappings before you mount a GPFS file system for the first time. This configuration of ID mappings ensures that IBM Storage Scale stores only properly remapped IDs on the disk. However, you can add or delete ID mappings at any time while a GPFS file system is mounted. IBM Storage Scale checks the mapping changes every 60 seconds and uses updated mappings immediately.
When you configure an IDMU mapping for an ID that is already recorded in file metadata, you must be careful to avoid corrupting IDMU mappings and disrupting access to files. An auto-generated mapping that is already stored in an access control list (ACL) on disk continues to map correctly to a Windows SID. However, the SID is now mapped to a different UNIX ID. When you access a file with an ACL that contains the auto-generated ID, the access appears to IBM Storage Scale to be access by a different user. Depending on the file access permissions, the ID might not be able to access files that were previously accessible.
To restore proper file access for the affected ID, configure a new mapping and then rewrite the affected ACL. Rewriting replaces the auto-generated ID with an IDMU-mapped ID. To determine whether the ACL for a particular file contains auto-generated IDs or IDMU-mapped IDs, examine file ownership and permission information from a UNIX node, for example by issuing the mmgetacl command.