AD FS certificate rollover CRM 2011

You find that you can’t logon to your CRM 2011 IFD deployment that you have configured around 12 months earlier.

image

In the browser you may see:

HTTP Error 401 - Unauthorized: Access is denied

<html><body><p>
An error has occurred. 
<br/><br/>
Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization&#39;s Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support.
</p></body></html>
 
Looking at the server log may show:

SERVER Log Error show: 1309

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 9/07/2012 12:09:59 PM
Event time (UTC): 9/07/2012 2:09:59 AM
Event ID: 50c7c9d7c3ba4b839bca7c72b9edf410
Event sequence: 51779
Event occurrence: 11
Event detail code: 0
 
Application information:
    Application domain: /LM/W3SVC/2/ROOT-1-129862684501956875
    Trust level: Full
    Application Virtual Path: /
    Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\
    Machine name: VSERVER08
 
Process information:
    Process ID: 3208
    Process name: w3wp.exe
    Account name: NT AUTHORITY\NETWORK SERVICE
 
Exception information:
    Exception type: SecurityTokenException
    Exception message: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

 
 
Request information:
    Request URL: https://auth.interactivewebs.com:444/default.aspx
    Request path: /default.aspx
    User host address: 124.189.39.157
    User: FSERVER4\Administrator
    Is authenticated: True
    Authentication Type: Negotiate
    Thread account name: NT AUTHORITY\NETWORK SERVICE
 
Thread information:
    Thread ID: 15
    Thread account name: NT AUTHORITY\NETWORK SERVICE
    Is impersonating: True
    Stack trace:    at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.CreateClaims(SamlSecurityToken samlSecurityToken)
   at Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
   at Microsoft.IdentityModel.Web.TokenReceiver.AuthenticateToken(SecurityToken token, Boolean ensureBearerToken, String endpointUri)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request)
   at Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at Microsoft.Crm.Authentication.Claims.CrmFederatedAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 
 
Custom event details:

And you find an error in the login attempt that gives you a 401 error.

ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.

Cause

The likely cause is that the ADFS certificate rollover has happened. Basically the self issued certificate that is used and configured as part of your IFD setup with CRM and AD FS has issued a new certificate around 1 week before the expiry of the old one.

If you start the SD SF services and look under:

Service >> Certificates

You will notice a primary and secondary certificate.

image

The Fix

Basically the certificate automatically rolls over to a new one and ADFS won’t authenticate any more. Here are the steps that seem to fix this issue:

  1. Open windows Powershell as administrator (right click runas)image
  2. Run the following commands:
  3. add-pssnapin Microsoft.adfs.powershell
  4. set-adfsproperties -autocertificaterollover $true
  5. update-adfscertificate -urgent
  6. Run the CRM deployment manager
    image
  7. Run through Configure Claims-Based Authentication Wizard (no changes)
  8. Run through Configure Internet-Facing Deployment Wizard (no changes)
  9. Restart the adfs service
    From a Command Prompt “cmd” Type
    net stop adfssrv
    then
    net
    start adfssrv
  10. Restart the Microsoft Asynchronous processing service
    From Services Windows
    Click the Restart Icon while the Service is selected
    image
  11. run an iisreset from the elevated command prompt
    Start RUN “cmd”
    iisreset

From here you should be good to go.

If you need assistance with CRM IFD setup see this post: http://www.interactivewebs.com/blog/index.php/server-tips/microsoft-crm-2011-how-to-configure-ifd-hosted-setup/

NOTE: In our case, the running through of the authentication wizard had defaulted the names back to the server name. We needed to manually put in the address correctly as per the setup of the IFD explained in the link above.

 

Author: InteractiveWebs

This blog is the combined blog work of the InteractiveWebs Dev Team. Together we work on a range of DotNetNuke (DNN) applications, modules, Silverlight, and Microsoft CRM Portal integration products. Our Business is website design and hosting, with a strong focus on DotNetNuke, Microsoft Dynamics CRM, Silverlight and iPhone iPad development.

45 thoughts on “AD FS certificate rollover CRM 2011”

  1. thank you so much!
    i’ve spent hours to find out why authentification suddenly wasn’t working anymore.
    after reading your post and applying your solution everything worked flawlessly again!
    BR

  2. Thanks a lot. If they set the ADFS certificates to expire, wouldn’t be logical to have some sort of notifications sent, at least???

  3. Hi…I have wild card certificate which is going to expire on 21st nov,2012.So please tell me what are the steps which I have to follow to to update certificate and ADFS 2.0.

    1.Does I have to attached renewed certificate again to default website and CRM website.

    2.Does I have to add these entry again to MMC for personal and Trusted certificate.

    If Not,then do let me know what are the steps that need to perform as still there are 20 days for certificate expiration.

    Please Help…It’s urgent.

  4. Almost anyone have automatic certs rollover on by default.
    So, you need only 2 steps:
    In CRM (Deployment Manager) run through (Configure Claims-Based Authentication Wizard) with NO changes! This step changes field (CertificateData) value (of a row that has (Type = TrustedIssuer) in [MSCRM_CONFIG].[dbo].[Certificates] table) with active/fresh/primary cert published in ADFS metadata (that non-updated value, that was a content of inactive/previous/secondary ADFS cert – was the core reason of this problem)
    In IIS management, stop CRM application pool (CRMAppPool) and start it.

  5. Ran in to a similar bit with Google Apps. Was kinda curious the signing certs had to be valid certs(not expired) and would still work.

  6. Saved my bacon as well, thanks!! I might add I had to reestablish the “trust” between ADFS and my ADFS Proxy server. Basically just went through the wizard again and supplied credentials.

  7. Thanks for this. Just saved what I suspect would have been a huge amount of time.

    Re-running the Configure Claims-Based Authentication Wizard without changes and then stopping and starting the CRMAppPool did the job.

    Thank you.

  8. You also saved us! We encountered the issue yesterday and were up and running again before start of business this morning. The only question I have is whether or not this will happen again next year. Does anyone know?

Leave a Reply to TJ Cancel reply

Your email address will not be published. Required fields are marked *