On Premise 2013 Install with ADFS/Claims Auth - 400 error on https address

(0) Share

Report

Posted on by Community Member

We are attempting to setup Dynamics CRM 2013 on premise, using claims based authentication, a wildcard certificate for our organisation, an ADFS server with an internet facing deployment (IFD).

We are at the stage of CRM working itself, claim authentication setup, and it all works on a http connection now internally only (our working url is for example internalcrm.ourdomain.net/orgname).

However when we attempt to browse to the site on the https address (ie internalcrm.ourdomain.net/orgname) ADFS throws a HTTP 400 Bad Request error.

Not sure if I've given enough detail, however just wondering if anyone else has come across http working but https not in this scenario and ADFS giving a HTTP 400 in this scenario.

*This post is locked for comments

I have the same question (0)

All responses (16)

Answers (0)

Ragnar Hilmarsson 3,427 on at

Like (0)

Report

Hi

I think you need to give us more detail about what you have done.

Have you read this guide?

www.microsoft.com/.../details.aspx

Was this reply helpful? Yes No
Suggested answer

Remon 1,485 on at

Like (2)

Report

Hello Billwinder,

In a normal situation you should not have HTTP enabled anymore for an CBA/IFD setup.

Microsoft supports only a single binding on the CRM site HTTP or HTTPS.

If you can connect to CRM using HTTP, this only means that your CRM setup seems ok, this is totally not related to the CBA setup.

Please start with a first step and check if ADFS is setup correct:

1)

https://[FQDN of ADFS Server/adfs/ls/IdpInitiatedSignon.aspx

If you can login, ADFS itself functions correct.

2)

Check if the CRM Webaddresses are updated to HTTPS.

3)

Check if the CRM CBA setup is correct.

4)

Check if a Trusted Relying Party is setup for the Internal URL inside ADFS

5)

Check if internalcrm.ourdomain.net connects ok.

Let me know the above results, and we'll help you further.

Good luck,

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks a lot Remon, I'll try out some of your suggestions and confirm back if worked.

Was this reply helpful? Yes No
Mohammad Atif on at

Like (0)

Report

blogs.technet.com/.../configuring-ifd-for-crm-2011.aspx :step by Step blog to configure Claims and IFD for CRM 2011

Thanks,

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Remon,

Thanks a lot for taking the time to reply. I put some things we have done below, appreciate you are busy of course, I put some responses in bold.

Thanks very much
Bill

In a normal situation you should not have HTTP enabled anymore for an CBA/IFD setup. Microsoft supports only a single binding on the CRM site HTTP or HTTPS. If you can connect to CRM using HTTP, this only means that your CRM setup seems ok, this is totally not related to the CBA setup.

Please start with a first step and check if ADFS is setup correct:

1) https://[FQDN of ADFS Server/adfs/ls/IdpInitiatedSignon.aspx

If you can login, ADFS itself functions correct.

Our internal ad domain is corp.local, but we have sts.contoso.net and internalcrm.contoso.cnet registered on internal DNS as pinpoint zones with A records and correctly resolvable.

Trying https://sts.contoso.com/adfs/ls/IdpInitiatedSignon.aspx from inside the corporate network generates an error page:

This seems to be the case whether forms or IWA is enabled in global authentication.

The really weird thing throughout is that after deploying AD FS, we deployed the sample claimapp from the technet documentation and configured via the web application proxy.

From outside the corporate network, sts.contoso.com gives FBA page, and I can login. Webtest.contoso.com\claimapp redirects to sts.contoso.com lets me login then passes through to the app and displays correctly:

2)Check if the CRM Webaddresses are updated to HTTPS.

Yes:

3)

Check if the CRM CBA setup is correct.

Yes – believe so, followed all the steps in the deployment pdf. Wizard completes ok and verifies metadata URL.

4)

Check if a Trusted Relying Party is setup for the Internal URL inside ADFS

Yes, set to https://internalcrm.contoso.net/FederationMetadata/2007-06/FederationMetadata.xml

5)

Check if internalcrm.ourdomain.net connects ok.

Let me know the above results, and we'll help you further.

Good luck,

