midPoint Active Directory and LDAP connectors

Correlation is the step where midPoint decides, for each account already sitting in Active Directory or LDAP, which identity from the authoritative source it belongs to. Get this right before any provisioning runs. If midPoint cannot link an existing account to a person, its next synchronization may create a second account for that person, and the duplicate then carries entitlements that nobody reviewed. The correlation rule set is therefore the first design decision in a migration, ahead of mappings and roles.

The main decision is which attribute pairs an account with an identity. An employee identifier from the HR source, copied into a directory attribute, is usually the strongest choice because it is stable and unique. A login name such as sAMAccountName or uid is familiar but changes when people marry, transfer or are renamed, and it can be reused. Email addresses and display names are weaker still. Whatever you pick, confirm in your own directory which attribute is populated for every account type, how many accounts hold a value that matches no HR record, and whether any value is shared by more than one account. Those three counts predict how much manual review the migration needs more reliably than any rule design.

midPoint's correlation rules can combine several attributes and assign a situation to each candidate account. The outcomes you must plan for are a single confident match, several candidates for one account, and no candidate at all. Ambiguous matches should not be resolved automatically by guessing. Route them to a review queue with the candidate identities shown beside the account attributes, and decide in advance who approves each link and what evidence they check. Accounts with no match are usually service accounts, shared mailboxes, leavers still present in the directory or contractors outside the HR feed. Classify them explicitly, either as unmanaged, as candidates for disablement after a defined period, or as accounts to be linked manually, rather than letting them drift into the default case.

The review step for accounts that match nobody needs an owner, a list and a decision rule before the first synchronization runs. Export the unmatched set from the directory, group it by container or organizational unit and by last logon date, and have the application owners confirm which accounts they need. Record each decision so that auditors can later see why an account was linked, left unmanaged or scheduled for removal. Keep the correlation rules and their test results under version control, and re-run the correlation in a non-production environment against a copy of the directory before you apply it to production.

Confirm the matching attributes and their data quality with your directory and HR teams before you choose rules. Ask for sample extracts, the count of accounts per attribute value state, and the owners of each attribute. The answers determine whether correlation can be largely automatic or whether a sizeable review effort is needed, and that effort should be reflected in any fixed-scope plan. Evolveum's connector documentation describes the LDAP and Active Directory connectors that read these attributes, so verify with your own test directory which attributes the connector returns before you write the rules.

The first decision is whether midPoint sets a password when it creates an account at all. The main options are a generated initial password delivered out of band, a password chosen by the service desk, or no initial password, with the user setting one through self-service on first use. Each option changes what midPoint holds in memory, what the connector sends to the directory, and who ever sees the value. Make this choice with your directory administrators before mapping work begins, because it determines whether the password is an attribute in an outbound mapping, a separate credential operation, or absent from provisioning entirely. Record the decision with a named owner so the connector configuration can be reviewed against it.

Self-service password changes and resets need their own rules. In midPoint, the rules for a new password value come from value and credential policy objects, which you define to cover length, character classes, reuse and history. Confirm the exact policy object types for your version in the connector and product documentation. These rules are a second layer on top of the password policy the directory enforces, so they must not be looser than the directory's own requirements. If midPoint accepts a value that Active Directory or the LDAP server rejects, the user sees a failure that is hard to trace back to the policy. Ask your directory administrators which policies apply to the target container, including any fine-grained policies, and test rejected values end to end in a non-production environment before go-live.

Active Directory and generic LDAP directories handle passwords differently, so a mapping cannot be copied from one to the other. In Active Directory, passwords are written through a dedicated attribute that the directory accepts only over an encrypted session, and whether an account is enabled, disabled or required to change its password at next logon is controlled by account control flags on the same object. A password write and a flag change can therefore interact, and the order of operations matters. Generic LDAP directories typically store a hashed password in a different attribute, may or may not expose a must-change state, and may apply password policy overlays that vary by product. Confirm the attribute names, transport requirements, hashing behavior and flag semantics with your directory administrators and with the connector documentation for your midPoint version.

Notifications and logs are where passwords most often leak. A new-account or reset notification should carry instructions or a one-time link, never the password itself, and its template should be reviewed for any variable that could expose the value. Check that the connector, mappings and tasks do not write password values to application logs, debug output, task results or the audit trail at the log levels you run in production. Raise the logging level only on a test account, then search the collected logs for a known test value. If you ever need to deliver a first secret out of band, decide the channel in advance and document who may view it. Treat this as the functional check, and pair it with the audit and credential protections covered in your security review.

Test the midPoint Active Directory and LDAP connectors in four layers before any change reaches the production directory: connection and schema, provisioning operations, correlation and reconciliation, and failure behavior. Start with the ConnId connector configuration on the resource object. Confirm that the test connection succeeds using the bind account you plan to use in production, that the schema read by the connector includes the object classes and attributes your mappings depend on, and that the bind account holds only the rights your design requires. Record the midPoint version and the connector version together, because either can change behavior during an upgrade. Confirm the supported combinations in the connector documentation for your release.

Next, test each provisioning operation in a non-production domain or a dedicated test OU. Cover create, update, disable, and delete for accounts, and add and remove for group memberships. For each case, write down the expected result before running it: attribute values, OU placement, the enabled or disabled state, the groups that should change, and the groups that must stay untouched. Where your midPoint version offers simulation or preview of intended changes, use it first and compare the preview with the directory result. An illustrative leaver case might expect the account to be disabled and moved, its project groups removed, and its shared mail distribution memberships left alone. Any gap between expected and actual results is a mapping or policy defect to fix before go-live.

Correlation tests need an extract of existing directory accounts, handled under the data protection approval your organization has for test data. Run the correlation rules against that extract and count the results in three groups: one match, no match, and multiple matches. Each multiple match must be resolved by a rule or a manual decision before cutover, because it can otherwise link the wrong identity. Then run a reconciliation task in a mode that reports differences without applying them. Review accounts that exist in the directory but have no midPoint owner, and attributes that have drifted from the source of truth. Agree in writing what count of unexpected differences blocks go-live, and who signs off on exceptions.

Failure tests show whether the design stops safely. Simulate an unreachable domain controller by pointing a test resource at a wrong host or blocking the LDAP or LDAPS port in the test network. Simulate a rejected password by submitting one that violates the domain password policy. For each case, confirm that the task stops or marks the affected objects in error, that the resource state reflects the failure, and that a retry after recovery does not create duplicate accounts or reapply a partial batch. Check the task error handling and retry settings in your version, and confirm that the directory receives no bulk changes from a failed run. Treat any flood of unintended writes as a stop condition for go-live.

Keep evidence that a reviewer can follow without asking the implementation team. Store the test plan with case identifiers, the expected and actual results for each case, and the exported resource, mapping, and task configuration at the tested versions. Add the midPoint and connector versions, the task logs from the failure tests, the audit records of test changes, the reconciliation reports, and the signed exception list. Attach this bundle to the change record with the name of the owner who accepted each residual difference. This record shows the auditor and the operations team what was tested, what passed, and what was accepted, and it gives the next upgrade a baseline to repeat.