We recommend that you use a secure connection when you are synchronizing passwords. Vulnerable connections are between the following:
The Metadirectory engine and the Remote Loader
The Remote Loader and Active Directory
This is true only when you run the Remote Loader remotely from the domain controller that you’re connecting to.
The Metadirectory engine and Active Directory when you aren’t using the Remote Loader
This is true only if the domain controller isn’t local to this machine.
You can create a secure connection by doing one or more of the following:
Configure SSL between the Metadirectory engine and the Remote Loader
Run the Remote Loader on the domain controller
Configure SSL between the driver shim and Active Directory
This doesn’t apply if you are running the driver on the domain controller that you’re connecting to.
For password synchronization to work when the driver shim isn’t running on the domain controller, you must have SSL configured.
If you see an error about a password not complying when a user is initially created, you need to check your password policies.
For example, perhaps you want the Active Directory driver to provide the initial password for a user when the Active Directory driver creates a User object in the Identity Vault. When a user is created, the driver shim creates the user and then sets the password.
Because adding the user and setting the password are done separately, the new user in this example receives the default password, even if only momentarily. The password is soon updated because the Active Directory driver sends it immediately after adding the user.
If the default password doesn’t comply with the eDirectory Password Policy for the user, an error is displayed. For example, if a default password that was created by using the user’s surname is too short to comply with the Password Policy, you might see a -216 error saying that the password is too short. However, the situation is soon rectified if the Active Directory driver then sends an initial password that does comply.
Regardless of the driver you are using, if you want a connected system that is creating User objects to provide the initial password, consider doing one of the following:
Change the policy on the Publisher channel that creates default passwords, so that default passwords conform to the Password policies (created by using the option in Password Management) that have been defined for your organization in the Identity Vault. When the initial password comes from the authoritative application, it replaces the default password.
This option is preferable. We recommend that a default password policy exist in order to maintain a high level of security within the system.
Remove the policy on the Publisher channel that creates default password. In the sample configuration, this policy is provided in the Command Transformation policy set. Adding a user without a password is allowed in eDirectory. The assumption for this option is that the password for the newly created User object eventually comes through the Publisher channel, so the user object exists without a password only for a short time.
These measures are especially important if the initial password does not come with the Add event, but comes in a subsequent event. A user is added to eDirectory in two stages. The object is created in the initial Add event and then the password is set for this user. In the Create rule in the Subscriber channel, there is a suggested rule to veto if the nspmDistributionPassword operational attribute is not available. This causes the initial Add event to end with a veto, and the subsequent Modify event ends with only modify-attr attr-name="nspmDistributionPassword" attribute, which turns the Modify event into a synthetic Add event. Because the initial Add event was vetoed, the password Modify event is converted into another Add event, but this time it can complete.