<icfs:resultsHandlerConfiguration>
<icfs:enableNormalizingResultsHandler>false</icfs:enableNormalizingResultsHandler>
<icfs:enableFilteredResultsHandler>false</icfs:enableFilteredResultsHandler>
<icfs:enableAttributesToGetSearchResultsHandler>false</icfs:enableAttributesToGetSearchResultsHandler>
</icfs:resultsHandlerConfiguration>Active Directory Connector (LDAP)
Connector for Active Directory servers based on the LDAP protocol.
| Functionality | stable |
| Development status | active (actively developed and maintained) |
| Support status | supported |
| Origin | Evolveum |
| Support provided by | Evolveum |
| Target systems | Active Directory servers |
| Protocol | LDAP/LDAPS |
| Source code | https://github.com/Evolveum/connector-ldap |
Capabilities and Features
| Schema | YES | Determined from standard LDAP schema, experimental support for native AD schema. |
|---|---|---|
Provisioning |
YES |
|
Live Synchronization |
YES |
Active Directory DirSync synchronization supported.1) |
Password |
YES |
|
Activation |
YES |
Activation using the userAccountControl attribute. |
Paging support |
YES |
Simple Paged Results and VLV |
Native attribute names |
YES |
Use |
Scripting |
NO |
Use of dedicated scripting connectors (SSH, PowerHell) is recommended. |
1) For the DirSync synchronization the DS-Replication-Get-Changes ( 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 ) extended right has to be granted.
Interoperability
Following versions of Active Directory are supported:
-
Active Directory Domain Services (AD DS), Windows Server 2022
-
Active Directory Domain Services (AD DS), Windows Server 2019
Active Directory Lightweight Directory Services (AD LDS) or any other variants of Active Directory or related services are NOT supported.
The connector supports only a subset of the operations that are available by using LDAP protocol and at the same time are documented in public Microsoft documentation. The connector does not claim to support all AD operations and complete AD functionality. Basic provisioning functionality is supported and it is tested in numerous real-world deployments. But advanced functionality may not be supported at all. Active Directory is a complex, proprietary and heavily non-standard system. It is not possible for the connector to support all the available operations. We recommend conducting a feasibility testing before deploying this connector. In case some connector functionality is missing then we recommend to purchase midPoint platform subscription to cover the functionality gap.
|
Unsupported Active Directory Versions
Following Active Directory versions (including their variants) are no longer supported, as they are not covered by regular (mainstream) support from Microsoft:
Please see Evolveum support policy details. |
Known Limitations
-
Synchronization based on modifyTimestamp has a simplistic implementation. It does not support SPR, VLV or referral-following functionality. This synchronization method is inherently inefficient and unreliable. It should be used only as a last resort, if no other method is available. Active Directory DirSync method should be preferred whenever available.
-
Minimal fetch strategy does not work reliably. LDAP has no way to specify that the connector wants to fetch all regular attributes except for one. Therefore, the connector has to list all the other attributes of an object, except the one expensive attribute (such as
jpegPhotoormember). However, Active Directory has attributes that cannot be used it a regular (subtree) search. If the list of attributes happen to contain such an "unsearchable" attribute, the request fails. Even worse, AD is not exposing information about search limitations in standard LDAP schema. Therefore, this LDAP-based connector has no way to find out which attributes are not searchable.A symptom of this problem is usually an error:
00002120: SvcErr: DSID-……., problem 5012a.k.a.ERROR_DS_NON_BASE_SEARCH.Possible solution is to use non-standard schema definition data structures which are native to Active Directory. However, this code is not production-ready yet.
-
LDAP connector 3.4 introduced a fail-over mechanism for LDAP servers. However, this mechanism is designed for standard-compliant LDAP server (which AD is not), and it was not tested with Active Directory. Therefore, the fail-over mechanism is not supported for Active Directory.
-
Newer version of AD may not support VLV paging strategy (recognized on Win2022). In case of higher amount of the objects the "Fatal error" is shown under Resource objects listing.
A symptom of this problem is usually an error:
000020EF: SvcErr: DSID-…….., problem 5010 (UNAVAIL_EXTENSION).In case you are facing this issue the solution would be setting pagingStrategy to spr.
MS Exchange Interoperability
Technically, this connector can be used to provision Microsoft Exchange servers in an indirect way by using PowerShell scripts.
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 1.4.2.18 the connector had support to execute commands and powershell scripts remotely using the WinRM interface. This feature can be used to manage Exchange mailboxes and additional settings. This feature was later "separated" to a dedicated PowerShell scripting connector. Please see Powershell Support in AD/LDAP Connector page for more details.
However, support for MS Exchange is not included in the "bundled" support for this connector (see below).
History
| Version | Origin | Binary | Sources | Build Date | ConnId Framework | Bundled with midPoint | Description |
|---|---|---|---|---|---|---|---|
1.4.2.0 |
Evolveum |
December 2015 |
Official release (experimental) |
||||
1.4.2.14 |
Evolveum |
April 2016 |
Official release (stable) |
||||
1.4.2.15 |
Evolveum |
April 2016 |
|||||
1.4.2.18 |
Evolveum |
September 2016 |
3.4.1 |
Powershell support. Bundled with midPoint 3.4.1. |
|||
1.4.2.19 |
Evolveum |
October 2016 |
1.4.2.18 |
Improved handling od DNs in AD multi-domain environment. MID-2926 |
|||
1.4.3 |
Evolveum |
December 2016 |
1.4.2.18 |
3.5 |
|||
1.4.4 |
Evolveum |
April 2017 |
1.4.2.18 |
3.5.1 |
CredSSP and Powershell and Exchange support. |
||
1.4.5 |
Evolveum |
3rd July 2017 |
1.4.2.18 |
3.6 |
Powershell improvements. |
||
1.5 |
Evolveum |
4th October 2017 |
1.4.2.18 |
3.6.1 |
Powerhell support. Alternative objectclass detection. Logging improvements. |
||
1.5.1 |
Evolveum |
11th December 2017 |
1.4.2.18 |
3.7 |
Powerhell fixes. |
||
1.6 |
Evolveum |
4th May 2018 |
1.4.2.18 |
3.8 |
Support for CredSSP version 5 and 6 (CVE-2018-0886) |
||
1.6.1 |
Evolveum |
17th April 2018 |
1.4.2.18 |
TBD |
Fix of security vulnerability: missing check of certificate validity. |
||
2.0 |
Evolveum |
7th November 2018 |
1.5.0.0 |
3.9 |
Native timestamp support. |
||
2.1 |
Evolveum |
17th April 2019 |
1.5.0.0 |
none |
Fix of security vulnerability: missing check of certificate validity. |
||
2.2 |
Evolveum |
31st May 2019 |
1.5.0.0 |
none |
Upgrade of Apache Directory API (may fix some connection issues) |
||
2.3 |
Evolveum |
13th August 2019 |
1.5.0.0 |
4.0 |
Upgrade of Apache Directory API |
||
2.4 |
Evolveum |
22th November 2019 |
1.5.0.0 |
TBD |
Upgrade of Apache Directory API |
||
3.0 |
Evolveum |
3rd April 2020 |
1.5.0.0 |
4.1 |
Separated PowerShell to a dedicated PowerShell Connector. |
||
3.1 |
Evolveum |
20th October 2020 |
1.5.0.0 |
4.2 |
Additional filter fixes at several places. |
||
3.2 |
Evolveum |
31st March 2020 |
1.5.0.0 |
4.3 |
Optional unbind before disconnect |
||
3.3 |
Evolveum |
8th October 2021 |
1.5.0.0 |
4.4 |
Fixed problem with excessive abandons |
||
3.3.1 |
Evolveum |
22nd December 2021 |
1.5.0.0 |
N/A |
Fixing AD "range" mechanism (used for large AD groups) |
||
3.4 |
Evolveum |
25th March 2022 |
1.5.0.0 |
4.5 |
AD dirsync fix (MID-6922). Improved error messages. Minor bugfixes. |
||
3.5 |
Evolveum |
10th October 2022 |
1.5.1.3 |
4.6 |
Added support for configuration discovery. Various AD fixes around userParameters and flags. |
||
3.6 |
Evolveum |
21st March 2023 |
1.5.1.3 |
LDAP integer syntax is mapped to BigInteger, supporting large numbers (MID-4424) |
|||
3.6.1 |
Evolveum |
27th March 2023 |
1.5.1.3 |
4.7 |
Synchronized bundle release with LDAP connector. |
||
3.7 |
Evolveum |
10th October 2023 |
1.5.1.3 |
4.8 |
Fixing of repeated adding of removed UAC attributes. |
||
3.7.1 |
Evolveum |
10th January 2024 |
1.5.1.3 |
4.8.1, 4.9 |
Fixing of default value for 'connectTimeout', 'writeOperationTimeout', 'readOperationTimeout', 'closeTimeout' and 'sendTimeout' configuration attributes. |
||
3.7.2 |
Evolveum |
16th August 2024 |
1.5.2.0 |
4.8.4 |
Update dependencies. Adding third error code for AD X_BIND_REQUIRED error. |
fixes handling of ENABLE attribute
This connector is based on the LDAP Connector which was completely rewritten from scratch during 2015-2016.
Support
This connector is bundled with midPoint distribution. Support for LDAP connector is included in standard midPoint support service (a.k.a bundled support) - however, there are limitations:
-
Only some Active Directory versions are supported (see above)
-
Only some Active Directory features are supported (see above). The connector does not claim to be feature-complete. We recommend conducting a feasibility testing before deploying this connector. In case some connector functionality is missing then we recommend to purchase midPoint platform subscription to cover the functionality gap.
-
PowerShell scripting implemented in this connector is supposed to be used to supplement creation of Active Directory (windows) accounts by using simple scripts. It is not supposed to be used to manage Microsoft Exchange accounts. Management of Exchange accounts can be quite a complex matter, requiring complicated PowerShell scripts. Support for the use of this connector to manage Exchange accounts has to be purchased separately.
|
There may be exception to this rule for the customers that purchased support before the release of midPoint 4.0. In case of any doubts please contact Evolveum sales representatives. |
When dealing with connector issues, please make sure to follow LDAP Connector Troubleshooting Guide.
Licensing
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.
Notes
This connector is contained in LDAP connector bundle, which also contains LDAP connector. Both connectors are specializations of the LDAP connectors. The Active Directory connector has additional support for the LDAP quirks needed to work with AD.
ConnId Result Handlers
|
We strongly recommend to disable all the handlers when working with well-designed connectors in general and when working with our LDAP or AD/LDAP connectors in particular. |
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.
ObjectClass Filters
Natural way to use LDAP is to use "short" search filters, such as (cn=foo). However, such search filter can match objects of several incompatible objectclasses, producing incorrect results.
Therefore a strict way to construct a search filter is to always add an objectclass clause to the filter, resulting in (&(objectclass=inetOrgPerson)(cn=foo)) filter.
Use of such search filter ensures that the results will be correct.
This search filter should work flawlessly on standard-compliance and correctly-configured LDAP servers.
Therefore since connector version 3.2, use of such search filters is tuned on by default.
However, such search filters may cause issues on non-compliant and/or incorrectly configured and populated servers.
In such case, the behavior can be controlled by includeObjectClassFilter configuration property.
Resource Examples
See Also
Was this page helpful?
YES
NO
Thanks for your feedback