LDAP Connector Passwords¶

Where you configure it, the LDAP Connector sets passwords on the accounts JIM manages, over JIM's password channel. This page covers setting passwords on each directory type, and the password policy JIM discovers from the directory.

Setting Passwords¶

Credential attributes such as unicodePwd and userPassword are never imported and can never be used in an Attribute Flow; see Credential attributes are never managed for the full list and the reasoning. The LDAP Connector writes passwords itself, on a separate channel (Passwords covers that channel across all Connectors), with two rules specific to directories.

Use LDAPS. A password set puts the password on the wire, so an unencrypted connection exposes it to anyone on the network path. By default JIM will not stop you: if "Use Secure Connection (LDAPS)?" is off, passwords are still set and a warning is written to the service log on every run, because some deployments genuinely cannot offer TLS on their directory and locking them out of password management entirely helps nobody.

That default exists because JIM cannot always tell an encrypted connection from an unencrypted one; a signed and sealed bind is encrypted and does not look it from the system's settings, so refusing on the settings alone would refuse a valid configuration. Once you know your connection is encrypted, turn on Only send passwords over an encrypted connection on the Connected System's Settings tab, under Passwords, and JIM refuses to send rather than warning. Nothing is discarded when it refuses: queued password changes wait, and accounts stay owed their first password. See Password Synchronisation, which describes that setting and the one beside it.

Active Directory decides for itself regardless. It refuses a password write unless the connection is encrypted or the bind is signed and sealed, so in practice LDAPS is required there; JIM reports that refusal with encryption named as the likely fix.

389 Directory Server decides for itself too. It accepts the Password Modify operation only over a secure connection, answering "Confidentiality required" on an unencrypted one, and has no setting that allows it, so a Connected System that sets passwords on 389 Directory Server must have "Use Secure Connection (LDAPS)?" on. If the directory's certificate is issued by a private certificate authority, add that authority under Admin > Certificates first (see Certificate validation).

Directories other than Active Directory use the standard extended operation. JIM sets passwords through the LDAP Password Modify extended operation (RFC 3062) and never writes the userPassword attribute directly. Directories apply their configured password hashing to the extended operation, but store a directly written userPassword value exactly as supplied, which would leave the password readable in the directory. If a directory does not advertise support for the extended operation, JIM reports a configuration fault rather than falling back to an unsafe write.

Active Directory and Samba AD use unicodePwd, which the Connector encodes correctly on your behalf.

Only Active Directory and Samba AD apply an expiry choice per account. They apply every choice under After the password is set. OpenLDAP, 389 Directory Server and generic directories govern expiry through whichever password policy applies to the account, with no portable per-account override, so they apply only Age according to the Connected System's own policy. Ask one of them to require a change at the next sign-in, or for a password that never expires, and the password is still set, but the delivery's Activity completes with a warning naming what was applied, and the Set Password dialog, the REST API and PowerShell report the outcome as set with a warning. Enabling the account as the password is set is reported the same way, because these directories have no enabled flag for JIM to set. To have a person change a password at their next sign-in on these directories, configure that in the directory's own password policy.

Check the channel before relying on it. The Connected System's Passwords tab carries a Password Channel panel with a read-only preflight covering the things that commonly stop a password set: encryption, the mechanism, whether the service account may actually reset passwords where JIM provisions, and whether the directory's password policy could be read. It writes nothing, so it is safe to run against production. See Password policy and the password channel.

There is no way to prove the whole chain without really setting a password somewhere, and JIM does not offer one: every route to it is a password reset against a real account. The preflight covers what surrounds the password, which is where most failures are.

Enabling new Active Directory accounts¶

Active Directory refuses to hold a user account enabled while it has no password, and JIM can only set a password once the account exists. A Synchronisation Rule whose userAccountControl Attribute Flow asks for an enabled account, such as 512, therefore needs an Initial Password on Active Directory. The same refusal meets a flow that enables an account later, before its password has been delivered: a pre-hire created disabled, say, whose start date arrives while the Initial Password is still queued, retrying or parked. In both cases JIM handles the order for you:

