29.01.2014

Increasing ADFS Token Timeout Time for Microsoft Dynamics CRM 2013

Wenn man via IFD auf einer CRM2013 Organisation arbeitet, kann es schon manchmal lästig sein, sich alle 60 Minuten (bzw. sogar 40 Minuten) neu einloggen zu müssen. Das ist nämlich die Zeitspanne, für die ein ADFS Token im Standard gültig ist.

Der Token ist abgelaufen...

Um die Zeitspanne auf z.B. 4 Stunden hochzusetzen muss man folgende auf dem ADFS-Server durchführen:


  1. Den ADFS Manager starten und den Display Name der Relying Party Trust ermitteln. 
    Anzeigename der Relying Party Trust
  2. Windows PowerShell als Administrator starten.
Aktuelle Werte eines Relying Party Trust auslesen:
Get-ADFSRelyingPartyTrust –Name:"crm"

Token Lifetime auf 4 Stunden setzen:
Set-ADFSRelyingPartyTrust –TargetName "crm" –TokenLifetime 240


Token Lifetime ist 4 Stunden

--
:: Links / Weiterführende Informationen: 

How to Configure IFD Hosted Setup in Dynamics CRM

In diesem Beitrag möchte ich die Schritte für ein IFD dokumentieren. Da es sich um eine Demoumgebung handelt wurden alle benötigten Komponenten auf einem Server installiert. Die Installation fand auf einem Windows Server 2012 in der Domain "CRM2013" statt.

0. Schematische Darstellung eines IFD-Logins (hier noch unter CRM 2011)


Die benötigten Komponenten und Rollen sind:
  • Active Directoy (AD)
  • Active Directory Federation Services (ADFS)
  • Datenbank (SQL Server 2012)
  • CRM (Microsoft Dynamics CRM 2013 On-Premise + UR 1)
  • DNS-Server
ADFS-Server
Unter Windows 2012 ist ADFS keine Komponente, die man herunterläd und zusätzlich installiert, sondern eine Serverrolle:

01. ADFS Server-Rolle in Windows Server 2012

CRM-Server
Da sich ADFS automatisch in die Default Website installiert, muss das CRM auf einem anderen Port installiert werden (z.B. 5555). Auch das HTTPS des CRMs kann nicht über die gewohnte 443 laufen. Ich habe das CRM HTTPS auf 444 konfiguriert.


02. HTTP Ports der CRM Installation

Zertifikat
Als erstes benötigt man ein SLL Zertifikat. Da wir mehrere (Sub-)Domain über HTTPS laufen lassen wollen, eigenet sich ein Wildcard Zertifikat wie "*.akquinet.de" am Besten. Dieses muss auf dem Server installiert werden.


02. Wildcard SSL Zertifikat

DNS Einträge
Des Weiteren benötigen wir einige Einträge im DNS, die in unserem Fall alle gegen die IP des Server, auf dem wir installieren, aufgelöst werden müssen.


04. Benötigt DNS Einträge

Auf Server und Client hilft nach der Einrichtung der DNS Einträge oft ein

ipconfig /flushdns 

um Probleme bei der korrekten Autlösung zu beheben.

Firewall
Zusätzlich sollte man darauf achten, dass alle eingerichteten Ports auch durch die Firewall hindurch kommen und von den Clients aus erreicht werden können. In unserem Fall sind das
  • 80
  • 443
  • 444
  • 5555 (nur intern) 
Alternativ kann man auch die Firewall komplett ausschalten - dies sollte man allerdings nur bei Test- oder Demo-Umgebungen machen.

ADFS konfigurieren
Um ADFS initial zu konfiguerieren, wählt man im Wizard folgende Einstellungen:
  • "Create a new Federation Service"
  • Deployment Type: Stand-alone federation server
  • Federation Service name: "sts1.akquinet.de"
Danach sollte ADFS erfolgreich konfiguriert sein:

05. ADFS Configuration Results
Wenn die Konfiguration erfolgreich war, kann man über die URL

https://sts.akquinet.de/federationmetadata/2007-06/federationmetadata.xml

die Metadaten im Browser anschauen.

06. ADFS Metadata

Microsoft Dynamics CRM Properties
Im Deployment Manager des CRMs öffnet man die Deployment Properties, stellt das Binding auf HTTPS um und aktualisiert die URLs wie folgt:

