Password Synchronization - NMAS, UP, and AD
Novell Cool Solutions: Feature
Digg This -
Posted: 17 Aug 2005
A reader asked about tips and best practices for AD passwords and NMAS. Here are the highlights:
"We have an environment with eDirectory 8.7.3 syncing to AD via IDM 2.0.1. Workstations in the AD Domain have Novell Client4.91a and NMAS.
When changing a password in eDirectory and AD, the eDirectory password (universal) changes successfully, but the AD password change fails - "old password is not valid ..." I suspect that the eDirectory password change is syncing thru DirXML too quickly for the domain controller to keep up.
As a fix/workaround, I have disabled Windows password synchronization on the Advanced Login tab of the Novell Client. This, of course, doesn't change the Windows password, so there's no error when the user is prompted to change password. The AD password then syncs in from eDirectory, so everyone is happy.
Which leads me to my question - In this scenario, if all domain servers and workstations have the Novell Client configured as above, I'm guessing that although I need to configure password polices in dirXML, I should not need to install password filters on every Domain Controller, as there are no AD passwords to capture. Any thoughts?"
And here's the reply from Forum participant Martyn Durrant ...
It rather depends on whether your organization has a consistent method of user password update across the board. If you have a mixed environment (for example, some people changing via a browser based password manager, others using the Novell Client, others using an MS client, others changing via a foreign application) then you will probably need to have bi-directional IDM password synchronisation. But if your user base is not mixed, then you can probably get away with having uni-directional IDM password synchronisation, or maybe even nil-directional synchronisation.
Here are three possible choices:
1) If you are sure that 100% of your users have the Novell Client, and their clients are all configured to update BOTH the eDirectory password AND the Active Directory password during a password change, then you could elect to completely turn off password synchronisation via IDM2. In practice, this is usually a poor choice because Administrative resets will never make their way across the directories.
2) As you know, if you are sure that 100% of your users have the Novell Client, and all clients are configured to update ONLY the eDirectory password during a password change, AND you can be confident that no Administrator will wish to do password resets in Active Directory, then you could eliminate the need for a password filter on the domain controllers. If that software is never going to alter an AD password in any Domain Controller, then there seems little point in harvesting password changes via the agent and filters.
3) You might not be sure of 100% uniformity of the client password update method, and the eDirectory and the AD passwords must be synchronized. This will often be the case where the eDirectory is an Identity Vault being used to push passwords out to other applications as well as AD). Provided your throughput of events through the AD Connector is relatively low, you can probably afford to put a sleep of say 1.5 seconds in the Subscriber Command Policy for events where the Distribution Password is being modified. This should give enough time for the Novell Client to update the Active Directory password directly. For performance reasons, the sleep action should not be used for any "from merge=true" events.
Here is one way you could approach implementation:
- Use bi-directional password sync between eDirectory and AD.
- Use password filters on all domain controllers.
- Disable NMAS on Domain integrated workstations/servers so that when a password is changed,
- Enable NMAS on non-Domain Workstations (and possibly ZEN DLU as well).
- Make sure administrative password changes sync both ways. For this you need to use iManager or ConsoleOne running on an NMAS-enabled workstation so that NDS-AD password synchronization will work. This should also allow for domain integrated workstations/servers without the Novell Client.
A. AD password is changed natively.
B. Only the NDS password is changed in eDirectory - not the Universal Password (avoiding the sync back to AD)
C. The AD password syncs to the eDirectory Universal password (resetting the NDS password to the same value).
Note: Make sure that your IDM and AD Driver AND NMAS on all servers are fully up to date. There was a problem discovered in 2004, where synchronization of the AD password to the eDir Universal Password caused the user's password expiry date to be set to today. So the very next time the user logged in, the Novell Client advised that the brand new password had expired.
This is all fixed if you have the latest versions and SPs of the components. You might also want to ensure that your AD Connector Publisher Channel does NOT update the NDS password directly. It should just update the Distribution Password and leave NMAS to do the proliferation of the NDS password.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com