You find that you can’t logon to your CRM 2011 IFD deployment that you have configured around 12 months earlier.
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'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.
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:
- Open windows Powershell as administrator (right click runas)
- Run the following commands:
- add-pssnapin Microsoft.adfs.powershell
- set-adfsproperties -autocertificaterollover $true
- update-adfscertificate -urgent
- Run the CRM deployment manager
- Run through Configure Claims-Based Authentication Wizard (no changes)
- Run through Configure Internet-Facing Deployment Wizard (no changes)
- Restart the adfs service
From a Command Prompt “cmd” Type
net stop adfssrv
then
net start adfssrv - Restart the Microsoft Asynchronous processing service
From Services Windows
Click the Restart Icon while the Service is selected
- 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.
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
Join the club. Who would have guessed that someone would make an automatic feature in a security system that automatically breaks its self…. WHO? Microsoft!
Pingback: Microsoft CRM 2011 How to Configure IFD Hosted Setup | InteractiveWebs Blog
Thanks a lot for this! We came in this morning to find a ruined environment that hadn’t undergone any change! Lifesaver.
We had the same experience. Glad it helped.
Thanks a lot. If they set the ADFS certificates to expire, wouldn’t be logical to have some sort of notifications sent, at least???
This is not Apple you are talking about…. Still I think the will work it out sooner or later. Perhaps after they get creamed on Windows 8.
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.
Thanks a bunch.
This was the last step in a series of painstaking troubleshooting
BUT the CRM works again!!
Glad to help. Please link to out blog if you blog yourself! We would like others to find this fix if they are experiencing the same issue.
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.
Oh! I missed to thank.
Your post is really useful (and lifesaver)!
Pingback: How to solve Exception: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry on your CRM Server | Idea Manglar
Thanks a lot, 200 Users were not able to work.
With this blog we were able to solve the issue in less than 30 minutes…
Glad to help… Sorry for you that you experienced a “Microsoft Event”.
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.
Thanks for the feedback.
Thank you – This stopped my Monday from sucking as much.
Glad to assist!
Same again, A BIG THANK YOU. Truely a life saver.
Pleasure!
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.
Glad to help.
I love you.
Muchas gracias!!!!! Haz recuperado un ambiente destruido por Microsoft.
Thanks for the help. Surprising this still happens, but then again, don’t do a lot of changes to the ADFS server.
Glad to help.
Heresan another saying thank you for great instructions!
Thank you so much!
This really help me.
Awesome thank you for the quick breakdown, worked like a charm.
You are welcome.
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.
No problem.
That worked! AutoCertificateRollever was already enabled, but I all I did was skip that step.
Great job!
You are welcome.
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?
I do know… it will happen again. Remember you are riding the Microsoft merry-go-round.
only one word – LIFESAVER
You’re most welcome!
Thank you soOooooO~ much!
You rock!
You’re welcome!
That fixed it. Thank you!
Welcome.
Many thanks, this resolved our issue after all other troubleshooting getting us nowhere!
Many thanks for this detailed post. It fixed our critical issue with CRM logins.