TMG 2010 and Exchange 2010 Resource Forest: OWA Login Issues (Account is Disabled??)

I recently wrapped up a large TMG deployment in support of a new Exchange 2010 resource forest and there were a lot of lessons learned (read: issues that needed to be overcome), so I figured I would try to capture the main ones for the blogosphere.

Part 2 of 3 – OWA Login Issues (Account is Disabled??)

This article assumes a fairly decent knowledge of both TMG and Exchange. It is not meant to be a detailed step-by-step configuration guide.  All steps should be tested prior to production rollout.

This particular issue started happening when I enabled the ability for users to change their passwords from the TMG login page.  Immediately after that, when logging on to OWA with an account from the account forest (which is the account connected to the Exchange 2010 Linked Mailbox), TMG says the account is disabled (and it’s not).  One of the key items here is that the sAMAccountName is the same on both accounts.

I found a KB article about the exact same issue but for ISA.  The issue is in the additional things TMG does behind the scenes during login to determine password age and expiration.  It stops on the first account it finds, which is the one in TMG’s local domain, which is in fact disabled as it is in the resource forest, so you are denied.  To verify, we turned off the password stuff in TMG and it began to work properly again.  The fix for the ISA issue was to apply a hotfix, then run a script to enable the new functionality.  Since TMG uses the same code base as ISA, I made the assumption that the hotfix code was already part of TMG and all we would need to do is run the script.  The assumption turned out to be correct, just run the script in the KB article below on your TMG servers.  I think you only need to run it on one server in each array (didn’t make a note of that), but it won’t hurt to run it again on each node.

Associated ISA KB: http://support.microsoft.com/kb/952675

 

Part 1 of 3: TMG 2010 and Exchange 2010 Resource Forest: Redirection to Legacy Exchange 2003

FIM 2010 UnicodePwd Issue on New AD User Creation

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.

KB250455: How to change display names of Active Directory users

Nothing earth shattering here, just something I can never seem to find quickly when I need it.

When a new user is created in Active Directory, the Full name field is always generated in FirstName LastName format. In turn, this field sets the Display Name field on creation, therefore, you end up with a FirstName LastName formatted global address list.

You can make this change by using the Adsiedit utility. Adsiedit not only changes the default way the Display Name field is built, but also the Full Name (that is, the "cn") field, therefore, users appear in the chosen format when you look in the Users and Computers snap-in.

http://support.microsoft.com/kb/250455

Exchange 2000/2003 RUS not updating certain objects?

This is a great article for troubleshooting issues in which the Exchange 2000 or 2003 Recipient Update Service is not stamping particular object or objects in particular OUs:

http://support.microsoft.com/kb/254030

Active Directory Topology Diagrammer

With the Active Directory Topology Diagrammer tool, you can read your Active Directory structure through Microsoft ActiveX Data Objects (ADO). The Active Directory Topology Diagrammer tool automates Microft Office Visio to draw a diagram of the Active Directory Domain topology, your Active Directory Site topology, your OU structure or your current Exchange 200X Server Organization. With the Active Directory Topology Diagrammer tool, you can also draw partial Information from your Active Directory, like only one Domain or one site. The objects are linked together, and arranged in a reasonable layout that you can later interactively work withthe objects in Microsoft Office Visio.

http://www.microsoft.com/downloads/details.aspx?familyid=cb42fc06-50c7-47ed-a65c-862661742764&displaylang=en&tm

AD Explorer v1.0

A nice Microsoft/Sysinternals provided AD utility to have handy. From Microsoft:

Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. You can use AD Explorer to easily navigate an AD database, define favorite locations, view object properties and attributes without having to open dialog boxes, edit permissions, view an object's schema, and execute sophisticated searches that you can save and re-execute.

AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons. When you load a saved snapshot, you can navigate and explorer it as you would a live database. If you have two snapshots of an AD database you can use AD Explorer's comparison functionality to see what objects, attributes and security permissions changed between them.

AD Explorer works on Windows 2000 and higher.

http://www.microsoft.com/technet/sysinternals/utilities/adexplorer.mspx