CRM 2013 – IfdAuthenticationMethod not working set by OrgDbOrgSettingsTool

 

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

tinder applicazione gratuita Issue:

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

πωσ να μεγαλωσεισ το πεοσ σου Reason:

OrgDbOrgSettingsTool settings are stored, but not honoured

free online dating free chat Solution:

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

 

ejercicios para agrandar el miembro 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:

IfdAuthenticationMethod

null

String

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

Article found at : http://support.microsoft.com/kb/2691237/en-us

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.

 

Failure

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}          crystal body urn:federation:authentication:windows

IntegratedAuthenticationMethod                 String {null}

SetRegardingLookupDefaultEntityType             String

ActivateAdditionalRefreshOfWorkflowConditions     Boolean False

DisableImplicitSharingOfCommunicationActivities     Boolean False

<OrgSettings><IfdAuthenticationMethod>urn:federation:authentication:windows</IfdAuthenticationMethod></OrgSettings>

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).

 

Solution

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. */

update
dbo.FederationProviderProperties
set
NVarCharColumn =

‘urn:federation:authentication:windows’
where (ColumnName =
‘IfdAuthenticationMethod’
and
id
=
‘26332692-CD1E-4DD6-BD5B-07326C43302E’)

/* 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.