The account is held disabled.
When the userAccountControl value is a single number with ACCOUNTDISABLE (0x2) clear, JIM sends it with ACCOUNTDISABLE added: 512 is sent as 514, and 66048 as 66050. A Create is sent that way whenever an Initial Password follows it. An Update that enables the account is sent as your flow asks, and is sent again with ACCOUNTDISABLE added only if Active Directory refuses it for want of a password while one is still owed to the account, so an account that already has a password is enabled straight away. Only the value sent to the directory changes. The Pending Export keeps the value your Attribute Flow asked for, and that is what the account is checked against. Until the confirming import reports what the account holds, the Connected System Object shows no userAccountControl value from the export, because the directory was not given the value your flow asked for.
The password enables it.
The Password Delivery Service sets the password and enables the account, because your Attribute Flow asks for it enabled, typically within seconds of the password becoming due. It does so whatever Enable the Connected System Object once the password is set says: the account was disabled only until it had a password. The delivery's Activity says that JIM held the enable back until the account had a password.
The confirming import waits for the password.
An import that still finds the account disabled while its password is owed (queued, being delivered, or parked) holds the change: it is not retried, no "not confirmed" warning is raised, Enforce State does not put the enabled value back in the meantime, and a synchronisation preview proposes no such correction either. Enforce State still corrects the account's other attributes at once: a value changed in the directory while the password is owed is put back by the next synchronisation that processes the account, as on any other account. Once the password is delivered, the next import that returns the account confirms the value your Attribute Flow asked for: the delivery clears only ACCOUNTDISABLE, so 66050 becomes 66048, and leaves "Password never expires" as your flow set it (see the next paragraph).

Your userAccountControl Attribute Flow decides "Password never expires" too. The flag (DONT_EXPIRE_PASSWORD, 0x10000) lives in userAccountControl beside the enabled state, so where an export has written an account's userAccountControl by the time its Initial Password is delivered, the delivery leaves the flag as your flow set it, whatever After the password is set says. To have such passwords never expire, set the flag in the flow itself. For the read-modify-write flow most directories use, start from 66048 rather than 512, or set the bit on whatever the flow computes:

SetBit(EnableUser(Coalesce(cs["userAccountControl"], 512)), 65536)

A flow that leaves the flag off gets a password that ages by the domain's policy even under Never expires, and the delivery's Activity says so. Require a change at the next sign-in is still applied, because it belongs to the password rather than to the flag, but Active Directory and Samba AD ignore it on an account whose password never expires: where your flow sets the flag, the delivery's Activity completes with a warning saying the change will not be asked for. With a Static Initial Password that means every account keeps the one shared password, so do not combine the two. After the password is set decides the flag only for accounts whose userAccountControl no export has written, such as an account whose Create carries no userAccountControl value.

Your userAccountControl Attribute Flow stays exactly as it is, and decides whether the account is enabled from the moment it is created: the password's delivery completes only the enable JIM held back, and leaves an account your flow creates disabled as it is (see Accounts your Attribute Flow creates disabled). A change to the person while the account waits is exported as usual. JIM decides whether a password follows at the moment each batch is sent: for a Create, from the provisioning Synchronisation Rule's settings; for an Update, from whether a password is still owed to the person on the Connected System, of any origin.

If the person leaves while the account waits, the waiting enabled value never reaches the account. Before the confirming import, the disabled value your flow now asks for replaces the waiting enabled one, as any different userAccountControl value does. Once that import has seen the account created disabled, the account already holds what your flow now asks for, so the next synchronisation withdraws the waiting enabled value and exports nothing. A password still owed is delivered as usual and leaves the account disabled, because no enabled value is waiting for it any more and your flow decides the account's enabled state. If you would rather the person who left had no password at all, cancel it under Operations > Passwords; the cancelled change stays listed there, and the account stays disabled with no password.

