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?

 

  • Marked as answer by Remi Vandemir Thursday, September 30, 2010 2:03 PM
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

great :-)
Free Windows Admin Tool Kit Click here and download it now
October 1st, 2010 12:00pm

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 5:22pm

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 8:42am

This is probably due to Kerberos not being used as the IP was specified.
December 10th, 2010 12:00pm

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 11th, 2010 5:50am

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 12th, 2010 4:15am

Hi Frank

that is interesting as a config.

I have built a new HA Service FIM 2010 R2 Sp1 server as a rebuild of an old setup that was creaking.

In the new setup I have myDomain.com and contractors.mydomain.com. The server is built in contractors.myDomain.com , but all my service accounts including the adma are in myDomain.com , I have set the correct permissions such as the replicating directory changes, and adma has full access to the containers in contractors.myDomain.com that are needed to create accounts etc.

When a new account gets in from the ADMA, all attributes (a lot) are set correctly, the user is created, but I get the problem where the password cannot be set. Same error as above, I would be interested in knowing if the problem is similar to your setup ? I can set the password and enable the account in AD tools or PowerShell, and it gets synced correctly. But this is a strange one as the previous build had no problem doing that. However in the old build all the servers and the accounts were in contractors.myDomain.com. Nothing in the root domain.

Rob

Free Windows Admin Tool Kit Click here and download it now
January 13th, 2014 9:11am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics