CRM 2013 – IfdAuthenticationMethod not working set by OrgDbOrgSettingsTool


First the short ‘less technical version’ , for more details scroll further down!

new age dating site Issue:

Not able to use Single Sign On (Windows Authentication) in a federated setup of CRM 2013

meet online Reason:

OrgDbOrgSettingsTool settings are stored, but not honoured

online dating experience Solution:

Open a support ticket with Microsoft Support! (unsupported solution is further down).


christian dating boundaries The Technical details

In CRM 2011 it is possible to set the IfdAuthenticationMethod to ‘urn:federation:authentication:windows’ using the OrgDbOrgSettingsTools.

From the Microsoft article:




Changes the request sent to the ADFS server. This changes the authentication when users access the org by using the context
Integrated – urn:federation:authentication:windows
Forms – urn:oasis:names:tc:SAML:1.0:am:password

Article found at :

The result of changing this setting is clearly visible when connecting to the IFD url for the Organization:

https://[organizationname].domain.ext/ :

Windows Authentication instead of Forms Based Authentication, this works flawlesly on CRM 2011!

Reason for this is to enable SSO (Single Sign On) when federating multiple Companies/Locations using multiple connected/trusted ADFS servers.



After an (in-place) upgrade to CRM 2013. Or even on a cleanly installed CRM 2013 (UR1) and IFD enabled installation, this won’t result in the above picture.

You will simply be redirected to the Forms Based Authentication as default configured by CRM.


Using the OrgDbOrgSettingsTool

When configuring the setting using the OrgDbOrgSettingsTool, it will store the changed value, as seen here (result of the retrieve action):

Creating Organization Service Proxy with Url- https://org.domain.ext/XrmServices/2011/Organization.svc

Name                 Type Default Value Current Value


ActivityConvertDlgCampaignUnchecked             Boolean        True

EnableReLinkingToExistingCRMRecord             Int 0

IfdAuthenticationMethod                 String {null}          best dating sites boston urn:federation:authentication:windows

IntegratedAuthenticationMethod                 String {null}

SetRegardingLookupDefaultEntityType             String

ActivateAdditionalRefreshOfWorkflowConditions     Boolean False

DisableImplicitSharingOfCommunicationActivities     Boolean False


But it just doesn’t work. When we check the database. The above information is stored in the [orgname]_MSCRM database at the [dbo].[OrganizationBase] table (the XML part).



To get this to work we submitted a Support Ticket with Microsoft, the solution is to configure this by updating the database (unsupported with MS Case!) directly:

/* Find the GUID for the active FederationProvider entry */

SELECT [Id] FROM [MSCRM_CONFIG].[dbo].[FederationProvider] WHERE Enabled=1

Result: 26332692-CD1E-4DD6-BD5B-07326C43302E

/* Update the entry with the Windows Authentication Setting. */

NVarCharColumn =

where (ColumnName =

/* Please keep in mind, this is: unsupported */

Do an iisreset on the CRM Front-End server!


After this change, your setup is ready for use in a federated environment and you clients get signed in ‘automatically’ using Windows Authentication on the internal ADFS server.


Hope this helps other people tweaking this setting, as we couldn’t find much information on this.