JIM changes the value it sends only for an enabled userAccountControl value Active Directory would refuse: on a Create while an Initial Password follows, and on an Update that Active Directory refused for want of a password while one is still owed. A Create that carries no userAccountControl value (Active Directory creates that account disabled on its own), one your Attribute Flow already creates disabled, and an Update to an account that already has a password are sent exactly as your flow asks. Samba AD accepts an enabled account with no password, so JIM sends it the value unchanged, as it does on every other directory. So does Active Directory where its password policy allows an account with no password: it accepts the enabling Update, and the account is enabled before its password is delivered.

A password is owed only until it expires. A queued password expires after the Connected System's initial password time to live (see Password Synchronisation), 7 days by default, or when you cancel it. An enabling Update after that is sent as your flow asks, and the export reports the error in the table below. Where your pre-hires are created more than a week before they start, and their passwords may not be delivered in that time, lengthen the time to live.

When the password cannot be delivered, the account stays disabled; nothing is lost.

Password	What happens to the account	What you do
Retrying (the directory could not be reached)	Waits, disabled	Nothing; JIM retries on the Connected System's Password Synchronisation schedule.
Parked (the directory refused the password)	Waits, disabled; nothing is retried or reported against the export meanwhile	Correct the Synchronisation Rule's Initial Password settings, which releases it, or retry it from Operations > Passwords. Once it is delivered, the account carries on as in the steps above.
Expired, cancelled, or never queued	The next import of the Connected System stops waiting, whether or not it returns the account, and the export after it writes your flow's enabled value, which Active Directory refuses: the export reports "Active Directory will not enable an account that has no password"	Set a password on the account with the set-password action, enabling it there, and the export's next attempt succeeds.

An expired or cancelled password changes nothing in Active Directory, so a Delta Import has nothing to report for the account; JIM stops waiting at the next import all the same, Delta or Full.

Accounts your Attribute Flow creates disabled¶

An account your Attribute Flow creates disabled stays disabled when its Initial Password is delivered. Where an export has written an account's userAccountControl by the time its Initial Password is delivered, your Attribute Flow decides whether the account is enabled, whatever Enable the Connected System Object once the password is set says: the delivery completes an enable JIM held back (see Enabling new Active Directory accounts), and otherwise leaves the enabled state as the last export wrote it. A pre-hire who has not started yet, or a person whose status is archived, gets a password but no enabled account until your flow enables it. This holds on Active Directory and Samba AD alike, and the delivery's Activity says that the enabled state was left to the Attribute Flow. "Password never expires" is left to the flow in the same way (see Enabling new Active Directory accounts).

The same goes for an account a later export disables while its password is still owed: a person who leaves before the password lands, or an account a Deprovisioning Action of Delete disables rather than removes, because the Connected System's Delete Behaviour is Disable with Disable Attribute userAccountControl. The delivery leaves it disabled, even if its password is cancelled and later retried. If the password comes due while that export is still being sent, the delivery waits for the export to finish rather than enable the account. If an export changes the account's userAccountControl in the moment between the delivery reading it and writing it, the delivery leaves the export's value in place and is tried again, deciding afresh from what the export wrote; its Activity says the account's flags changed while JIM was applying them.

Enable the Connected System Object once the password is set therefore decides only for accounts whose enabled state no export has written by the time the password is delivered, such as an account whose Create carries no userAccountControl value, which the directory creates disabled on its own. On, the delivery enables them; off, it leaves them as they were created. That holds whichever password is the account's first: the Initial Password, a password change that was already waiting for the person when the account was created, or a password an administrator sets without choosing to enable it while the account is still waiting for its first one (Passwords). Otherwise a password set on every Connected System changes neither flag: it leaves "Password never expires", and the enabled state, as each account has them.

An administrator who sets a password on one account is the one exception to all of this: an enable they choose is applied, and so is their choice under After the password is set, which sets "Password never expires" for Never expires and clears it for the other two. Where your flow disagrees and its Synchronisation Rule has Enforce State on, the next synchronisation puts the flow's value back, and the delivery's Activity completes with a warning saying so, because a change at the next sign-in may then stop being asked for.

Password policy discovery¶

