Previously in this appendix, it was stated that the term Windows referred to Windows platforms using Active Directory for authentication. However, the system being discussed in this appendix can use Windows NT in place of (or along with) newer variations of Windows.
Be aware however, Windows NT lacks the ability to use on-demand synchronization normally provided by Identity Synchronization for Windows.
The Identity Synchronization for Windows’ on-demand synchronization process must be able to bind to Windows over LDAP, with a set of candidate credentials — an ability that the Windows NT authentication system lacks. When Identity Synchronization for Windows environments are configured with Windows NT they expect password changes to be captured at their source and at the time the change is made. This capture requirement has ramifications when you initially bring up an Identity Synchronization for Windows environment. Specifically, the Identity Synchronization for Windows system needs to see a password change for any entry before the entry is actually synchronized.
Synchronization in an NT environment is similar to the proceeding steps described in Case 3, where you can modify the passwords of all entries in the LDAP store using an LDAP-based utility. As these modifications go through the LDAP store system, Identity Synchronization for Windows forwards the captured passwords to the Windows NT system, and then neither of the two systems would contain stale passwords. However, because you created the passwords by deterministic means, it may be easy to guess these passwords.
With this technique, you can limit potential damage if you use Windows NT’s password policy administration to force all users to change their password at their next logon. As each user changes their password, the Identity Synchronization for Windows password DLL installed on the Primary Domain Controller will forward the password change to the LDAP store.