More than often when identities are centrally managed in eDirectory it becomes crucial to ensure that the account lockouts are in sync (near real time) between the IDV and connected systems. The two attributes in question are lockedByIntruder (eDirectory) and lockoutTime (Active Directory). lockoutTime is a system maintained attribute in AD which can hold either a zero (means account is NOT locked) or non-zero value (means account locked) where as lockedByIntruder in eDirectory is a boolean type attribute. IDM publisher channel policies can be added to handle the lockout event coming from AD to eDirectory with little customization. The issue comes when the attributes are attempted to be synced on the subscriber channel due to the fact that AD does not allow setting lockoutTime value to a non-zero value to force a lockout for the account in AD via LDAP. AD only allows clearing of the lockout (set lockoutTime to '0' )in AD via LDAP.
The only way to force a lockout of AD account when the account is locked in eDirectory is to force a lockout of the AD account by send X bad passwords depending on the requirements enforced by the AD password policy via IDM subscriber channel policies. This solution makes a few assumptions like below based on a default setup.
DirXML-ADContext is available for each associated user
AD allows ldap access via port 389
The IDM server should be able to resolve the DNS name of the DC as specified in the authentication context of the driver configuration.
The ECMA script assumes the novell java ldap libraries (ldap.jar) is present in the <edir-install-loc>/lib/dirxml/classes folder and eDirectory is already restarted after copying the ldap.jar.
The policies depend upon the ecma script that actually has the function that performs the bind to AD. The function takes 3 parameters namely userContext,adAuthContext and retryCount.
userContext: This the actual DN of the user in AD domain where the account needs to be locked. The default driver stores the AD context of the user in DirXML-ADContext attribute in eDirectory. The code expects this data is populated in eDirectory.
Note: In cases where the population of this attribute is customized to support more that one domain, the code needs to be modified to retrieve the correct value of the user's AD domain context in which the account needs to be locked
adAuthContext: This value is determined as explained above. The policies extracts the DNS name of the active directory DC from the authentication context specified in the driver configuration. If authentication context is left blank when the driver is either running locally or in the remote loader on the DC, then the IP/DNS name of the remote loader configuration is selected or defaulted to “localhost”.
retryCount: This is the number of times AD bind would be made with a random password by the driver for the user who needs to be locked in AD. This value is derived from the AD password policy that is configured.
Create a new policy in the subscriber command policy set. Paste the attached XML code to the new policy.
Adjust the value of the retryCount in the policy.
Add the attached ECMA script to the driver.
Ensure the lockedByIntruder is set to notify on the subscriber channel.
If using Designer to make the above changes, then save the project and deploy the changes. Restart the driver. Download accountlockout.zip