07. CRM Deployment Properties

Claims-Based Authentication konfigurieren
Nun kann man den Wizard für die Claims-Based Authentication im Deployment
Als Federation Metadata URL ist die bereits verwendete URL einzugeben:


08. Claims-Based Authentication Wizard: Federation Metadata URL

Als Zertifikat wähl man das Wildcard Zertifikat aus:

09 Claims-Based Authentication: Select Certificate

Nachdem man sich über diverse Next-Buttons bis zum Ende geklickt hat, darf man nicht vergessen, das Log zu öffnen, nach unten zu scrollen und sich die dort angezeigte URL zu speichern:


10. Claims-Based Authentication: End


Auch diese URL kann man im Browser validieren.

Edit Claim Rules
Im ADFS Management Tool zu Trust Relationships -->Claims Provider Trust --> Active Directory navigieren und dort im Kontextmenü "Edit Claim Rules..." auswählen. 


11. Edit Claim Rules

Hier muss nun eine neue Rule über "Add Rule..." angelegt werden. Dafür gibt es auch wieder einen Wizard. Die Werte können den folgenden Screenshots entnommen werden:


12. Claim rule template "Send LDAP Attributes as Claims"
13. UPN Claim Rule

Relying Party Trust konfigurieren (intern)
Im ADFS Manager muss nun ein neuer Relying Party Trust hinzugefügt werden. Wichtig ist hier, als Federation metadata address die URL anzugeben, die wir uns beim Einrichten der Claims-Based Authentication im CRM aus dem Log-File gemerkt haben:

https://crm2013demointernal.akquinet.de:444/FederationMetadata/2007-06/FederationMetadata.xml

14. Relying Party Trust hinzufügen

Nachdem erfolgreichen Anlegen des Trusts, müssen im Claim Rule Editor folgende drei Claim Rules angelegt werden:

1. Pass Through UPN
  • Claim rule template: Pass Through or Filter Incoming Claim
  • Incoming claim type : UPN
  • Pass through All claim values
2. Pass Through Primary SID

  • Claim rule template: Pass Through or Filter Incoming Claim
  • Incoming claim type : Primary SID
  • Pass through All claim values

3. Transform Windows Account Name to Name

  • Claim rule template: Transform an Incoming Claim
  • Incoming claim type: Windows account name
  • Outgoing claim type: * Name
  • Pass through All claim values


15. Claim Rules

CRM 2011 IFD konfigurieren
Jetzt kann man im CRM Deployment Manager den Wizard für IFD starten:


16. IFD Wizard 1: URLs


17. IFD Wizard 2: External Domain


18. IFD Wizard 3: System Checks

Relying Party Trust konfigurieren (extern)
Im ADFS Manager muss nun ein weiterer Relying Party Trust hinzugefügt werden. Die Federation metadata address hat diesmal die Subdomain auth. - die wir im vorherigen Schritt im IFD Wizard konfiguriert haben:

https://auth.akquinet.de:444/FederationMetadata/2007-06/FederationMetadata.xml


19. Relying Party Trust hinzufügen

Acuh hier müssen nach erfolgreichem Anlegen des Trusts, folgende drei Claim Rules angelegt werden:

1. Pass Through UPN
  • Claim rule template: Pass Through or Filter Incoming Claim
  • Incoming claim type : UPN
  • Pass through All claim values
2. Pass Through Primary SID

  • Claim rule template: Pass Through or Filter Incoming Claim
  • Incoming claim type : Primary SID
  • Pass through All claim values

3. Transform Windows Account Name to Name

  • Claim rule template: Transform an Incoming Claim
  • Incoming claim type: Windows account name
  • Outgoing claim type: * Name
  • Pass through All claim values
20. Claim Rules

FERTIG!
Damit sind wir fertig und auch der extern Zugriff sollte funktionieren. Das Login Form kann hier

C:\inetpub\adfs\ls\FormsSignIn.aspx

bzw. hier

C:\inetpub\adfs\ls\MasterPages\MasterPage.master

angepasst werden.

21. Login Form
Achtung
Eventuell muss ADFS, der ISS oder am besten gleich der gesamte Server neu gestartet werden.