Hamburg Studie ADFS und Kerberos Constrained Delegation Autor... []
Hamburg 1. Inhaltsverzeichnis 1. Inhaltsverzeichnis... 2 2. Ausgangslage... 3 3. Anforderung... 5 4. Die technische Problematik... 5 5. Alternativer Ansatz: ADFS... 5 6. Testumgebung... 6 7. Konfiguration ADFS... 8 7.1 Resource ADFS (Unternehmensdomäne ORION.LAN) Teil 1... 8 7.2 Account ADFS (Kundendomäne GEMINI.LAN)... 12 7.3 Resource ADFS (Unternehmensdomäne ORION.LAN) Teil 2... 21 8. Konfiguration der Applikation WSS... 24 9. Konfiguration des TMG/ISA... 29 9.1 Vorbereitungen... 29 9.2 Konfiguration am TMG/ISA... 31 10. Funktionstest... 37
Hamburg 2. Ausgangslage Ein Unternehmen betreibt zwei Sharepoint Farmen. Eine der Farmen wird als Intranet für die Mitarbeiter bereitgestellt und befindet im lokalen Netzwerk (LAN). Die zweite Sharepoint Farm wird für Kunden des Unternehmens bereitgestellt und befindet sich in einem Perimeter Netzwerk für die Kunden. Beide Sharepoint Farmen stellen zum großen Teil gleiche Inhalte bereit, so gibt es Anwendungen, die sowohl von den Mitarbeitern als auch von den Kunden genutzt werden. Während die Mitarbeiter über die Integrated Authentication ggf. über die Basic Authentication auf die interne Farm zugreifen, benutzen die Kunden einen RSA SecurID Token, um auf die Sharepoint Farm des Perimeter Netzwerkes zu zugreifen. Hierfür werden extra Domänen Controller, ACE Server und TMG/ISA Server im Kunden Perimeter Netzwerk zur Verfügung gestellt. Für jeden Kunden (jede einzelne Person) gibt es ein Anmeldekonto in der Perimeter Netzwerk Domäne, die einem SecurID Token zugeordnet wird. Der Vorteil hier: der Anwender muss sein Passwort nicht kennen; er gibt lediglich seine Anmelde-ID, Pin und Token ein, um authentifiziert und autorisiert zu werden. Die Authentifizierung findet über den TMG/ISA Verbund statt. Der Anwender meldet sich formularbasiert am TMG/ISA an und dieser authentifiziert den User per Kerberos Constrained Delegation an der Domäne in dem Perimeter Netzwerk.
Hamburg Aktueller Aufbau der Sharepoint Farmen
Hamburg 3. Anforderung Im Rahmen von Realisierungsmaßnahmen zu Kostensenkungen stellt das Unternehmen die Frage, ob man nicht auf eine der Sharepoint Farmen verzichten könne, da beide Farmen im Grunde genommen gleiche Inhalte zur Verfügung stellen würden. Würde man sowohl Mitarbeiter als auch Kunden auf die gleiche Sharepoint Farm zugreifen lassen, könne man die Server, Lizenzen und Betriebskosten der anderen Farm einsparen. Die Kunden sollen weiterhin mit ihrem SecurID Token arbeiten und sich an der Kundendomäne anmelden, um hier die Autorisation für den Zugriff der Sharepoint Farm in der Unternehmensdomäne zu erhalten. 4. Die technische Problematik Die Umsetzung der Idee scheint schon im Ansatz zu scheitern. Der TMG/ISA Server wurde dazu delegiert, die sich anmeldenden Kunden via Kerberos an der Kundendomäne zu authentifizieren. Der TMG/ISA ist Mitglied der Kundendomäne und kann somit nur gegenüber Kundendomäne via KCD authentifizieren, im Gegenzug können die Anwender auch nur für Services innerhalb dieser Domäne autorisiert werden. Ein Kunde kann also nicht via Kerberos an der Sharepoint Farm der Unternehmensdomäne authentifiziert und autorisiert werden. Auch die Alternative die Kundenkonten in der Unternehmensdomäne anzulegen und die Kerberos Constrained Delegation gegenüber die Unternehmensdomäne durchzuführen scheidet aus, da dies durch Sicherheitsrichtlinien des Unternehmens untersagt ist. 5. Alternativer Ansatz: ADFS Nachdem diverse Alternativen zur Umsetzung diskutiert wurden, die alle kein zufriedenstellendes Ergebnis bringen würden, warf ein Sicherheitsexperte des Unternehmens ein, dass er sich vorstellen könne, dass die Kerberos Constrained Delegation in Verbindung mit ADFS die Anforderungen abdecken könne. Nun waren hier im Allgemeinen die Erfahrungen mit ADFS sehr beschränkt. Auch im Internet ist ADFS verhältnismäßig vage beschrieben; die speziellen Anforderungen des Unternehmens, also die Kombination aus KCD und ADFS, sind bisher gar nicht beschrieben. Die Machbarkeit und Umsetzung muss damit über eine Testumgebung verifiziert werden
Hamburg 6. Testumgebung Um die Machbarkeit zu belegen oder ggf. auch zu widerlegen, wurde eine Testumgebung aufgebaut. Die Testumgebung wurde aufgrund von Ressourcenmangel recht klein gehalten. Rechner Domäne Aufgabe OS TPSRV01 Orion.lan DC, CA, Resource ADFS Win 2008 SP2 WSS Orion.lan Windows Sharepoint Services 3.0 Win 2003 R2 SP3 GEMSRV01 Gemini.lan DC, Account ADFS Win 2008 R2 GEMTMG Gemini.lan TMG Win 2008 R2 Ein ACE Server stand leider nicht zur Verfügung, als Alternative wurde die einfache FBA genutzt. Dies sollte aber keinen Einfluss auf das Ergebnis haben. Die Rechner wurden in zwei Domänen zur Verfügung gestellt, eine Vertrauensstellung existierte nicht. Die Domäne ORION.LAN deckte dabei die Unternehmensdomäne ab, die Domäne GEMINI.LAN hingegen die Kundendomäne in der DMZ. Die öffentliche Domäne wurde durch den Namen PORTALS.LAN repräsentiert. Durch beschränkt zur Verfügung stehende Ressourcen wurden auf den jeweiligen Domänen Controllern auch die ADFS Dienste installiert. Des Weiteren stellte der DC der Unternehmensdomäne auch eine Certification Authority bereit, die sowohl eine Enterprise CA als auch eine öffentliche CA imitierte.
Hamburg LAN WSS 3.0 ADFS (R) ORION.LAN DMZ FBA and KCD ISA/TMG ADFS (A) GEMINI.LAN Internet Customer
Hamburg Testumgebung 7. Konfiguration ADFS Die Installation von ADFS ist unter http://technet.microsoft.com/en-us/library/cc731443(ws.10).aspx ausgiebig beschrieben, daher wird hier nicht näher auf die Installation eingegangen. Pro Domäne wird ein ADFS installiert, außerdem werden auf dem Server, der WSS bereitstellt, die ADFS Web Agents installiert. Die ADFS arbeiten in zwei Funktionen, als Account ADFS und als Resource ADFS. Der Account ADFS ordnet Anmeldekonten und ggf. Gruppenzugehörigkeiten zu und erteilt entsprechende Token. Der Resource ADFS interpretiert entsprechende Token und erteilt Autorisierungscookies für die Applikation. 7.1 Resource ADFS (Unternehmensdomäne ORION.LAN) Teil 1 Im ersten Schritt wird eine so genannte Trust Policy angelegt. Unter dem Reiter General werden der URI und der Endpunkt URL festgelegt.
Hamburg Wichtig zu wissen ist es, dass der Endpunkt URL die öffentliche Adresse enthält, worüber er aus dem Internet erreichbar ist. Der Resource ADFS wird später öffentlich über https://radfs.portals.lan erreichbar sein (Anm.: portals.lan repräsentiert in der Testumgebung eine öffentliche Domäne). Im nächsten Schritt wird ein Display Name für die Vertrauensrichtlinie festgelegt.
Hamburg Im letzten Schritt muss dem ADFS Rechner noch ein Zertifikat zugeordnet werden. Das Zertifikat wurde von der eigenen CA ausgestellt.
Hamburg Nachdem die Trust Policy erfolgreich angelegt wurde, konfiguriert man die so genannten Claims. Drei Claims stehen schon per Default zur Verfügung; diese sind vom Typ Identity Claim und haben die Aufgabe den Anwender zu identifizieren. Für das Testszenario werden noch drei weitere Claims erstellt. Diese sind vom Typ Gruppe und repräsentieren bestimmte Gruppenzugehörigkeiten in der Kontendomäne. Auf der WSS Applikationsebene sollen diese Claims bestimmte Berechtigungen widerspiegeln.
Hamburg Im nächsten Schritt speichert man die Trust Policy ab und kopiert die entstandene XML-Datei auf den Rechner des Account ADFS. 7.2 Account ADFS (Kundendomäne GEMINI.LAN) Die ersten Schritte der ADFS-Konfiguration in der Kundendomäne GEMINI.LAN verlaufen analog zu denen in der Unternehmensdomäne ORION.LAN. Zunächst wird auch hier eine Trust Policy erstellt. Genauso wie in der Domäne ORION.LAN werden URI und Endpunkt URL festgelegt.
Hamburg Auch hier muss beachtet werden, dass der Endpunkt URL, dem öffentlichen URL entspricht. Es folgen die Schritte Display Name für die Policy festlegen und Zertifikat zuordnen.
Hamburg Das Zertifikat wurde von der Enterprise CA in der Domäne ORION.LAN ausgestellt, hier muss also beachtet werden, dass die Rechner, die mit Zertifikaten dieser CA arbeiten, das Root Zertifikat im Ordner Trusted Root CA halten.
Hamburg Im nächsten Schritt werden, wie analog zur Konfiguration der Unternehmensdomäne Orion.lan drei Group Claims hinzugefügt. Ab jetzt unterscheiden sich die Konfigurationsschritte des Account ADFS und des Resource ADFS. In dem Account ADFS wird ein so genannter Account Store erstellt.
Hamburg Hierüber wird festgelegt, welche Attribute aus welcher Quelle in dem ADFS Token insgesamt bereitgestellt werden können. In diesem Szenario werden Attribute direkt aus der Domäne GEMINI.LAN bereitgestellt. Per Default werden natürlich alle Identity Claims in dem Account Store angeboten, wobei nur der UPN an den Token übergeben werden muss. Die beiden anderen Identity Claims sind deaktiviert.
Hamburg Der Account Store wird als nächstes um die Group Claims erweitert, die vorher unter Organization Claims kreiert wurden. Unter anderem findet hier die Gruppen-zu- Group Claim Zuordnung statt, beispielsweise wird der Group Claim gemini_wss_read die AD-Gruppe wssread@gemini.lan zugeordnet. Als nächster Schritt folgt der Import der Trust Policy von ORION.LAN, praktisch die Konfiguration für die Kommunikation mit dem Resource Partner (Alternativ kann die Konfiguration auch manuell durchgeführt werden). Über den Wizard wählt man die vorher abgespeicherte und kopierte Trust Policy
Hamburg Nach dem Import der Trust Policy ist der Resource Partner vorkonfiguriert; es muss lediglich noch festgelegt werden, welche zusätzlichen Claims zu dem Token an den Resource Partner hinzugefügt werden.
Hamburg In diesem Testszenario soll in erster Linie die Identität über den UPN bestimmt und übergeben werden, E-Mail Adresse oder Common Name spielen hier keine Rolle (Von daher sind diese Claims deaktiviert). An den Token übergeben werden sollen zusätzlich die Gruppenzugehörigkeiten. Die Berechtigungsgruppen wurden beim Konfigurieren des Account Stores den vorher definierten Group Claims zugeordnet. Nun gilt es diese Organizational Group Claims auf so genannte Outgoing Group Claims abzubilden, die später an den Token übergeben werden.
Hamburg Nachdem alle benötigten Outgoing Group Claims erstellt wurden, ist der Account ADFS durch konfiguriert. Im letzten Schritt wird die Trust Policy exportiert und beispielsweise auf den Rechner des Resource ADFS gespeichert, um diese dort zu importieren.
Hamburg 7.3 Resource ADFS (Unternehmensdomäne ORION.LAN) Teil 2 Nachdem der Account ADFS fertiggestellt ist, müssen nun noch abschließende Konfigurationen am Resource ADFS durchgeführt werden, beginnend mit der Erstellung eines neuen Account Partners über den Import der GEMINI.LAN Trust Policy. Über den Wizard wählt man die vorher exportierte und kopierte Trust Policy In der Konfiguration des Account ADFS wurden Group Claims auf Outgoing Claims abgebildet, die innerhalb eines Tokens an den Resource ADFS übermittelt werden. Diese Claims sind nun aus der Sicht
Hamburg des Resource ADFS so genannte Incoming Claims, die jetzt auf die Organizational Claims des Resource ADFS abgebildet werden. Für jeden Incoming Claim findet eine Zuordnung zum entsprechenden Organization Claim statt, sodass im Endeffekt jeder relevanten AD-Gruppe aus der Domäne GEMINI.LAN ein bestimmtes Recht auf der WSS-Applikation (in der Domäne ORION.LAN) zugeteilt werden kann. Group Membership Group Claim (GEMINI.LAN) Outgoing/ Incoming Claim Group Claim (ORION.LAN) Application Rights on WSS
Hamburg Um die Konfiguration des Resource AFDS zu komplettieren, muss im letzten Schritt dem Resource ADFS die Applikation zugeordnet werden (via Applications -> New -> Application). Auch hier gilt es zu beachten, das der öffentliche Applikations-URL eingetragen wird. Aktiviert sind im Übrigen die Claims, die für die Applikation relevant sein sollen.
Hamburg 8. Konfiguration der Applikation WSS In diesem Teil geht es darum, die zu veröffentliche WSS Applikation für ADFS vorzubereiten. Nachdem WSS 3.0 installiert wurde, werden die ADFS Web Agents zu dem Server hinzugefügt. (Unter Windows 2008 fügt man die Agents über Rollen hinzufügen hinzu.) Als nächstes wird die Applikation erstellt, die veröffentlicht werden soll.
Hamburg Im nächsten Schritt wird diese Applikation erweitert, sodass eine IIS Website erstellt wird, die auf den URL https://wss.orion.lan angesprochen wird. Diese Web Site wird der Extranet Zone zugeordnet. Außerdem wird ein zusätzliches Alternate Access Mapping für den öffentlichen URL erstellt (https://wss.portals.lan). Jede der Zonen hat einen so genannten Authentifizierungsprovider. Für die Default Zone ist es beispielweise Windows (NTLM oder Negotiate), für die Zone Extranet soll es der SSO Provider werden. Hierfür muss die Applikation über die web.config Dateien konfiguriert werden. Sehr einfach lässt es sich mit dem VB-Script SetupSharePointADFS.vbsumsetzen, welches auf der Seite http://blogs.msdn.com/b/sharepoint/archive/2007/10/11/a-script-to-configure-sharepoint-to-use-adfs-forauthentication.aspx heruntergeladen werden kann. Durch Ausführen von: cscript SetupSharePointADFS.vbs -fs tpsrv01.orion.lan -appconfig C:\Inetpub\wwwroot\wss\VirtualDirectories\wss.orion.lan443\web.config -adminconfig c:\inetpub\wwwroot\wss\virtualdirectories\37945\web.config -cookiepath / -returnurl https://wss.orion.lan/ - urlzone extranet
Hamburg werden die web.config Dateien für die Nutzung von ADFS automatisch angepasst. Änderungen werden sowohl auf Seiten der Applikation als auch auf Seiten der der SharePoint Zentraladministration durchgeführt (-adminconfig und appconfig). Die Änderungen der der Zentraladministration müssen zusätzlich auch für die Web Applikation an sich durchgeführt werden, weshalb das VB-Script ein zweites Mal mit veränderten adminconfig Parametern ausgeführt wird: cscript SetupSharePointADFS.vbs -fs tpsrv01.orion.lan -appconfig C:\Inetpub\wwwroot\wss\VirtualDirectories\wss.orion.lan443\web.config -adminconfig c:\inetpub\wwwroot\wss\virtualdirectories\sp180\web.config -cookiepath / -returnurl https://wss.orion.lan/ -urlzone extranet. 1 2 3 1 = Verzeichnis Sharepoint Zentraladministration 2 = Verzeichnis Erstellte Applikations-Website (Default Zone) 3 = Verzeichnis Erweiterte Website (Extranet Zone) Nach einem IISRESET steht der SSO Authentifizierungsprovider für ADFS zur Verfügung.
Hamburg Zusätzliche Informationen erhält man unter: http://technet.microsoft.com/en-us/library/cc262696(office.12).aspx Die Funktion des SSO Authentication Provider und auch die Funktion des ADFS Web Agents lassen sich testen, indem man beispielsweise Benutzer für die Applikation hinzufügt.
Hamburg Über die Suche nach Anwendern, die mit orion_ beginnen, werden beispielsweise die Group Claims zurückgeliefert, die wir vorher bei der Einrichtung des Resource ADFS erstellt haben, aufgelistet.
Hamburg 9. Konfiguration des TMG/ISA 9.1 Vorbereitungen Um sich via KCD am Account ADFS authentifizieren zu können, müssen einige Rahmenparameter erfüllt sein. Zunächst muss ein Benutzer erstellt werden (hier gemini\adfsviakcd), in dessen Kontext der ADFS Application Pool läuft. Diesem Benutzer muss ein Service Principal Name zugewiesen werden, entweder mit dem Tool SetSPN oder per ADSIEDIT. Setspn a http/federation.gemini.lan gemini\adfsviakcd
Hamburg Dieser Benutzer muss außerdem Mitglied der Gruppe IIS_IUSR (ab Windows 2008) sein. Des Weiteren braucht der Benutzer folgende Benutzerrechte auf dem ADFS (Account) Rechner: Act as part of the operating system Generate Security Audit Events Logon as a Service Darüber hinaus sind folgende Berechtigungen erforderlich: Schreib-/Leserecht auf C:\ADFS Schreib-/Leserecht auf C:\Windows\TEMP Schreib-/Leserecht auf C:\Windows\Microsoft.NET\Framework64\v2.0.50727 Leserecht auf C:\Windows\SystemData\ADFS Schreib-/Leserecht auf C:\Windows\SystemData\ADFS\Logs Leserecht auf den privaten Schlüssel des internen Webzertifikates, welches in der Trust Policy zugewiesen wurde (gemsrv01.gemini.lan) Abschließend muss der ADFS Application Pool neu gestartet werden.
Hamburg Auf der Seite des TMG/ISA muss sichergestellt sein, dass dem Computer für die Delegierung vertraut wird: 9.2 Konfiguration am TMG/ISA Im nächsten Schritt werden auf dem TMG/ISA die Firewallrichtlinien und Web Listener erstellt. Hierfür benötigt werden außer den drei öffentlichen URLs zusätzlich drei öffentliche IP Adressen und drei IP Adressen aus der DMZ; die öffentlichen Adressen werden per NAT auf die DMZ IP Adressen umgeleitet. Des Weiteren sind für jeden öffentlichen URL öffentliche Zertifikate erforderlich. In der Testumgebung wird ein so genanntes SAN Zertifikat genutzt, sodass jeder URL von dem gleichen Zertifikat authentifiziert werden kann.
Hamburg Zunächst werden die Web Listener erstellt. Hierbei ist zu beachten, dass jeder Web Listener eine eigene DMZ IP zugewiesen bekommt.
Hamburg Der TMG/ISA fungiert als Reverse Proxy mit einer Netzwerkkarte, somit ist das interne Netz zu wählen. Die Web Listener sollen alle nur auf SSL geschützte Anfragen reagieren, weshalb dem Web Listener das öffentliche Zertifikat zugeordnet werden muss.
Hamburg Die Web Listener des WSS Portals und des Resource ADFS ist keine Client Authentifizierung erforderlich, sodass für diese Web Listener No Authentication gewählt wird, während für den Web Listener des Account ADFS die Form Based Authentication gewählt werden muss.
Hamburg Da die Anwender sich gegen die Domäne GEMINI.LAN authentifizieren sollen, ist die Authentication Validation Method für Windows gewählt. Nach der Fertigstellung der Web Listener können die Firewall Policies erstellt werden. Die Parameter der drei Firewall Richtlinien sind folgend in tabellarischer Form dargestellt. Funktion Subfunktion Richtlinie: WSS Richtlinie: radfs Richtlinie: aadfs General WSS/enabled radfs/enabled aadfs/enabled Action Allow Allow Allow From Anywhere Anywhere Anywhere To wss.orion.lan tpsrv01.orion.lan gemsrv01.gemini.lan Forward org. Hostheader Nein Nein Nein
Hamburg Requests appear to come from TMG/ISA TMG/ISA TMG/ISA Traffic HTTPS HTTPS HTTPS Listener WSS listener radfs listener aadfs listener Public Name wss.portals.lan radfs.portals.lan aadfs.portals.lan Paths /* /adfs/ls/* /adfs/ls/* Auth. Delegation No delegation No delegation KCD SPN N/A N/A http/federation.gemini.lan Application Settings inaktiv inaktiv inaktiv Bridging SSL nach 443 SSL nach 443 SSL nach 443 Users All Users All Users All Auth. Users Schedule Always Always Always Link Translation Apply to rule Apply to rule Apply to Rule Und die Richtlinien auf dem TMG/ISA im Überblick: Somit ist die Testumgebung konfiguriert.
Hamburg 10. Funktionstest Für den Funktionstest sind vier Testkonten in der Kundendomäne GEMINI.LAN vorbereitet. Jeder dieser Testanwender, bis auf Frank Borman, ist Mitglied in einer der Berechtigungsgruppen für das WSS Portal. In diesem Beispiel wird John Young versuchen sich am WSS Portal anzumelden. John Young wird auf die Seite des Account ADFS umgeleitet und muss sich am TMG/ISA authentifizieren.
Hamburg Im TMG/ISA Log spiegelt sich das folgendermaßen wider. Der Benutzer versucht auf das Portal zu zugreifen (Zeile 1) und wird aufgrund eines fehlenden Cookies auf die Seite des Resource ADFS umgeleitet (Zeile 2). Dieser wiederum leitet den Benutzer zum Account ADFS, damit der Benutzer einen Token beziehen kann. Der TMG/ISA bremst den Benutzer zunächst aus (Zeile 3), da ein non-authentifizierter Zugriff nicht erlaubt ist, und stellt das Anmeldeformular bereit (Zeile 4). Meldet sich der Benutzer erfolgreich über den TMG/ISA an,
Hamburg
Hamburg erhält der Benutzer seinen Token (Zeile 4) und wird zum Resource ADFS zurückgeleitet. Hier erhält er seinen Cookie (Zeile 5) und fordert wieder den URL des Portals an, wo er erfolgreich autorisiert wird (ab Zeile 6).
Hamburg John Young hat sich erfolgreich an dem WSS Portal athentifiziert John Young ist kein Portal-Admin (wssadmin). Das Tab Site Actions fehlt. John Young hat Schreibrechte über die Gruppe wsswrite@gemini.lan Ein Benutzer, der sich zwar authentifizieren kann aber nicht für das WSS Portal autorisiert ist, erhält folgende Meldung:
Hamburg