# Active Directory with LDAP connector

Status Provisioning works well. Synchronization works well. Active Directory Connector (LDAP)

## Resource Configuration

(Remote connector server is not needed for this connector)

We have successfully tested both provisioning and synchronization of users with the following access privileges using Active Directory domain "Delegate Control" mechanism:

• Create, delete and manage user accounts

• Create, delete and manage groups

• Modify the membership of a group

• Create, delete and manage inetOrgPerson accounts (TODO: is this needed?)

• Reset inetOrgPerson accounts and force password change at next logon (TODO: is this needed?)

 In the new versions of windows the option Create, delete and manage groups disappear from the list to select. Without this permission the proper provision is not possible. The successful tests has been reached with the Domain admin membership for the account used by the midpoint to access the AD.
``Add-ADGroupMember -Identity 'CN=Domain Admins,CN=Users,DC=ad2019,DC=lab,DC=evolveum,DC=com' -Members 'CN=MidPoint,CN=Users,DC=ad2019,DC=lab,DC=evolveum,DC=com'``

For LiveSync, you also need "Replicating Directory Changes" (DS-Replication-Get-Changes) permission (please refer to https://support.microsoft.com/en-us/help/303972 and https://support.microsoft.com/en-ae/help/891995/how-to-poll-for-object-attribute-changes-in-active-directory-on-window).

 All the permissions in AD have own GUID which is unique ID used for the assignment. In case of DS-Replication-Get-Changes permission it is 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/1522b774-6464-41a3-87a5-1e5633c3fbbb).
Powershell command to assign DS-Replication-Get-Changes permission
``````#############
# Module ActiveDirectory is needed to be loaded just once.
# In case of AD: "prefix" the module is not loaded automatically.
#############
Import-Module ActiveDirectory

$path = "AD:DC=ad2019,DC=lab,DC=evolveum,DC=com"$acl = Get-Acl -Path $path$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
[System.DirectoryServices.ActiveDirectoryRights] 'ExtendedRight',
[System.Security.AccessControl.AccessControlType] 'Allow',
(new-object Guid '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2')
)
$acl.AddAccessRule($ace)
Set-Acl -Path $path -AclObject$acl``````

Framework: ConnId
Bundle: com.evolveum.polygon.connector-ldap
Version: most recent stable version

## Connector Configuration

(currently, no published documentation)

 Active Directory LDAP Strangeness Active Directory in the default configuration is not really LDAPv3-compliant server. It has many quirks, extensions, modification and twists the LDAP standard almost beyond recognition. The LDAP connector was modified to survive this brutal "intepretation" of the LDAP specifications. However, there are many things that needs to be taken into account when configuring AD resource: `instanceType`, `nTSecurityDescriptor` and `objectCategory` are formally defined as mandatory attributes in the `top` object class (!!!). This means they are (formally) mandatory for all objects accessed using LDAP connection. But the reality is different. It seems to be OK to create an object without these attributes. Therefore for a proper operation of midPoint we recommend to modify the schema using the `limitations` mechanism in midPoint Resource Schema Handling by setting `minOccurs=0`. (This is already done in the sample referenced below.) The objects can easily have attributes that are not defined in any object classes that they have. E.g. a normal user (the `user` object class) may have attribute `info`. If such extra attributes are used in your AD instance then the best way is to configure them as operational attributes in the connector configuration and define them explicitly in Resource Schema Handling (see MID-3379).

### Resource Configuration Example

``````<connectorConfiguration xmlns:icfc="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/connector-schema-3">
<icfcldap:port>636</icfcldap:port>
<icfcldap:baseContext>DC=evolveum,DC=com</icfcldap:baseContext>
<icfcldap:bindDn>CN=midpoint,CN=Users,DC=evolveum,DC=com</icfcldap:bindDn>
<icfcldap:connectionSecurity>ssl</icfcldap:connectionSecurity>
<t:clearValue>secret</t:clearValue>
</icfc:configurationProperties>
<icfc:resultsHandlerConfiguration>
<icfc:enableNormalizingResultsHandler>false</icfc:enableNormalizingResultsHandler>
<icfc:enableFilteredResultsHandler>false</icfc:enableFilteredResultsHandler>
<icfc:enableAttributesToGetSearchResultsHandler>false</icfc:enableAttributesToGetSearchResultsHandler>
</icfc:resultsHandlerConfiguration>
</connectorConfiguration>``````

### Limitations

• Active Directory LDAP schema is violating LDAP standards and best practices in numerous ways. The connector is build to tolerate these "quirks" in the AD schema. However the underlying LDAP library may complain about the schema issues. It is usually safe to ignore these warnings.

## Recommendation and Notes

To avoid clear-text password visible in the repository, please refer to String to ProtectedString Connector Configuration.

### Full Active Directory Schema

Active Directory has huge schema. The schema when encoded in XSD has several megabytes. This might take several hundreds of megabytes of memory when processed. Make sure that your midpoint instance has enough memory (heap) to handle that. The impact of AD schema can be limited by reducing the number of object classes that are processed by midPoint:

``````    <schema>
<generationConstraints>
<generateObjectClass>ri:user</generateObjectClass>
<generateObjectClass>ri:group</generateObjectClass>
</generationConstraints>
</schema>``````

### Explicit Referential Integrity

We recommend turning off explicitReferentialIntegrity for associations with groups. Active Directory will maintain the group membership after account rename automatically.

Example:

``````...
<association>
<ref>ri:group</ref>
<kind>entitlement</kind>
<intent>group</intent>
<direction>objectToSubject</direction>
<associationAttribute>ri:member</associationAttribute>
<valueAttribute>ri:dn</valueAttribute>
<shortcutAssociationAttribute>ri:memberOf</shortcutAssociationAttribute>
<shortcutValueAttribute>ri:dn</shortcutValueAttribute>
<explicitReferentialIntegrity>false</explicitReferentialIntegrity>
</association>
...``````

### National Characters

Although LDAP protocol and data structures are designed to be safe for use with national characters, Active Directory obviously leaves a large room for improvement in this area. For example, although LDAP specification states that DNs using different national characters should be considered different identifiers, Active Directory might consider them to be the same (see MID-7355).

Therefore, we strongly recommend to avoid use of national characters in Active Directory, especially in the identifiers (`dn` and hence also `cn`). MidPoint polystring functionality is designed especially for this purpose. Following mapping may help create identifier without national characters:

``````<attribute>
<ref>ri:dn</ref>
<outbound>
<source>
<path>givenName</path>
</source>
<source>
<path>familyName</path>
</source>
<expression>
<script>
<code>
'CN=' + basic.concatName(familyName.getNorm(), givenName.getNorm()) + iterationToken + ',OU=Users,DC=example,DC=com'
</code>
</script>
</expression>
</outbound>
</attribute>``````

An equivalent mapping would be probably needed for `cn` attribute as well.

• Evolveum - Team of IAM professionals who developed midPoint

• WILL_NOT_PERFORM - wiki page explaining a lot of error messages returned by Active Directory