ActiveDirectory & LDAP provisioning

The Memority’s ActiveDirectory & LDAP connector can be used to provision an ActiveDirectory or any LDAP directory. However, some prerequisites must be respected to be able to provision the application.

This page explains how the provisioning works in Memority and prerequisites to be able to provision an application.

Definitions

What is a provisioning ?

Provisioning is used to automatically create, update and deactivate/delete accounts in target application and ensure that data are consistent between Memority (the authoritative source) and the application (the target).

It means that once Memority provisions your application, you shouldn't perform any creation, modification or deactivation/deletion of accounts directly in the application, it will be done automatically for you.

Memority ActiveDirectory & LDAP connector

The Memority ActiveDirectory & LDAP connector is used to create, update and at the end deactivate/delete objects in a target application (user accounts, groups or organizations) thanks to LDAPS commands.

The ActiveDirectory & LDAP connector, like any of others Memority connectors, computes delta between Memority data and target data at each event occurring on the Memority object to determine the action to perform:

• Create an new object

• Link an existing object

• Update an existing object

• Delete / Deactivate an existing object

To perform these actions, the Memority ActiveDirectory & LDAP connector works thanks to 5 methods that must be defined in the configuration : SEARCH, GET, CREATE, UPDATE and DELETE.

When an event is detected on an object, and that event impacts the provisioning because it has been defined in mapped attributes, then the following process will be triggered:

• If an application’s object is already linked to the Memority’s object, then the connector use GET method to check if there is delta between Memority and application object

• If a Memority’s object to provision is not linked to an existing application' object, then the connector use SEARCH method to check if there is already an existing application object matching SEARCH method

• Whenever an action method is called (CREATE, PATCH or DELETE), a GET action is performed after that to validate the provisioning worked well. It means there 3 requests for each action performed by the connector.

• When the identity authorization is removed, the connector will use the DELETE method to deactivate or delete the account in the application.

Memority accesses to the schema of the directory and so is able to provision custom attributes.

The correlation key between Memority and ActiveDiretory account is the ObjectID, so even if the ActiveDirectory account is moved or modified locally, Memority will be able to find it and overwrite modifications.

The correlation key between Memority and LDAP account is the DN, so even if the ActiveDirectory account is moved or modified locally, Memority will be able to find it and overwrite modifications through the search method.

ActiveDirectory & LDAP authentication prerequisites

To be able to requests directory actions, Memority’s connector need to authenticate against the application. The ActiveDirectory & LDAP connector bind to targeted directory in LDAPS thanks to an IPSec tunnel set between Memority’s network and client’s network.

To be able to set the LDAPS binding, Memority must trust the whole certificate chain that generated the directory SSL certificate. So any private root certificate must be added to the dedicated Synchronization service setting sync.ssl.trust.trustStore to be trusted.

The connector bind with an account that should have administration rights on the account. The provisioning account’s password shouldn’t expire to avoid any issue.

ActiveDirectory configuration prerequisites

Memority ActiveDirectory connector officially supports versions since Windows Server 2019.

The schema must be readable by the provisioning account to be able to get existing attributes.

Configuration

Connector configuration

To be able to provision or import data from an ActiveDirectory or a LDAP directory, you first need to configure a connector to establish a connection to it.

This chapter will give you information about ActiveDirectory & LDAP connector configuration, you can get global information about connector configurations in Application Connector.

Bear in mind that if your directory is not published on internet, you will need to first request an IPSec tunnel setup to be able to join the directory from Memority as explained in prerequisite AUTH1.

More information in Memority Support Portal

Binding configuration

To configure the connector, you will need to define a set of properties specified below.

We strongly advise to use settings to specify these properties and be able to switch them per environment.

To use a setting in a connector, set the value as “settings:” + the setting’s identifier.

SSL configuration

The connector can be configured to use SSL or not. The both options are described below.

The SSL is mandatory for production environments.

ActiveDirectory doesn’t allow account’s password provisioning when the SSL connection is not set.

Without SSL

