Provisioning works well.
Synchronization works well.
This connector is the recommended way to connect to the Active Directory since connector version 184.108.40.206 (bundled with midPoint 3.3.1 and 3.4).
The .NET-based Active Directory connector is deprecated and it is no longer supported.
The connector can be used for provisioning and synchronization with Active Directory using the LDAP protocol.
(Remote connector server is not needed for this connector)
Administrative Account for Provisioning/Synchronization
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
- Reset user passwords and force password change at next logon
- Read all user information
- 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?)
- Read all inetOrgPerson information
Version: most recent stable version
(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:
objectCategoryare formally defined as mandatory attributes in the
topobject 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
limitationsmechanism 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
userobject 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-3379Getting issue details... STATUS ).
Resource Configuration Example
- 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.
Note: 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:
- Active Directory Connector (LDAP)
- Active Directory Tips&Tricks
- Active Directory Multi-Domain
- Active Directory with the legacy .NET connector
- AD Connector Design Notes