Lately I’ve been doing some publishing on ISA & TMG and here are some of the errors I came accross with a solution. I’m not saying they will also work for you as these error messages are perhaps generic, but for me they did. Some of them I stumbled upon trying to publish an AD FS 2.0 enabled web application, some of them when publishing an application using two factor authentication on ISA.

When an application is AD FS enabled, you no longer authenticate to the application server. In fact on the first visit you are redirected to your security token service server (AD FS). You authenticate against the STS, get a SAML token (claim) and present that to the application. One of the possibilities to publish this on ISA is to use two publishing rules with the same listener. Configure the listener for FBA (or something else) and configure a SSO domain. One rule publishes app.contoso.com, the other adfs.contoso.com. Visiting app.contoso.com will show you the FBA, you get to the application and are immediately redirected to adfs.contoso.com. Because of the ISA SSO on the listener you don’t have to authenticate a second time. Here are the errors I came across during this process. I believe they are specific to how the AD FS service expects it’s communication:

• Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter. Contact the server administrator. (12217)

For some reason ISA is complaining, I found a KB article with some explanation: KB837865: You receive a "The request was rejected by the HTTP Security filter" error message when you try to... and also a blog post: Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter. Contact the server administrator. (12217)

Bottom line: all you have to do is right click your rule, choose configure HTTP and deselect verify normalization

Another problem I came across during the AD FS publishing:

• ID6018: Digest verification failed for reference  ‘#_long_id’

This can be solved by unchecking “apply link translation to this rule” on the web publishing rule. It struck me as odd as there was no really translation configured (internal name was the same as external), but it' did seem to do the trick.

An error I come across now and then is “Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)”. One of the possible reasons is a Web Publishing Rule configured with Kerberos Constrained Delegation (KCD) and you forgot to trust to ISA computer object for delegation in Active Directory.

And last but not least a fun fact about 2 factor authentication on ISA 2006 SP1 and TMG: you can configure a listener for Form Based Authentication (FBA) and configure the advanced option “require client certificate”. However there is a subtle difference when you choose either LDAP or AD to connect your Active Directory environment:

• When configure as LDAP (or RADIUS, RADIUS OTP and SecurID) ISA will only verify if the presented client certificate is trusted by ISA. There is no need for a link between the user credentials and the certificate. So you can present a trusted certificate, and use any user to authenticate.
• When configured as Active Directory, ISA will try to find a mapping to a user for the presented certificate in Active Directory and afterwards verify if the credentials entered match the user found by mapping the certificate.

This can cause an issue when you want to hand out a certificate to a user, but allow him to log on use multiple accounts. If the user enters credentials other than those of the user the certificate is mapped to, or when ISA doesn't find a mapping in AD, you’ll get the following error: ERROR : 403: forbidden Authentication failed. The client certificate used to establish the SSL connection with the forefront TMG computer doesn’t match with the user credentials that you entered (12323 )

Now how can a user map to a certificate?

1. When you enable advanced options in ADUC, you can right-click a user and choose “name mappings”. Then you can upload a certificate.
2. When the certificate contains an UPN in the SAN part of the certificate. Of course the UPN needs to map to a user in AD.

Now how can we alter the ISA behavior? KB 953684  How to change the default behavior for client certificate mapping when you use forms-based authentication with Active Directory in ISA Server 2006 Service Pack 1 of course you have to decide for yourself whether this is desired or not.

I’m currently writing a guide on how to transition a FIM configuration from a lab to an acceptance environment. The great part is that MS already has some nice work on this and has the PowerShell scripts ready for download. The step by step guide (and scripts) can be found at Technet: FIM 2010: Configuration Migration Deployment Steps

One of the steps allows you to sync the exported config of the lab environment with that of the acceptance environment: syncpolicy.ps1

And then things went wrong (a copy paste):

PS C:\FIM\Migration Scripts> .\SyncPolicy.ps1
Loading production file  C:\FIM\Migration Scripts\ProductionPolicy.xml .
Loaded file  C:\FIM\Migration Scripts\ProductionPolicy.xml . 760  objects loaded.
Loading pilot file  C:\FIM\Migration Scripts\PilotPolicy.xml .
Loaded file  C:\FIM\Migration Scripts\PilotPolicy.xml . 801  objects loaded.

Executing join between pilot and production.

Join-FIMConfig : Two objects with the same AnchorAttributeValue were detected. A requirement for using this migration tool is that AnchorAttributeValue is unique with an Object Type.
AnchorAttributeNames = DisplayName
AnchorAttributeValues = Displayname
ObjectType = ManagementPolicyRule
ObjectID 1 = urn:uuid:1aaf99c7-e7d8-42c0-bc53-457fdd74f330
ObjectID 2 = urn:uuid:17dbb6a7-5271-4ea3-9ca3-58d1836b4575
…

