Troubleshooting Password Synchronization
Novell Cool Solutions: Feature
By Raymon Epping
Digg This -
Posted: 13 Jan 2003
A few weeks ago I had some password synchronization services problems ... after some digging, I've uncovered a solution. I wanted to share my problem (and the solution) so you can avoid having to deal with same issue.
The products that I was running:
- Password Sync (latest version including service pack)
- eDirectory 8.6.2 (latest version including service pack)
- DirXML 1.1
- Client 4.83 (including all available service packs)
- eDirectory 8.6.2 and the DirXML engine were running on a Sun Solaris 8 batch 13 server
- DirXML remote loader was running on Windows NT4 PDC SP6
My problem was the following:
DirXML was correctly synchronizing all attributes from the NT domain to eDirectory and vice versa. Except for the passwords. Passwords were only sent from NT to eDirectory, not the other way! It seemed that no password information was being sent from eDirectory to the NT domain.
To investigate, I sent some e-mails to the newsgroups, NTS and development. The developer was so kind to send me two debug files. (DBGVIEW_1.EXE, pwdnotify.dll). Available here http://www.novell.com/coolsolutions/tools/1452.html
pwdnotfy.dll -- this is a file that is included with the client -- copy this file to a machine where you are trying to change the NDS password (it belongs in the system32 directory ... just rename the current file).
dbgview.exe -- captures debug output. Copy this utility to the same machine where the debug pwdnotfy.dll was copied. Run dbgview.exe and then try to change the NDS password from this machine ... you should see some information captured in the dbgview window.
The solution is:
We had an error message on the server that was saying: "The Cryptographic Service Provider has defaulted to Microsoft Base Cryptographic Provider v1.0. Encryption will be downgraded to the standards of this provider. Execution of the password synchronization server will not be affected. If higher encryption standards are required, please contact your network administrator."
The reason things were not working was an encryption-level incompatibility. Specifically, the workstation where the NDS password was being changed (a Windows 2000 workstation) had 128-bit encryption installed and the machine where the password sync service was running had 56-bit encryption installed.
Be aware that the client machines can have either high or low encryption, because the high encryption provider can decrypt messages encrypted by the low encryption provider.
We easily fixed this "issue" by installing high encryption with the latest service pack for Windows NT4.
Some additional information:
- eDirectory is not required on the NT/Windows server, the DirXML Remote Loader can be used.
- Passwords can be changed with ConsoleOne ... but only when running it on Win9x or NT/2000 with the Novell Client installed. In this case, the password change comes through the client libraries and we were able to "capture" it with the pwdnotfy.dll. If the password is changed through ConsoleOne running on any other platform (NetWare, Solaris, etc.) it will not get synchronized.
- Make sure that you add the relevant Password Synchronization attributes to both the Publisher and Subscriber filters. These attributes are: GUID, Public Key & Private Key. These attributes are also needed in case of a NDS to NDS Password Synchronization.
- Please make sure that if you have previously installed NDS for NT (Account Management 2.1) that it is completely uninstalled before you install Password Synchronization services. This is because of the modified SAMSRV.DLL. There are several TID's on how to uninstall NDS4NT.
Basically it comes back to:
- The Authentication ID for the driver doesn't have rights to the registry (where the SAM database is stored),
- The eDirectory user that the driver is set Security Equal To doesn't have sufficient rights to eDirectory, and
- The eDirectory server where the DirXML engine is installed does not hold all of the necessary replicas (this may cause some users to get associations but not others).
Also, have you tried setting the DirXML-DriverTraceLevel (this is on the driver set ... set the value to 3) and looking at the DS Trace screen - this may give you some indications of the failures. Here's the process:
- Rename C:\WINNT\SYSTEM32\SAMSRV.DLL to be C:\WINNT\SYSTEM32\SAMSRV.OLD
- Rename C:\WINNT\SYSTEM32\MSSAMSRV.DLL to be C:\WINNT\SYSTEM32\SAMSRV.DLL
NDS for NT 2.0 now includes the Novell Service Pack Sentry service (see TID-2945831, section 2 for further information) that impacts the renaming of SAMSRV.DLL.
- Rename C:\WINNT\SYSTEM32\SPSENTRY.EXE to be C:\WINNT\SYSTEM32\SPSENTRY.OLD
- Change to the SYSTEM32\NETWARE directory and del *.DLL (Note: there may be some DLL's in use that may not be deletable, which is fine. This shouldn't hinder the process)
- Reboot the NT server (the NT server will now be using Microsoft's SAMSRV.DLL due to the rename in step 2 above)
- Login to the NT server and run REGEDIT32
- Go to HKEY_LOCAL_MACHINE\Security\
Select security permissions from the menu - Select administrators - Give administrators full control - Replace permission on existing subkeys (check box). Click OK. Click Yes.
- Expand security key - NT Migration key and Nwsam key - Delete both keys
- Go back to security key and change it back to special access - (write dac and read control) Check replace permission on subkeys.
- Remove the Novell Client from the NT server
- NDS4NT is now uninstalled.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com