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.
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.
If using Designer to make the above changes, then save the project and deploy the changes. Restart the driver.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.