What it basically was telling is that there were two objects with the same display name. The syncpolicy.ps1 script does not like this. Using the Object ID it’s quit easy to find out which ManagementPolicyRules (MPRs) are involved. One can use PowerShell to retrieve extra attributes given the ObjectID:

Set-Variable -Name URI -Value "http://fimsvc.corp.contoso.com:5725/resourcemanagementservice" -Option Constant
$dest = get-location

#Get information for a specific object
$ExportObject = Export-FIMConfig -uri $URI –customConfig "/*[ObjectID='acbcad3b-8394-4af3-a1d4-149cabae05d1']" -onlybaseresources -ErrorVariable Err -ErrorAction SilentlyContinue 
If($Err){Throw $Err}
If($ExportObject -eq $null) {throw "Object not found in your environment"}
$exportObject | ConvertFrom-FIMResource  -file $dest\object.xml

I am by no means a PowerShell guru so there are probably 10 ways to write the above code in a more decent/efficient way. But it gets the job done. A nice resource on FIM PowerShell stuff is the TechNet: FIM ScriptBox As an alternative to writing some code yourself there’s also the FIM Object Visualizer which has an option to get a HTML page of an object given it’s ObjectID. Quick and easy! The FIM Object Visualizer is also a great to tool to aid you in documenting your FIM solution. Just make sure you use the “c:\windows\system32\mshta.exe” when launching the HTA on Windows 2008 R2 (X64…), I like creating a shortcut to the HTA which has the mshta.exe path in front of it.

After doing the above research it seems there are two MPR’s with the same display name: “Users can create registration objects for themselves”. One which applies for create and one which applies for Create, Modify. 

After renaming one of those MPR’s, in both lab and acceptance, re-running the exportPolicy.ps1 scripts I re-ran the syncPolicy.ps1 script and everything worked out fine: 

While I was browsing the TechNet Forums: Two MPRs with the same name after FIM 2010 Update 1 today I noticed someone mentioning the same issue and workaround. As I already began writing this post a few days ago I decided to post it nevertheless. Anthony Ho mentioned there has been filed a bug request and that the FIM 2010 Update 1 release notes will be updated. Seems like one of the MPR’s should have replaced the other one. Renaming is a workaround, but not the ideal solution. We’ll get more info soon.

I've been playing around with the email templates in FIM 2010 and one of the cool things is that you can easily add information about the subject or requester of the request. To use these values you can use the following notation in the templates:

