When deploying ADFS/IFD solution, you will most likely want to build a seperate ADFS server. Since ADFS is Microsoft’s STS (Security Token Service) many of their applications including Microsoft Dynamics CRM 2011 will be federating with it for single sign-on within your enterprise.
ADFS can be setup on a single server, and can work with multiple instances (Dev, Test, Production) or deployments of Microsoft Dynamics CRM 2011 as show below:
The gotcha is the names of the CRM Organizations across the multiple CRM deployments. You cannot have duplicate organization names between dev, test and production. So for example an organization named CRM, cannot be used in both DEV, TEST and PROD when using ADFS. This will give you the following error message:
An error occurred during an attempt to access to the AD FS configuration database (Write to). Each identifier for a replying party trust must be unique across all replying party trust. This error is because the indentifier in this case CRM is referenced by the identifier https://crm.domainname.com. Once you add in DEV, the duplication occurs when you then try to add TEST and PROD.
A CRM Organization name change is required to use one ADFS server for three seperate deployments, so CRM would become CRMDEV,CRMTEST & CRM, hence eliminating the duplication in identifiers, hence the error. Enjoy!
When implementing ADFS to support Internet Facing Deployments (IFD) for CRM 2011 Claims Based Authentication, many administrators will experience an ADFS 503 error when trying the endpoint for both internal CRM and auth within a browser. The error message is usually 503, service not available. A simple IISreset might do the trick but for these cases it will not.
Previously, the undocumented fix was to use the handlers/FederationMetadata.ashx URL instead of the complete https://internalcrm.domain.com/FederationMetadata/2007–06/FederationMetadata.xml.
The issue behind why the 503 occurs, is because the URL was previously reserved in the Access Control List (ACL). Because of how the URL’s are reserved (before instead of after installation) and change of bindings and ports will leave the reserve URL already in place for /FederationMetadata/2007-06 etc.
From the CRM Server (or ADFS for external trust), using an adminstrative command prompt, issue the following command:
netsh http show urlacl (note: you can also use the > to pipe the output to a text file etc)
You are looking for the reservations made by ADFS:
Now delete the old URL reserveration by entering the following command:
netsh http delete urlacl url=https://+:443/FederationMetadata/2007-06
The URL has been deleted, you will need to reconfigure Claims Based but clicking on the wizard in the deployment manger again, re-stepping through the same steps (next,next,next etc). Now try the URL again and the ADFS 503 error will be gone!
Special thanks to Dan Francis @ Microsoft for contiuning to share ADFS tips together. Enjoy.
I have run into several customers having internally users loginning each time using the companies external crm address. This can cause a bit of anger with your CRM users.
Each ADFS system has an internal URL. This URL can be found by openning up the ADFS Management Console or Using the CRM deployment manager. Using the CRM deployment manager, right click on CRM and hit properties, and navigate to the web tab. This is the internal URL.
The internal URL will pass the domain credentials (Kerboros) and not force the user to login each time. The CRM users will love you!