Tuesday, November 22, 2011

MCTS: Microsoft Forefront Identity Manager 2010, Configuring

Just received an email that I passed the beta version of the FIM 2010 Exam (71-158) I took in early August.

Some of the questions needed work, so I am curious how the updated exam looks.  Not sure if I am curious enough to take it again though…

Details on the exam can be found here.

TMG 2010 and Exchange 2010 Resource Forest: Redirection to Legacy Exchange 2003

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 1 of 3 – Redirection to Legacy Exchange 2003

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; it only serves to identify the key configuration elements for redirection. All steps should be tested prior to production rollout, usually by editing the hosts file to force traffic to the right IP for testing.

In our original publishing model, ISA or TMG is used to publish the Exchange 2003 FE.  Pretty straightforward.

Original Publishing Model
TMG Publishing1

Exchange 2010 in Same Forest as Exchange 2003

In the case of an upgrade/transition to Exchange 2010 (a deployment of Exchange 2010 in the same forest as the legacy Exchange 2003 environment), the Exchange 2010 CAS servers can be configured to hand out a legacy URL for OWA.  TMG/ISA is generally used to publish the new Exchange environment under the standard name, and to publish the legacy Exchange environment under the legacy URL.

The goal here has three components:

  1. Avoid modification of the existing, legacy Exchange environment
  2. Allow publishing/redirection of OWA for both Exchange 2010 and Exchange 2003 users
  3. Allow the publishing/redirection with a single sign on

New Publishing Model – Upgrade/Transition in Same Forest
TMG Publishing2

If you were using TMG originally, it is possible to achieve this by deploying a new TMG server/array, or by modifying the publishing rules on your existing deployment.

The steps:

  1. Install the new public certificate on TMG. The new certificate should have all of the DNS names required by your Exchange 2010 deployment: Autodiscover (autodiscover.company.com), Outlook Anywhere (outlook.company.com), and OWA (webmail.company.com).  It should also have the new legacy Exchange URL (legacy.company.com).
  2. Ensure the certificate on the Exchange 2010 CAS server has the appropriate public name.
  3. Configure the legacy Exchange URL on the Exchange 2010 CAS (legacy.company.com)
  4. Create a single Web listener using that certificate, with SSO enable for your domain (.company.com in this example).
  5. Create and test the appropriate Exchange 2010 publishing rules, using the above listener:
    • OWA (for the public name webmail.company.com)
    • OA (for the public name outlook.company.com)
    • Autodiscover (for the public name autodiscover.company.com)
  6. Create and test a new Exchange 2003 publishing rule, using the same listener as the Exchange 2010 publishing rules.
    • Public name must be legacy.company.com, but the old name (webmail.company.com) must be sent to the Exchange 2003 server because it was not configured for the legacy.company.com name.  To do this enter the name that Exchanger 2003 is configured for (webmail.company.com) on the “To” tab of the rule, and uncheck the box for “Forward the original host header instead of the actual one (specified in the Internal site name field)”.  I also recommend using the IP address of the Exchange 2003 server to avoid DNS issues with the name.

  7. Create DNS entries for all new public names to the IP of TMG
  8. Update existing DNS entries (webmail.company.com) to the IP of TMG

For an Exchange upgrade/transition in the same forest, this should meet the required goals.  No changes have been made to the Exchange 2003 environment.  All publishing rules use the same listener, so single sign on should be working.  All users are initially sent to the Exchange 2010 CAS, but if their mailbox is on Exchange 2003, the Exchange 2010 CAS redirects the user to legacy.company.com, which TMG is now configured to publish to Exchange 2003.  The only change to the user experience is that Exchange 2003 users will notice their browser change to legacy.company.com, even though they browsed to webmail.company.com.

Exchange 2010 in a Resource Forest

However, there is a SMALL catch for a resource forest – Exchange 2010 redirection to Exchange 2003 doesn’t work.  Also, it is important to remember that in a resource forest, user are logging in to their mailboxes with their AD accounts in the account forest, and the AD accounts in the resource forest are disabled.

In general, the TMG architecture is the same, and with a few minor technical modifications and one migration process modification the same goals can be achieved.  An added bonus is that the Exchange 2003 does not have the address changed to legacy.company.com in this model, so in the case that the change in address is unacceptable to the business, these same changes can be applied to a normal upgrade/transition as well.

New Publishing Model – Resource Forest

TMG Publishing3

Since Exchange 2010 can’t determine where the user’s mailbox is, we need to configure TMG to handle it.

The TMG configuration detailed in the previous section should be modified as follows:

  1. Create an AD group that contains the Exchange 2010 migrated users.
    • Can be in either in forest, but the accounts in the group must be from the account domain
  2. Ensure the Exchange 2010 publishing rules are above the Exchange 2003 rule.
  3. Create a User Set in TMG that contains the newly created group.
  4. Modify the Exchange 2010 publishing rules to only allow the newly created set (on the “Users” tab).
  5. Modify the Exchange 2003 publishing rule to allow the traditional public name (webmail.company.com).

With these changes, TMG will only send members of the AD group to Exchange 2010, and all users not in the group will be sent to Exchange 2003.  The process change is that you must update the membership of the group as users move to Exchange 2010.

