![]() |
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
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)
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"
![]() |
05. ADFS Configuration Results |
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
- 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
- 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.
--
:: Links / Weiterführende Informationen:
:: Links / Weiterführende Informationen:
Keine Kommentare:
Kommentar veröffentlichen