Categories
ADFS CRM Server SharePoint Windows

ADFS 3.0 – Extend Login-Token Lifetime

Without further Configuration, the Lifetime of a Login-Token in ADFS is very limited. To avoid permanent relogins, we need to extend the Lifetime by using PowerShell:

At first we need the Display Name of the Relying Party Trust. Therefore we’ll open the ADFS Management and navigate to ADFS -> Trust Relationships -> Relying Party Trusts.

Then we’ll execute the following one-liner by using the PowerShell-Console:

Get-ADFSRelyingPartyTrust -Name "[Display Name]" | Set-ADFSRelyingPartyTrust -TokenLifetime 720

The Parameter “-TokenLifetime” determines the Lifetime in Minutes. In our case we would have set the Lifetime to 12 Hours.

The changes made will apply immediately and all future Tokens will have now an extended Lifetime.

Categories
ADFS CRM

Event 3005, ID4175 – CRM & ADFS-Error

Fehler: 

Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 26.01.2015 09:16:59 
Event time (UTC): 26.01.2015 08:16:59 
Event ID: 7c097f8cb25c47eaaee0b06824c52971 
Event sequence: 861 
Event occurrence: 109 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/1/ROOT-1-130666738292352050 
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\ 
    Machine name: XXXXXXXX
 
Process information: 
    Process ID: 6392 
    Process name: w3wp.exe 
    Account name: XXXX\XXXXXXXXXX 
 
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://XXXXXXXXX.XXXXXXXXX.XXXX:443/default.aspx 
    Request path: /default.aspx 
    User host address: XXX.XXX.XXX.XXX
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: XXXX\XXXXXXXXXX 
 
Thread information: 
    Thread ID: 24 
    Thread account name: XXXX\XXXXXXXXXX 
    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: 

Ursache:
Wenn das selbsterstellte Zertifikat zur Kommunikation zwischen CRM und ADFS kurz vorm auslaufen ist (~1 Woche), stellt das ADFS ein neues Zertifikat aus und verwendet dieses auch sofort. Die eigentlichen CRM-Server bekommen davon allerdings wenig mit, haben immer noch den Thumbprint vom alten Zertifikat gespeichert und können mit dem nun verwendeten neuen gar nichts anfangen. Dies versucht uns diese Fehlermeldung zu übermitteln.

Behebung:
Zuerst führen wir auf dem ADFS-Server folgende Powershell-Befehle aus: 

Set-AdfsProperties -AutoCertificateRollover $true
Update-AdfsCertificate -Urgent
Im Anschluss daran öffnen wir den CRM Deployment Manager auf dem CRM-Server und führen diese beiden Assistenten nochmals aus:

  • Configure Claims-Based Authentication Unbedingt richtiges (neues) Zertifikat auswählen.
  • Configure Internet-Facing Deployment

Diese müssen einfach nur durchgeklickt werden, sprich “Next”, “Next”, […], Apply.
Zurück auf dem ADFS-Server muss nun der ADFS-Dienst neugestartet werden (“Active Directory Federation Services”).
Jetzt gehts wieder zum CRM-Server, wo der “Microsoft Dynamics CRM Asynchronous Processing Service” neugestartet werden muss. Als letzter Schritt muss noch ein iisreset ausgeführt werden. Nun sollte alles wieder gehen.

Categories
General ADFS Server Windows

ADFS 3.0 – Zertifikat erneuern

Um im ADFS 3.0 ein Zertifikat zu erneuern, muss folgendes getan werden:

  1. Über MMC das neue Zertifikat importieren – ACHTUNG: Es sollte ein Zertifikat mit Private Keys sein
  2. Über All Tasks -> Manage Private Keys… folgende Berechtigungen hinzufügen:
    [Service-Account] – READ
    NT SERVICE\adfssrv – READ
    NT SERVICE\drs – READ
  3. Über das ADFS Management -> Service -> Certificates das neue Zertifikat einspielen. Dies geht über Set Service Communications Certificate.
    Sollte das Zertifikat hier nicht auftauchen, so hat es entweder keine Private Keys oder die Berechtigungen fehlen.
  4. Folgenden PowerShell-Befehl absetzen um den Thumbprint des neuen Zertifikats herauszufinden: 
    Get-ChildItem Cert: -Recurse |
         ? { $_ -is [System.Security.Cryptography.X509Certificates.X509Certificate2] }
  5. Anschließend diesen Befehl absetzen, um das alte Zertifikat durch das neue zu ersetzen: 
    Import-Module ADFS
    Set-AdfsSslCertificate -Thumbprint [Thumbprint des neuen Zertifikats]