UPDATE 2010.08.17 – Ultimately, 2008 SP1 did not resolve the issue in this case. We ended up enabling Password Policy Enforcement in FIM 2010 SSPR. This change alters how FIM connects to AD to make password changes on new user creation, password sync, and password reset operations. Instead of Kerberos, it uses LDAPS to the domain controller. Together with a hotfix for the AD MA used, it now enforces the full AD password policy (including password history).
----
Now this was a an odd one. I am working on a pretty basic FIM deployment and got to the point of provisioning users into Active Directory. I set up all of my attribute flows in Outbound Sync Rules and set up my workflows and MPRs accordingly. At this point, I was flowing a static string value to unicodePwd – one that did meet the password requirements of the domain – and it was configured for “Initial Flow Only”. The user gets created in Active Directory, but I was getting a “Cd-Error” in FIM with no real detail, other than the fact that userAccountControl was not being updated to 512 (for an enabled, regular user). No errors in the event logs on the FIM Sync server or the target domain controller. Using the account used by my AD MA, I opened ADUC and tried to enable the user. No luck. I got the error message about the password not meeting the policy requirements. I could however manually set the password to the value I was flowing from FIM, and then I could enable the user. So that told me it wasn’t an AD rights issue, and that for some reason FIM wasn’t flowing the password to the new user at all.
After looking into all of the more common Kerberos issues (time sync, firewalls, DNS name resolution, etc.) I used Wireshark to capture the network traffic on the FIM Sync server during the export to AD. The capture showed that the KPASSWD command was failing with “KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN”.
The details of the error showed that the DC could not locate the SPN “kadmin/changepw”.
But, running “setspn –Q kadmin/changepw” returned the correct AD account, “krbtgt”, without issue. A little bit of searching led me to this KB article, which mentions an issue with “kadmin/changepw” when the “krbtgt” account was authoritatively restored in the past. Though I didn’t catch it right away, it even says that this would cause an issue with ILM setting passwords on newly provisioned accounts.
So, I ran “repadmin.exe /showobjmeta DC1 cn=krbtgt,cn=users,dc=domain,dc=com” and lo and behold, the “krbtgt” account had been authoritatively restored in 2008. A sample of the output is below. Note the highlighted attribute versions that have been increased by 100,000.
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
14299 aa8e4db6-7d0e-45ae-95e9-82db0e59a327 34567640 2008-08-19 03:02:35 100001 objectClass
14299 Default-First-Site-Name\DC1 14299 2010-12-04 18:12:51 1 cn
14299 aa8e4db6-7d0e-45ae-95e9-82db0e59a327 34567640 2008-08-19 03:02:35 100002 description
14299 aa8e4db6-7d0e-45ae-95e9-82db0e59a327 34567640 2008-08-19 03:02:35 100001 instanceType
14299 2f2a1f4c-eac1-404a-b305-37fd2e28eddf 1479 2002-03-13 20:27:04 1 whenCreated
So, the hotfix from the KB article was installed on the DCs, and the issue was resolved. The hotfix is included in Server 2008 R2 SP1, so definitely go that route if you can. New users provision with the proper password and are properly enabled on creation. Hopefully you don’t run into this issue, but if you do, I hope this eases your pain.
