Dynamics Community Forum Thread Details

Internal Claims-based Authentication results in "ADFS does not have P3P policy" error

We have been trying to setup a CRM 2015 deployment to support development of some integration tools.

We first tried the "all-in-one" howtos for a developer/demo environment. They worked but there were lots of issues with cramming domain controller, DB, IIS, etc all in one.

When it was decided that claims-based authentication would be needed we decided to go with a less all-in-one environment, though still small.

We've got four VM's running Windows Server 2012 R2:

DC1 - simple domain controller
DB1 - SQL Server
CRM1 - Dynamics CRM server
ADFS1 - AD FS

We've followed the MS doc pretty faithfully:

Implement claims-based authentication internal access" section
technet.microsoft.com/.../gg188587.aspx
It was pretty straightforward in most cases and where not some googling resolved questions.

We have done the suggested tests every step of the way and all has been good. But when we went to test we get the "ADFS doesn't have P3P policy, please contact your site's admin for more details." error back from the request to ADFS.

When I trace the requests (in either IE or FireFox) we get the following:

Req	Resp Code	Header/Notes
https://crminternal.domain.com	302
sts.domain.com/.../ls;wtrealm=https%3a%2f%2fcrminternal.domain.com%2f&wctx=rm%3d1%26id%3d8054838a-d566-4bb7-aa4d-cdebb3ad96b3%26ru%3d%252fdefault.aspx&wct=2015-11-03T02%3a34%3a52Z&	302
sts.domain.com/.../wia;wtrealm=crminternal.domain.com/&wctx=rm=1&id=4fc94b9d-fb70-4665-b442-16ee697d011f&ru=%2fdefault.aspx&wct=2015-11-02T17:10:34Z&wauth=urn:federation:authentication:windows	401	Server: Microsoft-HTTPAPI/2.0 WWW-Authenticate: "NegotiateNTLM"
sts.domain.com/.../wia;wtrealm=crminternal.domain.com/&wctx=rm=1&id=4fc94b9d-fb70-4665-b442-16ee697d011f&ru=%2fdefault.aspx&wct=2015-11-02T17:10:34Z&wauth=urn:federation:authentication:windows	401	Server: Microsoft-HTTPAPI/2.0 WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADgAAAAFgomi9n3RJzUYhoAAAAAAAAAAAKYApgBEAAAABgOAJQAAAA9UAFAAVABEAEUAVgACAAwAVABQAFQARABFAFYAAQAWAFQAUABUAEQARQBWAEEARABGAFMAMQAEABgAVABwAHQARABlAHYALgBsAG8AYwBhAGwAAwAwAFQAcAB0AEQAZQB2AEEARABGAFMAMQAuAFQAcAB0AEQAZQB2AC4AbABvAGMAYQBsAAUAGABUAHAAdABEAGUAdgAuAGwAbwBjAGEAbAAHAAgA5gFTrJEV0QEAAAAA
sts.domain.com/.../wia;wtrealm=crminternal.domain.com/&wctx=rm=1&id=4fc94b9d-fb70-4665-b442-16ee697d011f&ru=%2fdefault.aspx&wct=2015-11-02T17:10:34Z&wauth=urn:federation:authentication:windows	200	Server: Microsoft-HTTPAPI/2.0 P3P: CP="ADFS doesn't have P3P policy, please contact your site's admin for more details."
crminternal.domain.com	302
crminternal.domain.com/.../errorhandler.aspx;wtrealm=https%3a%2f%2fcrminternal.domain.com%2f&wctx=rm%3d1%26id%3d3f7d735e-6568-4150-ae4f-290bbcdbb286%26ru%3d%252fdefault.aspx&wct=2015-11-02T21%3a15%3a20Z&wauth=urn%3afederation%3aauthentication%3awindows&ErrorCode=&Parm0=Error Details: The private key does not support the exchange KeySpec.&RequestUri=/default.aspx&user_lcid=1033	200

The area I have the most doubts about is the certificate generation:

For CRM1 (the CRM Dynamics server) we used the following line to create the self-signed certificate:
- makecert -r -pe -n "CN=*.Domain.com" -ss my -sr LocalMachine -eku "1.3.6.1.5.5.7.3.1" -len 2048 -e "01/01/2020" "\Users\administrator.DOMAIN\Documents\Certificates\Domain.com_CRM1_wildcard.cer"
For ADFS1 (the AD FS server) the command is similar but when it did not work the first time, I added the "-sky exchange" option, based on a comment about CNG certificate templates:
- makecert -r -pe -n "CN=*.Domain.com" -ss my -sr LocalMachine -eku "1.3.6.1.5.5.7.3.1" -len 2048 -sky exchange -e "01/01/2021" "\Users\administrator.DOMAIN\Documents\Certificates\Domain.com_ADFS1_wildcard.cer"

Any help or ideas is much appreciated. Also I really have done a good bit of searching on and off this forum - if I've missed an existing solution my apologies.

I was finally able to get this resolved via partner support issue #115110413335275.

Here is what worked.

Run theses commands (this is what ultimately worked):

On TptDevADFS1 (server with ADFS 3 installed).

Used this command file on TptDevADFS1:
- SETLOCAL
  SET cert_folder=%HOMEPATH%\Documents\Certificates
  IF NOT EXIST "%cert_folder%" md "%cert_folder"
  SET sdk_folder=C:\Program Files (x86)\Windows Kits\8.1\bin\x64
  IF NOT EXIST "%sdk_folder%" ECHO SDK FOLDER %sdk_folder% NOT FOUND.
  IF NOT EXIST "%sdk_folder%" EXIT
  CD "%sdk_folder%"
  echo makecert -r -pe -n "CN=*.TptDev.com" -ss my -sr LocalMachine -eku "1.3.6.1.5.5.7.3.1","1.3.6.1.4.1.311.10.3.12" -len 2048 -sky exchange -e "01/01/2021" "%cert_folder%\TptDev.com_%COMPUTERNAME%_wildcard_exchDocSign.cer"
  ENDLOCAL
Resulted in this command and output:
- C:\Program Files (x86)\Windows Kits\8.1\bin\x64>makecert -r -pe -n "CN=*.TptDev.com" -ss my -sr LocalMachine -eku "1.3.6.1.5.5.7.3.1","1.3.6.1.4.1.311.10.3.12" -len 2048 -sky exchange -e "01/01/2021" "\Users\Administrator.TPTDEV\Documents\Certificates\TptDev.com_TPTDEVADFS1_wildcard_exchDocSign.cer"
  
  Succeeded
  
  C:\Program Files (x86)\Windows Kits\8.1\bin\x64>
The above command imported the certificate into
(Local Computer) Personal->Certificates (aka as certificate store “My”).
Then browse to certificate file and imported it (with exportable key) to
(Local Computer) Trusted Root Certificate Authorities->Certificates
Export key in Personal store as PFX file with options:
include private key, include all certs in chain, export all extended properties.
Copy file to TptDevCRM1 (Server Dynamics CRM 2015 is installed on).

On TptDevCRM1 (server with Dynamics CRM 2015 installed)

Imported PFX certificate (file) into (Local Computer) Personal->Certificates.
Imported PFX certificate (file) into (Local Computer) Trusted Root Certificate Authorities->Certificates

Quick Links