Whenever JIM retrieves or refreshes the schema, and again when the Password Channel preflight runs, the Connector reads the directory's password policy so a generated password satisfies it. Passwords explains what the figures mean and how to read a blank one; this section says where each directory type keeps its policy, what JIM reads from it, and how it decides that some objects may be governed by a different policy. Discovery never fails a schema refresh: where a search is refused or returns nothing, the Connector records why and the panel says so.

Active Directory and Samba AD
The domain policy is read from the domain root (the root DSE's defaultNamingContext): minPwdLength, pwdHistoryLength, maxPwdAge, minPwdAge, and the complexity flag in pwdProperties, which JIM reports as three of five character classes. Fine-Grained Password Policies are detected, not read, by searching the Password Settings Container (CN=Password Settings Container,CN=System,<domain DN>): any result means some exist, an empty result means JIM could not tell, and only a domain whose functional level is below Windows Server 2008 (where they cannot exist) is reported as having none.
OpenLDAP
The policy is the ppolicy overlay's, and JIM looks for it only when the root DSE advertises the password policy request control (1.3.6.1.4.1.42.2.27.8.5.1) in supportedControl; without it the directory is reported as publishing no policy. JIM reads the overlay's configuration under cn=config (the olcOverlay=ppolicy entries, whose olcPPolicyDefault names the default policy entry and whose olcPPolicyCheckModule names a check module), then the pwdPolicy entries under the first user naming context: pwdMinLength, pwdInHistory, pwdMaxAge and pwdMinAge (the ages in seconds, shown as days). A value of zero means the rule is off and shows as blank; required character classes are not published. When the overlay's configuration cannot be read and exactly one pwdPolicy entry exists, that entry is the policy; when several exist, JIM cannot know which is the default and reports the configuration as not readable. No pwdPolicy entry at all is reported as no policy configured. The directory applies further checks JIM cannot see when pwdCheckQuality is 1 or 2 and a check module is named (pwdCheckModule on the policy, or olcPPolicyCheckModule on the overlay); when the overlay configuration could not be read, pwdCheckQuality alone decides. Overrides: any entry carrying pwdPolicySubentry, more than one pwdPolicy entry, or two databases with different default policies means some exist; an empty probe or a refused search means JIM could not tell.
389 Directory Server
The global policy is read from cn=config, honouring the switches that gate each rule: passwordMinLength and passwordMinCategories only when passwordCheckSyntax is on (more than one category is reported as complexity required, counted over 389's five classes: upper, lower, digit, special and 8-bit), passwordInHistory only when passwordHistory is on, passwordMaxAge only when passwordExp is on, and passwordMinAge when it is above zero; the ages are in seconds. The directory applies further checks JIM cannot see when syntax checking is on and any of passwordDictCheck, passwordPalindrome, passwordMaxRepeats, passwordMaxSequence, passwordMaxSeqSets, passwordMaxClassChars, passwordMinDigits, passwordMinAlphas, passwordMinUppers, passwordMinLowers, passwordMinSpecials, passwordMin8Bit or passwordMinTokenLength is set. One of those deserves naming: 389's syntax checking also refuses a password that contains a run of passwordMinTokenLength characters (3 by default) from the account's own name, uid or mail attributes, which JIM cannot model. A password JIM generates, or a static initial password, that trips it is parked with the directory's own words rather than retried, and the administrator sees it on the Connected System; Passwords says how parked work is released. Overrides are subtree and per-object policies, probed in each user naming context (up to five) for an nsPwPolicyContainer entry or an entry carrying pwdpolicysubentry: a result means some exist; an empty result, a refused search or an administrative limit on an unindexed search means JIM could not tell. 389 offers no way to prove that none exist. If cn=config cannot be read, the configuration is reported as not readable and the override answer is could not tell; the read is granted, to exactly the attributes named here, by the cn=config rule under 389 Directory Server below.
Generic directories
No policy is read; the directory is reported as publishing none.

Discovery costs at most three searches per directory type, so it adds nothing you will notice to a schema refresh.