Security Compliance

How to convert existing AD security groups to ARM groups

This article describes the related functionality in the WebAPI that makes it possible to convert/assimilate existing security groups to ARM groups.

First published date

3/14/2023 9:18 AM

Last published date

9/22/2023 6:26 AM

Overview

  • In certain environments it can be more convenient to convert/assimilate the actual AD security groups to ARM groups.

Product section

Access Rights Manager

Resolution

To convert the existing security groups to ARM groups the function Filesystem.AssimilateGroupsForPath (POST) from the ARM WebAPI is needed. Further information is found in the ARM WebAPI documentation .
 

This function assimilate(s) Active Directory group(s) to the application in the ARM Groupwizard. The group(s) will be annotated with necessary ARM information in the Active Directory. The LDAP attribute 'description' is used for this. Former data in this attribute are lost. After successful execution, the groups are recognized in the ARM Groupwizard and can be used without restriction.

Optionally, the name of the groups can be forced to change as defined in the ARM GroupWizard Change Configuration.

This function only supports the ARM GroupWizard operation modes with local, global or universal groups. The operation mode for nested group application is not supported. If this mode is primarily defined in ARM the API function is not compatible.
 

Note

 Assimilating an AD group into ARM is only useful and applicable if the following group characteristics are matching:

  • The group type is aligned with the ARM GroupWizard group type definition (operation mode), otherwise it will be not detected as ARM group later
  • The purpose of the AD group should be restricted to only access rights control of one dedicated file system directory.

Preconditions

  • The ARM GroupWizard configuration must be defined completely  
  • The group account domain origin should correspond with the ARM GroupWizard configuration definition.
  • The Active Directory account information required for assimilation must be available in the ARM (origin domain scan required)
  • All needed AD and file server write credentials must be defined
  • The file server credentials additionally need the permission to create a file. ARM will create a hidden file .id.8man to store essential control information. The file is encrypted.

Example

POST /api/v1/filesystem/AssimilateGroupsForPath HTTP/1.1
Host: localhost
Content-Type: application/json
Cache-Control: no-cache
{
    "PathUriKey" : "path:///fs/\\\\Server\\share\\folder",
    "GroupPermissions" : [
        {
            "AccountUriKey" : "sid:///ad/S-1-5-21-3786657226-1431040019-1912278583-88803",
            "AccessMask" : 131241,
            "Inheritance" : 3,
            "Propagation" : 0
        }],
    "AdaptOptionFlags" : 0,
    "Comment" : "Test"
}
 

Details

The API function is just applicable for such access categories which are selected for the administrator. (see figure below)
image.png
 

The needed API parameters can be found below.

The Access mask is according to Microsoft's enum definition. See also (© 2023 Microsoft, available at https://learn.microsoft.com/de-de/dotnet/api/system.security.accesscontrol.filesystemrights?view=netframework-4.8 , obtained on March 14th, 2023)

Propagation and inheritance are combined technical parameters. The semantic is derived from a combination of both values. See note column.

image.png


Response


image.png