Windows Server 2003 ADAM to Windows Server 2008 AD LDS replication fails when using NTLM (negotiate)
AD LDS can use “negotiated” as the replication security level within a configuration set
(http://technet.microsoft.com/en-us/library/cc770465(WS.10).aspx). This may happen on AD LDS
servers that are domain-joined if there is a problem with Kerberos (e.g. a service principal
name issue) but will also happen for ADAM or AD LDS instances that are only members of a workgroup.
There is a known issue with mixed configuration sets, that is configuration sets containing
both Windows Server 2003 ADAM instances and Windows Server 2008 AD LDS instances, on attempting
to form a configuration set when the replication security level is Negotiate replication may
fail to complete.
The signature of the problem is seen when using repadmin to try and force a replication
of a naming context hosted on the (originating) Windows Server 2003 ADAM instance so e.g.
for a naming context “dc=mycompany,dc=com”
repadmin /syncall w2k3server.mycompany.com:389 “dc=mycompany,dc=com”
results in the following errors
From: W2k3server.mycompany.com:389
To : W2K8Server.mycompany.com:389
Error issuing replication: –2146893008 (0x80090330):
The specified data could not be decrypted.
If the servers are domain-joined then diagnosing the reason that kerberos is not being
used for replication security is the thing to do and will circumvent this issue. In pure
workgroup configurations there is currently no workaround for this problem.
Update 12 August 2010:
Microsoft have now released a fix for this problem:
(http://support.microsoft.com/kb/973678)
as ever test this in a non-production environment and note that in existing configurations sets of ADAM instances on Windows Server 2003 replication will fail between instances that are mixed (where some do and some do not have the patch applied).
11 Responses
Subscribe to comments with RSS.
Notes on IT (mainly Microsoft) 
Hi there,
I’m having the same problems replication ADAM to ADLDS. I’ve selected negotiated pass through as the replication authentication method, but I’m still getting the “Could not decrypt data.” error message.
I have to get the replication running in a workgroup, but I’m currently not able to make it work.
Do you have any ideas?
Thanks.
Jeroen
April 8, 2010 at 12:46
Unfortunately I think you are blocked in a workgroup because of this issue. As far as I know Microsoft have not decided whether to fix this or not, I’m hoping that gathering evidence here will help. However even a fix might not arrive in your project timescales, perhaps there are other approaches you could use rather than replication it depends on what you need to achieve?
adamsync
April 8, 2010 at 19:33
The goal is to use replication from ADAM to ADLDS as a migration path from Win2k3 to Win2k8 without performing an OS upgrade (which is considered very risky). As Microsoft does not provide a tool to migrate ADAM directly to ADLDS, the migration option looked like the only way out.
Maybe there is some way to convert an ADAM instance to ADLDS using a tool that I’m overlooking here?
Jeroen
April 8, 2010 at 22:26
The use of replication as migration path when in a workgroup is exactly what is blocked by this issue. The only “workaround” is to domain join the machines but that may not be an option. There is no supported way to pick up the database from an ADAM instance and present it to an AD LDS instance however perhaps you could consider the following:
take a backup [1] of your ADAM instance (hopefully you backup anyway).
Note to have a portable backup (for restore to another server) it’s usually a good idea to add the Windows Builtin Administrators group to the Administrators role in the ADAM instance if not already present (you can remove it again after taking the backup if required)
install a Win2k3 server on some machine (physical or virtual) and install ADAM and then restore your ADAM backup to that server
upgrade that Win2k3 server just created to Win2k8 and upgrade the ADAM instance to AD LDS [2] for testing
backup [3] that AD LDS instance and restore [4] to a clean install of Win2k8 running AD LDS in your production environment allowing you to leave your Win2k3 ADAM instance untouched
[1] http://technet.microsoft.com/en-us/library/cc737702(WS.10).aspx
[2] http://technet.microsoft.com/en-us/library/cc732566(WS.10).aspx
[3] http://technet.microsoft.com/en-us/library/cc816727(WS.10).aspx
[4] http://technet.microsoft.com/en-us/library/cc770886(WS.10).aspx
adamsync
April 9, 2010 at 14:05
Thank you very much for the response. I’ll suggest this as a possibility for the migration. It’s a rather lengthy operation though 🙂
Thanks
Jeroen
April 10, 2010 at 13:53
I’m also having the same problem, do you know if MS make a decision on this matter?
Thanks.
gap516
June 14, 2010 at 21:34
The best information that I have is that a hotfix is now expected in August (updated in the post above).
adamsync
July 1, 2010 at 10:25
Has anyone tried it yet with the patch installed? I’ve set it up here in the lab, but I’m getting the same results i.e. Data could not be decrypted.
Jeroen
August 18, 2010 at 10:13
Ok everyone, replication is working here. It seems that there was a registry key missing in order to get it going.
Just add Reg Value = “HKLM\System\CurrentControlSet\Services\\Parameters\NTLMSessionKey”
Type = DWORD
Value = 0x1
Sit back, relax and watch the whole thing replicate.
Jeroen
August 19, 2010 at 16:22
I have not had a chance to try the patch yet. The registry path above does not look complete is there an element missing? Also how did you figure out that this key was required? Thanks.
adamsync
August 20, 2010 at 17:31
The space between the two dashes has to be filled up with the name of your ADAM instance.
I’ve had contact with Microsoft Support and they provided me with this registry key.
Jeroen
August 25, 2010 at 17:57