To configure the connector, you will need to define a set of properties specified below.

To bind the directory without SSL, you usually need to use port 389. It must be enable in IPSec tunnel to use it.

With SSL

To configure the connector, you will need to define a set of properties specified below.

To bind the directory with SSL, you usually need to use port 636. It must be enable in IPSec tunnel to use it.

To be able to authenticate, the connector must be able to validate the server’s SSL certificate chain. If the certificate has been generated from a custom authoritative certification, you need to root and intermediate certificate in SYNC service setting sync.ssl.trust.trustStore.

Custom attributes

The LDAP connector uses standard schema to retrieve objects attributes. If you extended your directory schema, you can specify them in the connector to be able to retrieve them.

To configure the connector, you will need to define a set of properties specified below.

Object filters

When you import or discover accounts with the ActiveDirectory & LDAP connector, any objects below the base context organizational unit will be imported.

To configure the connector, you will need to define a set of properties specified below.

Next chapters will give you some common configurations examples.

Object filter is apply on imports/account discovery tasks and on provisioning. Any object outside the scope cannot be managed by the connector, included groups to assigned to accounts.

If you want different scopes for provisioning and imports/account discovery, you can use objectIgnoredCondition in application configuration (Object Schema Mapping Definition) or duplicate the connector configuration.

Filter on user account only

You can use the following filter on objectCategory attribute to get only user accounts from an ActiveDirectory.

(objectCategory=person)

Filter on organizational units

You can use the following filter on msDs-parentdistname attribute to get objects from a specific organization unit from an ActiveDirectory (it must be specified with its DN).

(msDs-parentdistname=OU=Users,DC=internal,DC=my,DC=com)

Filter on group assigned

You can use the following filter on memberOf attribute to get accounts directly assigned to a group from an ActiveDirectory (it must be specified with its DN).

(memberOf=CN=MyApp-User,OU=applications,DC=internal,DC=my,DC=com)

To get any account assigned to the group, even through nested groups, you need to filter on memberOf:1.2.840.113556.1.4.1941: (memberOf:1.2.840.113556.1.4.1941:=CN=MyApp-User,OU=applications,DC=internal,DC=my,DC=com)

Application configuration

To be able to provision or import data from an ActiveDirectory or a LDAP directory, you need to configure a data model mapping.

This chapter will give you information about ActiveDirectory & LDAP specific attribute mapping , you can get global information about application configurations in Application.

Distinguished Name definition

The Distinguished Name (DN) is a mandatory attribute that should be unique in the directory.

The distinguished name attribute is used as correlation key, so you need to define the target attribute to __NAME__.

The value can be set directly thanks to a simple or a custom mapping, but you can also use the built in constructDnFromRdnOpenAm normalization rule.

The connector handle automatically object move in case of DN modification, there is no particular action to do.

<attributeMappingDefinition>
	<targetAttributeId>__NAME__</targetAttributeId>
	<targetAttributeType>STRING</targetAttributeType>
	<mandatory>true</mandatory>
	<simpleAttributeMappingStrategyDefinition>
		<inputAttributeId>id</inputAttributeId>
		<normalizeRule class="constructDnFromRdnOpenAm">
			<config xsi:type="dmn:ConstructDnFromRdnOpenAmRuleConfigurationType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
				<baseDn>ou=Users,dc=internal,dc=my,dc=com</baseDn>
				<rdnAttributeName>uid</rdnAttributeName>
			</config>
		</normalizeRule>
	</simpleAttributeMappingStrategyDefinition>
	<multiValued>false</multiValued>
</attributeMappingDefinition>

Account status

The account status is managed in ActiveDirectory thanks to attribute userAccountControl. This attribute is a bit mask to determine account status and more information such as password expiration (UserAccountControl property flags - Windows Server | Microsoft Learn)

To manage the account status, you can set the default value according to enable status (512 for active accounts, 514 for inactive accounts).

