Hitachi ID Identity and Access Management Suite includes two connectors for Active Directory targets. One works at the domain level and one is a forest-level connector. The connectors are full featured, supporting operations relating to passwords (test value, reset, check/clear lockout, set expiry date), to accounts (enumerate, create, set attributes, move, rename, enable, disable, delete) and to groups (enumerate membership, attach/remove account, attach/remove group-as-member, read/write attributes, create, delete).
The scope of integration -- i.e., which accounts and groups are in scope, can be controlled by group membership or by listing containers (OUs). A text file listing OUs can limit which accounts are visible in Hitachi ID Identity and Access Management Suite via this integration.
The forest-level connector is mainly used where many domains are in scope and/or where group memberships must be managed across domains. For example, where a user in domain A must be placed into a group in domain B, where both A and B belong to the same forest. The domain-level connector is used where management scope is limited to a single domain.
A DLL and service can be deployed on AD DCs to trigger password synchronization. Where these are deployed, password changes in AD continue to be subjected to native password strength rules. After a password is deemed to pass by the OS, the OS hands the password to the DLL. The DLL calls the service, which in turn contacts a Hitachi ID Password Manager server to apply further password policy rules. Passwords that pass these rules are committed locally to AD and then sent back to Password Manager to be synchronized on any other systems or applications where the same user has accounts.
Password Manager can apply rules to determine what DCs (plural) to contact when resetting passwords and -- more importantly -- clearing intruder lockout flags. These rules may be based on the user's current location, mail server or home directory UNC. By clearing lockouts on DCs near services the user is likely to access, any delays between a password reset and before the user is able to use his account again can be minimized.
Updating cached credentials after password changes
After a password change with a web-based password management system, the cached credentials on a user's PC will be different than the user's new domain password:
- When a user signs into Windows, Windows stores his domain
login ID and password in a cache in memory and in the registry.
- When the user signs into other Windows resources (e.g., shares,
printers, Outlook/Exchange mail boxes, IIS web sites), Windows
will normally try to offer a Kerberos ticket. If this fails,
Windows will offer its cached domain password and, if this fails,
Windows prompts the user to type the correct password.
- If the user changes his domain password from the PC with
the Ctrl-Alt-Delete process, Windows updates both the domain password
and the locally cached password -- there is no problem.
- If the help desk, another PC or a web application
changes the user's password on the domain, then the cached password
on the user's PC will be wrong. Subsequent attempts by the user to
access network resources may cause the OS to repeatedly provide the
(wrong) cached password and can trigger an intruder lockout.
- Intruder lockouts feed back to the help desk as increased call volume.
If a user signs off and back-on after a web-based password change, the Windows cache is refreshed and the intruder lockout problem described above is averted. This approach is not very user friendly.
To eliminate this problem without forcing users to sign off and back on, Password Manager includes an ActiveX component that can silently update the user's Windows password cache after a web-based password change.
The same mechanism can notify other components on the user's PC of the new password, notably full disk encryption packages (McAfee, Symantec, etc.) which often use a password that is synchronized with AD. This can, with most full disk encryption products, eliminate the delay after a password change, before the new password is available to login to the FDE software locally, pre-boot.
The cache-updating ActiveX component works on all Windows PCs.
Clearing intruder lockouts - quickly
Active Directory does not propagate cleared intruder lockout flags on an expedited schedule. This can create problems for remote users who inadvertently trigger a lockout and subsequently call a central help desk for assistance. The help desk will typically clear the user's lockout on a domain controller near the help desk. This lockout may take hours to reach the domain controllers against which the user wishes to authenticate or which support network services that the user wishes to access.
This problem is especially acute in global organizations, with hundreds of domain controllers that employ a global IT support function.
Note that AD password change replication is described here:
Password Manager uniquely circumvents the problem of slow replication of cleared intruder lockouts between Active Directory domain controllers by automatically directing password resets and cleared intruder lockouts to a select set of domain controllers, which the user is most likely to access:
- DCs on the user's home site, based on the user's home directory UNC and the IP address of the server that hosts this UNC.
- DCs on the user's current site, based on the user's web browser IP address (this only applies to self-service password reset).
- DCs mapped to either of these sites by an administrator-configured rule set. For example, at global or regional data centers.