Nope, can see from fiddler that it redirects to sts.contoso.net and then generates the error:

Interestingly chrome generates a “the web page is not available” on the URL

https://sts.contoso.net/adfs/ls/wia?wa=wsignin1.0&wtrealm=https%3a%2f%2finternalcrm.contoso.net%2f&wctx=rm%3d1%26id%3d586a9beb-e726-423e-9147-ff8aa89a717d%26ru%3d%252fdefault.aspx&wct=2014-05-16T13%3a57%3a41Z&wauth=urn%3afederation%3aauthentication%3awindows

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Please ignore my previous post, the images weren't present, and I can't delete the post now. I've included the same post with the images below. Thanks alot, I put my answers in bold!

1) https://[FQDN of ADFS Server/adfs/ls/IdpInitiatedSignon.aspx

If you can login, ADFS itself functions correct.

Our internal ad domain is corp.local, but we have sts.contoso.net and internalcrm.contoso.cnet registered on internal DNS as pinpoint zones with A records and correctly resolvable.

Trying https://sts.contoso.com/adfs/ls/IdpInitiatedSignon.aspx from inside the corporate network generates an error page:

This seems to be the case whether forms or IWA is enabled in global authentication.

The really weird thing throughout is that after deploying AD FS, we deployed the sample claimapp from the technet documentation and configured via the web application proxy.

From outside the corporate network, sts.contoso.com gives FBA page, and I can login. Webtest.contoso.com\claimapp redirects to sts.contoso.com lets me login then passes through to the app and displays correctly:

2) Check if the CRM Webaddresses are updated to HTTPS.

Yes:

3)

Check if the CRM CBA setup is correct.

Yes – believe so, followed all the steps in the deployment pdf. Wizard completes ok and verifies metadata URL.

4)

Check if a Trusted Relying Party is setup for the Internal URL inside ADFS

Yes, set to https://internalcrm.contoso.net/FederationMetadata/2007-06/FederationMetadata.xml

5)

Check if internalcrm.ourdomain.net connects ok.

Let me know the above results, and we'll help you further.

Good luck,

Nope, can see from fiddler that it redirects to sts.contoso.net and then generates the error:

Interestingly chrome generates a “the web page is not available” on the URL

https://sts.contoso.net/adfs/ls/wia?wa=wsignin1.0&wtrealm=https%3a%2f%2finternalcrm.contoso.net%2f&wctx=rm%3d1%26id%3d586a9beb-e726-423e-9147-ff8aa89a717d%26ru%3d%252fdefault.aspx&wct=2014-05-16T13%3a57%3a41Z&wauth=urn%3afederation%3aauthentication%3awindows

Was this reply helpful? Yes No
Remon 1,485 on at

Like (0)

Report

Are you using a proxy? if so disable it for the urls.

adfs should also work internally, check the eventviewer on the adfs server, what error is noted? The 400 bad request is strange and sounds like a firewall/proxy in between.

Let me know!

Was this reply helpful? Yes No
Oleg Kosminsky 35 on at

Like (0)

Report

Hi!

I have the same problem.

When I try adfs.domain.ru/.../IdpInitiatedSignon.aspx, firstly it asks me credentials, than it fails.

It happens when I use IE, Chrome, Opera, Safari.

But it Firefox it works correctly. So, now I can use my CRM only in Firefox.

Do you have any ideas?

Thanks!

Was this reply helpful? Yes No
Mayank Singla 25 on at

Like (0)

Report

Hi Remon,

I have ADFS 3.0 and CRM 2013 on Server 2012 R2. I have removed http binding as advised. As for step 1, unable to login on https://[FQDN of ADFS Server/adfs/ls/IdpInitiatedSignon.aspx it keeps giving 400 bad request. Any suggestions?

Was this reply helpful? Yes No
Suggested answer

Remon 1,485 on at

Like (1)

Report

Hi,

did any of you had a look the SPN's set for your ADFS service account?

there should be an SPN registered for your ADFS service account (Local System = machinename$)...

If not register it: HTTP/FQDN (example: HTTP/sts.contoso.com )

Good luck and let us know!

Was this reply helpful? Yes No