cd-error on ADMA export
Hello everybody!
I`m trying to provision users to AD. But when I run the "Export" rutine I get cd-error.
The users get created in AD, but the are all disabled.
My solution is like this:
FIM server in one domain. (Win2008R2) Domain functional level: Win2003 Forest functional level: Win2003
And AD server in another domain. (Win2003) With no trust. Domain functional level: Win2003, Forest functional level: Win2000
cd-error
Stack trace:
Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.
I`ve tried:
1. Changing the dSHeuristic on the target AD to value: 00000000010000001
2. Turning off Password complexity, and matched both domains regarding password policy.
3. Checked that the clock on both servers matching.
4. Tried setting a password with the same complexity and lenght manually in AD. This works.
September 29th, 2010 2:03pm
If the AD MA Export results disabled users you were definitly not able to set a appropaite password.
How do you compute your initial passwords? Do have a chance to preview / log the computed password?
What kind of security events are logged on your target DC?
Is there a firewall in between both ADs?
The computed password must meet complexity rules as defined in your target domain, you don't have to care about the complexity rules in the AD that contains the FIM server.
If you check complexity requirements take care of the following:
password length minimum password age complexity rules (three-of-four rule: upper case characters, lower case characters, numbers, special characters)
The password does not have to contain three or more characters from the user's account name
Free Windows Admin Tool Kit Click here and download it now
September 29th, 2010 3:54pm
If the AD MA Export results disabled users you were definitly not able to set a appropaite password.
How do you compute your initial passwords? Do have a chance to preview / log the computed password?
- Yes. I have a solution where I can see the password that FIM is trying to set. When I try to set the password on a AD user manually, it works.
What kind of security events are logged on your target DC?
- Nothing but success.
Is there a firewall in between both ADs?
- Yes, there are. And the following ports are open both ways: 53/88/464/389
The computed password must meet complexity rules as defined in your target domain, you don't have to care about the complexity rules in the AD that contains the FIM server.
If you check complexity requirements take care of the following:
password length minimum password age complexity rules (three-of-four rule: upper case characters, lower case characters, numbers, special characters)
The password does not have to contain three or more characters from the user's account name
- The password policy is correct. By setting the same password manually in AD I verified that.
September 30th, 2010 2:52pm
Have you tried to set the password manually from the FIM server?
Start ldp.exe on the FIM server Connect and bind to the target AD using the credentials the target AD MA uses
Select the domain naming context in question via the menu View | Tree Navigate to a disabled User Right-click the user object and select Modify Attribute: unicodepwd Value: \UNI:"newPassword"
Free Windows Admin Tool Kit Click here and download it now
September 30th, 2010 3:40pm
Tried this now. And was able to set the password using ldp.exe like you described.. hmm
September 30th, 2010 3:56pm
Have you enabled LDAP Signing / Encryption or SSL on the AD MA?
Free Windows Admin Tool Kit Click here and download it now
September 30th, 2010 4:42pm
There we go!
No. Thanks alot! :) :)
September 30th, 2010 5:02pm
?? So, what was going wrong ??
Free Windows Admin Tool Kit Click here and download it now
September 30th, 2010 5:06pm
Just like you said. First I tried setting a user password with ldp.exe with and without encryptet LDAP traffic. When I tried doing this with unencrypted traffic, I got an error. But it worked when the traffic was encrypted. So I activated "Sign and
Encrypt LDAP Traffic" on the AD MA. And that fixed the problem :)
October 1st, 2010 10:52am
same problem, but in MA AD I have selected "Sign and Encrypt LDAP Traffic"
in Sync rule I configure rule:
Modification type: update
Object type: user
Changes: modify
Attribute Name: userAccountControl
Old Value: 546
New Value: 512
I get CD-ERROR error:
Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.
When I manual enable user and change his password - sync complete successfully.
Any solution this problem...
November 30th, 2010 9:26am
I had this same problem, even with 'sign & encrypt' set
When I set up the AD MA, I specified the IP of a DC in the forest and domain fields.
After I changed to the actual forest and domain name, it started working. Since the domain wasn't in DNS, I had to add host file entries (or you could add a conditional forwarder in DNS if that's allowed)
Free Windows Admin Tool Kit Click here and download it now
December 10th, 2010 12:45am
This is probably due to Kerberos not being used as the IP was specified.http://setspn.blogspot.com
December 10th, 2010 4:04am
Thomas,
Interesting variation here.. I have two labs, with the same configs (exported configs) so they should work the same.
One of them was fixed by changing the ip to the real forest/domain name. The second one is still exhibiting the same problem - name or ip
Looks like i'll be turning up kerberos logging and breaking out the sniffer to see whats happening on the wire.
I'll let you know what I find.
Free Windows Admin Tool Kit Click here and download it now
December 10th, 2010 9:53pm
ok, It turned out the server that was working was pointing to a DNS server that had records from the destination domain. Without those, there is not way from FIM to set passwords for accounts in that destination AD. You can add hosts file entries, but you
can't add the SRV records required for Kerberos to work...
So, without access to the remote domain's DNS server records, it won't work. Unless you know of another way to get that info.
December 11th, 2010 8:19pm
ok, It turned out the server that was working was pointing to a DNS server that had records from the destination domain. Without those, there is not way from FIM to set passwords for accounts in that destination AD. You can add hosts file entries, but you
can't add the SRV records required for Kerberos to work...
So, without access to the remote domain's DNS server records, it won't work. Unless you know of another way to get that info.
Free Windows Admin Tool Kit Click here and download it now
December 11th, 2010 8:19pm