<attributeMappingDefinition>
	<targetAttributeId>userAccountControl</targetAttributeId>
	<targetAttributeType>INTEGER</targetAttributeType>
	<mandatory>true</mandatory>
	<secret>false</secret>
	<customAttributeMappingStrategyDefinition>
		<computeRule>
			<script><![CDATA[
					return IDM_OBJECT.enabled as Boolean ? "512" : "514"
				]]></script>
		</computeRule>
		<computeRuleAttributeDependencies>
			<dependency>enabled</dependency>
		</computeRuleAttributeDependencies>
	</customAttributeMappingStrategyDefinition>
	<multiValued>false</multiValued>
</attributeMappingDefinition>

You can also use mask computation to enable and disable the account without modifying other flags.

<attributeMappingDefinition>
	<targetAttributeId>userAccountControl</targetAttributeId>
	<targetAttributeType>INTEGER</targetAttributeType>
	<mandatory>true</mandatory>
	<secret>false</secret>
	<customAttributeMappingStrategyDefinition>
		<computeRule>
			<script><![CDATA[
					def userAccountControl = SHADOW.userAccountControl as int
					def enabled = IDM_OBJECT.enabled as boolean
					def disabledMask = 2
					def accountEnabled = ((userAccountControl & disabledMask) != disabledMask)

					// If account status == memority status, return the userAccountControl as is
					if (enabled == accountEnabled) {
						LOG.debug("Provisioning AD User - userAccountControl - {} - No status modification", IDM_OBJECT.id)
						return userAccountControl
					}

					// If account account should be disabled, return userAccountControl + disable mask
					if (!enabled) {
						LOG.debug("Provisioning AD User - userAccountControl - {} - Disable account", IDM_OBJECT.id)
						return (userAccountControl | disabledMask)
					}

					// If account account should be enabled, return userAccountControl - disable mask
					if (enabled) {
						LOG.debug("Provisioning AD User - userAccountControl - {} - Enable account", IDM_OBJECT.id)
						return (userAccountControl ^ disabledMask)
					}
				]]></script>
		</computeRule>
		<computeRuleAttributeDependencies>
			<dependency>enabled</dependency>
		</computeRuleAttributeDependencies>
	</customAttributeMappingStrategyDefinition>
	<multiValued>false</multiValued>
</attributeMappingDefinition>

Password management

Password are managed in ActiveDirectory with attribute unicodePwd. You can also use attribute pwdLastSet to force the password modification on first connection.

These attributes can be set with a mappingStrength option set to WEAK to be applied only on account creation. Thanks to this, users will be able to manage their passwords autonomously.

The Memority password can be used directly, or you can use a new attribute to generate and store a dedicated password. In this case, be sure to set the attributeDefinition as secret and encrypted and use PASSWORD binding to generate it.

Set the unicodePwd mapping as secret to hide the password in audit, logs and reports.

The password modification requests a SSL binding due to ActiveDirectory policies.

<attributeMappingDefinition>
	<targetAttributeId>unicodePwd</targetAttributeId>
	<targetAttributeType>STRING</targetAttributeType>
	<mandatory>false</mandatory>
	<secret>true</secret>
	<simpleAttributeMappingStrategyDefinition>
		<inputAttributeId>password</inputAttributeId>
	</simpleAttributeMappingStrategyDefinition>
	<multiValued>false</multiValued>
	<mappingStrength>WEAK</mappingStrength>
</attributeMappingDefinition>
<attributeMappingDefinition>
	<targetAttributeId>pwdLastSet</targetAttributeId>
	<targetAttributeType>INTEGER</targetAttributeType>
	<mandatory>false</mandatory>
	<secret>false</secret>
	<customAttributeMappingStrategyDefinition>
		<computeRule>
			<script><![CDATA[
				// Set the value to 0 to force password modification on first connection
				return 0
				]]></script>
		</computeRule>
		<computeRuleAttributeDependencies/>
	</customAttributeMappingStrategyDefinition>
	<multiValued>false</multiValued>
	<mappingStrength>WEAK</mappingStrength>
</attributeMappingDefinition>