Stable. Works well.
This connector is the recommended way to connect midPoint with Active Directory servers.
Connector for Active Directory servers based on the LDAP protocol.
This is a specialized version of the LDAP Connector to support the Active Directory LDAP quirks.
This LDAP-based connector is the supported and recommended Active Directory connector to use with midPoint. The old .NET-based Active Directory Connector and Exchange Connector (.NET) are deprecated and they are no longer supported (except for customers that purchased midPoint subscription prior to April 2016 and September 2016 respectively).
LDAP or LDAPS
Capabilities and Features
Active Directory DirSync synchronization supported.
Activation using the userAccountControl attribute.
Simple Paged Results and VLV
|Native attribute names||YES|
Use ri:dn instead of icfs:name
Use ri:GUID instead of icfs:uid
|Scripting||YES||Command execution and Powershell by using WinRM|
This connector is based on the LDAP Connector which was completely rewritten from scratch during 2015-2016.
|Bundled with midPoint|
Official release (experimental)
|188.8.131.52||Polygon||April 2016||Official release (stable)|
|184.108.40.206||Polygon||September 2016||3.4.1||Powershell support. Bundled with midPoint 3.4.1.|
|220.127.116.11||Polygon||October 2016||18.104.22.168||Improved handling od DNs in AD multi-domain environment. MID-2926 - Passing __NAME__ in ConnId Uid class as an additional hint Resolved|
|1.4.4||Polygon||April 2017||22.214.171.124||3.5.1||CredSSP and Powershell and Exchange support.|
|1.4.5||Polygon||3rd July 2017||126.96.36.199||3.6||Powershell improvements.|
|1.5||Polygon||4th October 2017||188.8.131.52||3.6.1||Powerhell support. Alternative objectclass detection. Logging improvements.|
|1.5.1||Polygon||11th December 2017||184.108.40.206||3.7||Powerhell fixes.|
|1.6||Polygon||4th May 2018||220.127.116.11||3.8||Support for CredSSP version 5 and 6 (CVE-2018-0886)|
MS Exchange Support
This connector supports Microsoft Exchange servers in a slightly indirect way.
Firstly, the Exchange attributes are accessible in Active Directory when the Exchange software is installed. The AD/LDAP connector dynamically discovers AD schema and therefore it will discover presence of these attributes. Then these attributes can be manipulated in a normal way. Please note that some Exchange attributes may not be properly propagated in the AD LDAP schema. In such case there is a workaround to specify these attributes in the
operationalAttributes connector configuration property.
Secondly, since version 18.104.22.168 the connector has support to execute commands and powershell scripts remotely using the WinRM interface. This feature can be used to manage Exchange mailboxes and additional settings. Please see Powershell Support in AD/LDAP Connector page for more details.
The connector itself is available under the terms of Apache License 2.0. The connector is using only the LDAP protocol to access Active Directory. We are not using any Microsoft library or any other component that might be subject to Microsoft licensing. To our best knowledge no extra license is needed to use the connector with Active Directory. However the Microsoft license texts are not entirely clear and we are not lawyers. Therefore it is recommended for each user to make his own analysis of the licensing issues. Please use your Microsoft support program and contact Microsoft with the licensing question when in doubt.
Additional Notes for Provisioning
ConnId Result Handlers
Those "result handlers" are an artifact of an original original Identity Connector Framework over-engineering. The handlers are supposed to assist connectors by implementing "mechanism" that the connector or resource does not support - such as search result filtering, data normalization and so on. However, those handler are generic and they know nothing about the particulars of the resource that the connector connects to. Therefore in vast majority of cases those handlers just get into the way and they distort the data. Good connectors usually do not need those handlers at all. Unfortunately, these handler are enabled by default and there is no way for a connector to tell the framework to turn them off. The handlers needs to be explicitly disabled in the resource configuration.
Please make sure you are using the following
enableAttributesToGetSearchResultsHandler is important to be
false, otherwise you may be unable to see all attributes (just identifiers stored in shadow).