• [//Target/Attribute]
• [//Request/Attribute]
• [//Requestor/Attribute]
• … ?

Some examples:

Suppose you have a Synchronization Rule which is added to a User object using a workflow and MPR, then:

• [//Target/DisplayName] will give you the displayname of the user
• [//Target/Domain]\[//Target/AccountName] will give you the domain\accountname of the user
• [//Target/Email] will give you the email address of the user
• [//Requestor/DisplayName] will give you the displayname of the user of this request: in this case the Built-in Synchronization Account
• [//Request/DisplayName] will give you the displayname of the request

In my FIM deployment I use this to send email notification to certain persons. As an example I send an email to the exchange team when a user is "deprovisioned" by FIM so the mailbox deprovisioning process can be triggered. Of course there are many other possible scenario's to use this functionality.

A nice walk-through on how to create your own templates: blogs.msdn.com: Customizing email templates

There are several good resources on how to provision mailboxes for Exchange 2010 using FIM 2010. For starters the following attributes have to be set (export attribute flow) during the user creation phase:

• Mailnickname
• homeMDB
• msExchHomeServerName

Secondly the AD MA should be configured to "provision for Exchange 2010" and the RSP URI should be provided as well. The URL should looke like http(s)://casarray.yourdomain.tld/Powershell.

Following these steps FIM will create a mailbox-enabled account when provisioning accounts in Active Directory. An issue which I came upon is the options panel in Exchange 2010 Outlook Web Access (OWA). All my FIM provisioned users can successfully logon to OWA, but when clicking the options button they received the following error:

I verified the application event log of the Exchange CAS server around the time I did my tests and came upon the following error:

A copy paste of the error:

(Process w3wp.exe, PID 3104) "RBAC authorization returns Access Denied for user test001@corp.contoso.com. Reason: No role assignments associated with the specified user were found on Domain Controller CORP-DC-01.corp.contoso.com"

Using the Exchange Management Shell I was able to verify the RoleAssignmentPolicy of the users. I could clearly see that all users created using the Exchange Management Console had the "Default Role Assignment Policy" assigned and that the users provisioned from within FIM had no policy assigned. Verifying the RoleAssignmentPolicy can be done as follows:

• for a specific user: get-mailbox accountname | ft name,roleassignmentpolicy
• for all users: get-mailbox | ft name,roleassignmentpolicy

Some examples:

Using the update-recipient cmdlet I could actually reproduce this behavior without FIM in the picture. It looks like the new-mailbox cmdlet sets the default policy, but the update-recipient cmdlet which can convert a legacy mailbox to a mailbox does not set this policy. Guess what FIM is using…

If you'd want to fix this, you could issue the following command:

• get-mailbox | set-mailbox –RoleAssignmentPolicy "default role assignment policy"

A colleague of me pointed me out to the msExchRBACPolicyLink attribute of a mailbox-enabled user account in AD. This attributes holds the RoleAssignmentPolicy and looks like CN=Default Role Assignment Policy,CN=Policies,CN=RBAC,CN=MAIL,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=CORP,DC=CONTOSO,DC=COM. When I add this attribute to the list of attributes I initially mentioned all goes well. Mailbox created, RoleAssignmentPolicy in place and Exchange Control Panel (options) available!

A possibility to find out which setting is managed by which attribute in AD is to leverage the repadmin command with the showobjmeta option:

• repadmin /showobjmeta name_of_dc dn_of_userobject

The name_of_dc can be one specific domain controller, or you can use a wildcard (*) in your name to target multiple DC’s. Following the DC you can provide the DN of your test user. Now just change a setting (like in this case the RoleAssignmentPolicy) using PowerShell, and then execute the repadmin command. That way you can find out which attribute was changed seconds ago and hence is very likely to represent the setting you can control with FIM. As a (not related) example I got the output of a useraccount which I just disabled in AD. You can clearly see that this is controlled by the “userAccountControl” attribute:

So to conclude I think as a bare minimum the following attributes should be exported when provisioning mailboxes for Exchange 2010:

[Update 21/12/2010] This topic was discussed on the FIM TechNet Forums as there’s some official Technet Documentation out there now, I would like to reference here. For a fully supported Kerberos enabled CAS array, Exchange 2010 SP1 is required, and you can follow this guide: http://technet.microsoft.com/en-us/library/ff808313.aspx

One of the problems I had with FIM 2010 in the past is the configuration of the RPS URI in the FIM Active Directory Management Agent (AD MA) configuration. When you want FIM to provision mailbox’ for you, or when using FIM for GALsync (provision contacts) you have to provide the URL to the exchange PowerShell webservice (http://webmail.contoso.com/powershell):

A lot of Exchange environments have more than one CAS server, typically these are combined with a NLB solution. So ideally you just point FIM to the CAS URL (like webmail.contoso.com) and thus ensuring FIM will not be dependent on the uptime of one specific CAS server. Because the MA only uses Kerberos to connect to that URL, there is a problem. Out of the box the CAS array URL is not kerberos enabled. As such the provisioning of mailbox’ will fail. When targeting a specific CAS server Kerberos authentication goes just fine. Because all required SPN’s are registered for each CAS server by the exchange setup and thus Kerberos authentication against a CAS server works.

From Exchange 2010 RU3 (Or RU4, not quit sure) there is a way to enable the CAS array for Kerberos. The word is out that this would officially be supported from Exchange 2010 SP1. The following steps are required:

1. Create a service account in Active Directory: svc_exchange
2. Register the SPN’s on this account (I always register both FQDN and short):
   • setspn -F -S exchangeMDB/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S exchangeRFR/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S exchangeAB/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S HTTP/webmail.contoso.com CONTOSO\svc_exchange
   • setspn -F -S exchangeMDB/webmail CONTOSO\svc_exchange
   • setspn -F -S exchangeRFR/webmail CONTOSO\svc_exchange
   • setspn -F -S exchangeAB/webmail CONTOSO\svc_exchange
   • setspn -F -S HTTP/webmail CONTOSO\svc_exchange
3. The following steps have to be executed on each CAS server
   • $cred = get-credential "CONTOSO\svc_exchange"
   • Set-clientaccessserver -Identity CASserver -AlternateServiceAccountCredential $cred
   • iisreset
   • restart-service MSexchangeAB
   • restart-service MSexchangeRPC
4. To verify the setting, execute the following on each CAS server
   • Get-ClientAccessServer -Identity CASserver -IncludeAlternateServiceAccountCredentialStatus |fl AlternateServiceAccountConfiguration

From now on, if you use outlook to connect to the CAS array, or just when provisiong with FIM and using HTTP, Kerberos will be used. You can eassily verify this with Klist (Windows 2008 and up built-in) or with Kerbtray. Or just in the security eventlog of a CAS server.

The actual procedure I used comes from the following blog:  TUTORIEL: Exchange 2010 SP1 (Beta) - Activer Keberos pour un pool de serveurs CAS (Client Access Array) As it’s French, I think it’s justified to have some English alternative.

Technet help for the set-clientaccessserver command: http://technet.microsoft.com/en-us/library/bb125157.aspx