Unexpected/Inaccurate federation metadata XML generated by CRM federation metadata URLs

  • Article

Hi All,

Today we’re are going to talk about the unexpected/Inaccurate federation metadata XML generated by CRM federation metadata URLs. I have seen many people getting into this. Let’s take a deep dive into usage of federation into CRM.

We all know that CRM 2011 uses AD FS 2.0 to provide claims based authentication. For AD FS STS (Security Token Service) to provide a Security Token (SAML Token) for CRM application to consume AD FS has to know some basic information like format, content (basically claims) etc. so that the Token issued by AD FS STS is consumable by CRM application.

Being application’s requirement CRM 2011 has to tell AD FS on what format, information it should have SAML token. CRM 2011 achieved this by providing Federation Metadata URL from which AD FS can retrieve the Federation Metadata for CRM application.

CRM maintains separate external and internal endpoints so it can tell AD FS to authenticate the internal users (users on the company network/VPN) to be authenticated using Kerberos authentication and the external users using AD FS form based authentication. Here is a sample of what external and internal URL may look like:

External Federation metadata URL:

https://crmauth.namma.com/FederationMetadata/2007-06/FederationMetadata.xml

Internal Federation metadata URL:

https://crmint.namma.com/FederationMetadata/2007-06/FederationMetadata.xml

Further to clarify internal Federation metadata URL is the one which you specify on Web Address tab of Deployment Properties in Deployment Manager tab. External Federation metadata URL is the one specified in text box “Enter the external domain where your Internet-lacing servers are located:” on 3rd page on Configure Internet Facing Deployment wizard in Deployment manager.

Ideally, both internal and external Federation Metadata XML has different CRM endpoints specified to tell AD FS to differentiate the authentication behavior.

In odd situations you may see both internal and external CRM federation metadata URLs returning external end points in XML. When such wrong end points are given by internal federation metadata URL, browsing internal URL shown AD FS sign-in page, 404 on providing credentials on the AD FS sign-in page.

Here are screenshots for pictorial representation of this behavior:

You can see in above example that both internal and external URL exhibits external endpoints which is unexpected.

This behavior happens when there is default port number specified with Internal URL under deployment properties. Port 443 is not required when HTTPS (SSL) is specified as its default port for HTTPS communication. However, there could be a situation in which CRM website HTTPS bindings has a custom port specified e.g. 444. In such scenarios one have to specify port 444 explicitly as its not known to be HTTPS communications port. Removing the port number 443 gives expected Federation Metadata XML. In other words, specifying internal URL like internalcrm.crm.namma.com instead of internalcrm.crm.namma.com:443 followed by IIS reset returns expected behavior.

Here is a sample screenshot:

Thanks & Regards
Bhavesh Shastri