The group is only temporary and is no longer needed once the transition is completed.  In that case, remove the Exchange 2003 publishing rule and change the Exchange 2010 rule back to “Authenticated Users”.  You can then delete the User Set in TMG and the group in AD.

Thursday, September 01, 2011

FIM 2010 R2 Beta: Changing the Web Based Password Reset Page After Install

First post on FIM 2010 R2 Beta…

FIM 2010 R2 provides a new based password reset option.  For more info on the feature, check out Anthony Ho’s post.

When you install the new Web Based Password Registration and Reset applications (web sites), you are asked if the site is an extranet site or not.  Specifying it as extranet tells FIM to present the additional QA Gate for added security.  However it isn’t readily apparent how to change it after install.  You can uninstall it and re-install it, but the reinstall forces you to go through the entire install for the FIM Service, Portal, etc.  Turns out there is an easier way.

Simply edit the web.config file for the application, which (by default) you can find at:

C:\Program Files\Microsoft Forefront Identity Manager\2010\Password Registration Portal


C:\Program Files\Microsoft Forefront Identity Manager\2010\Password Reset Portal

Edit the web.config file by changing this line:

<add key="SecurityContextAssertion" value="Extranet" />

Valid values are “Extranet” or “NoneSpecified”.

I had no problems editing this line and getting the change to take effect for the Reset page, but with the registration page, I continually got the Extranet QA Gate to answer.  I suspect that’s by design as I need to answer the questions for both QA Gates so that I am ready to reset from either option.

Tuesday, August 30, 2011

Certificate Autoenrollment Not Working on Windows 7

Why do I always seem to find the weird issues?

I was working with a client on a PKI deployment and ran into an issue of a Windows 7 workstation not autoenrolling properly.  The new Windows Server 2008 R2 PKI was fine, the client simply wouldn’t update.

I went to manually request the desired certificate, and found that the Root CA was not trusted, and therefore the client wouldn’t autoenroll.  Of course, the Root CA and the Issuing CA were properly registered in AD, so the client should’ve auto-downloaded the root certificates for them as part of the autoenrollment process.

I verified the client had autoenrollment enabled as described in this article: http://social.technet.microsoft.com/wiki/contents/articles/3048.aspx

I also removed the AEDirectoryCache registry entry as described here:  http://technet.microsoft.com/en-us/library/bb456981.aspx#ECAA (For XP, but the registry key removal is still valid for 7)

What I found then is that the AEDirectoryCache registry key was not be recreated when gpupdate /force is run.  There were no event log entries for autoenrollment at all (good or bad).  No Root CAs were downloaded, and I still didn’t get my certificate.

I ran certutil –pulse to force autoenrollment and got the following unusual message…

CertUtil: -pulse command FAILED: 0x80070002 (WIN32: 2)
CertUtil: The system cannot find the file specified.

That led me to this forum posting: http://social.technet.microsoft.com/Forums/en-SG/winserverDS/thread/5100f13d-f9e6-46fb-a394-76b7f9702c80

The symptoms described there were exactly what I had (though for Vista), so I looked into the resolutions posted.  I couldn’t do the first one, since there were no child tasks.  I’m on to something now…

I copied the entire c:\Windows\System32\Tasks\Microsoft\Windows directory from a good system to the problem system, then went back into Task Scheduler.  Still no child tasks.  I also noticed this time that that Task Scheduler gave me an error about failing to connect to the remote system.  Then it hit me, what if the Task Scheduler service was disabled?  Went to look and found out that the Task Scheduler service DID NOT EXIST!!

I exported the registry key for the service (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Schedule) from a good system and imported it to the problem system, rebooted and I now had a running Task Scheduler service again, complete with child tasks.  Also, my root certificates auto-downloaded, and I got my certificate!  Also, certutil –pulse works fine again, and the AEDirectoryCache key was re-created.

So I learned that, somehow, the certificate autoenrollment process in Vista and Windows 7 is connected to the Task Scheduler service.

Wednesday, August 17, 2011

Managing Malware Inspection Temporary Storage in TMG 2010

A very handy (and under-documented) feature of TMG 2010 is the ability to adjust some of the temporary storage settings for the Malware Inspection feature.  If you are experiencing slow downloads - particularly of larger files - in TMG with Malware Inspection on, you may want to adjust some these settings.  I won't go into details on each setting, but I wanted to share the link to the TechNet documentation.

Monday, July 18, 2011

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.

Wednesday, March 30, 2011

Office 2010 x64 and SharePoint Datasheet Views

It turns out that you cannot switch a SharePoint list to Datasheet View if you are running Office 2010 x64.  The required components are not part of the Office 2010 x64 install.  Various postings had you verify if Access was installed.  I didn't have it installed, added it, and still couldn't switch to Datasheet View.  To add the required components, simply install the 2007 Office System Driver: Data Connectivity Components.

IE9 RTM and Citrix ICA files

I ran various IE9 betas and RCs without issue when it came to opening and launching Citrix ICA files.  Once I installed the RTM version however, they failed to open.  The file would download, and then just sort of hang.  If I went to the site with Firefox, I had no issues.  Today I learned that to resolve this, you simply need to uninstall "Citrix online plug-in - web", and then reinstall the web client when prompted through your Citrix portal.  Much better now...