ADFS Proxy

Der ADFS-Server oder die ADFS-Farm steht in der Regel im internen LAN und erlaubt eine integrierte Authentifizierung. Wenn Dienste aus dem Internet mit dem ADFS-Server sprechen müssen (z.B. Abrufen der Federationmetadata oder Authentifizierung) oder Anwender von draußen ein ADFS-Ticket für den Zugriff auf Office 365 benötigen, dann muss der ADFS-Dienst "sicher" veröffentlicht werden

Anforderung

Die Anforderungen an eine sichere Veröffentlichung sind durchaus hoch:

  • URL/DoS Schutz
    Der Service ist aus dem Internet per HTTPS erreichbar und kann nicht "versteckt" werden. "Security by Obscurity" wäre esein schlechter Ratgeber. Der Proxy kann also schon viele Anfragen abfangen und damit die Belastung des internen ADFS-Systems reduzieren
  • Passende Authentifizierung (MFA, Forms statt Kerberos)
    Der interne ADFS-Server bietet natürlich "Negotiate", also NTLM, und Kerberos an, damit die Anwender keine Anmeldung explizit eingeben müssen. Aus dem Internet funktioniert das nicht. Da darf es dann ein Formular, Basic oder auch Zertifikate oder MFA sein. Der Proxy macht zwar keine Anmeldung, aber der ADFS-Server kann erkennen, ob der Zugriff über einen Proxy erfolgt und kann dann die gewünschte Anmeldeverfahren anbieten.
  • Account Lockout Schutz
    Wenn von draußen jemand mehrfach versucht sich als ein Konto erfolglos anzumelden, dann würde dies bei den meisten Firmen irgendwann auch das interne Konto sperren. Über den ADFS-Proxy kann der ADFS-Service auch dies erkennen und weiter Anmeldungen von extern für eine gewisse Zeit ignorieren.
  • Verfügbarkeit
    Mit einem ADFS-Proxy ist es nicht getan. Niemand würde einen Forest mit nur einem DC betreiben. Der ADFS-Proxy muss bezüglich Verfügbarkeit wie ihre ADFS-Server den Anforderungen entsprechen. Mehrere ADFS-Proxy Systeme mit Loadbalancer etc. müssen möglich sein.

Wenn sie ihren ADFS-Server also einfach mit einem Bein ins Internet stellen würden oder hinter einen NAT-Router per statischer Veröffentlichung erreichbar machen würden, wird trotzdem nicht viel Freude damit haben; von der mangelnden Sicherheit mal ganz abgesehen.

NAT ist keine Firewall, NAT übersetzt Adressen aber auch hinter NAT sind eingehende Verbindungen auf einen Server möglich. Zwar muss die Initiative erst einmal von innen ausgehen, aber eine Hürde ist dies nicht. Skype, Lync und andere Produkte, die Peer2Peer-Protokolle einsetzen, zeigen das gut.

ADFS veröffentlichen

Ein Problem solcher direkten Veröffentlichungen ist oft, dass die Anmeldung per NTLM nicht möglich ist, da Proxy-Server etc. gerne den HTTP-Header abändern. Eine Anmeldung per Kerberos scheitert schon daran, dass der KDC sicher nicht aus dem Internet erreichbar ist. Zumindest sollte er es nicht sein. Sie müssen als ADFS sinnvoll veröffentlichen. Dazu gibt es drei prinzipielle Wege:

  • ADFS-Proxy
    Bei der Installation von ADFS werden Sie nach dem Typ gefragt. Ein ADFS-Proxy ist genau die Rolle, die sie auf einem System in einer DMZ o.ä. installieren, damit Anfragen von Außen mit einem "Formular" beantwortet werden. Der Anwender kann dort dann seine Anmeldedaten eingeben und der Proxy leitet diese dann zum ADFS-Server intern weiter.
  • Reverse Proxy
    Es gibt aber auch andere Produkte, die nach außen ein Formular zur Anmeldung bereit stellen und mit den Anmeldedaten dann nach innen auf den ADFS-Server gehen.
  • Ohne Formular mit SSL
    Es ist etwas unsicherer, eine Webseite per "Basic Authentication" zu veröffentlichen, wenn Sie dafür HTTPS als Zwang vorschreiben. Der Anwender muss seine Anmeldedaten dann nicht in einem Formular mit Cookie übergeben, sondern an dem dem Browser eingeben, aber auf dem Weg zum ADFS-Server ist die Sicherheit gegeben. Dieser Weg ist aber unsicher, wenn der Anwender danach den Browser nicht schließen kann, da man über den "Zurück"-Button eine Sitzung wieder aufnehmen könnte. Die Anwender müssen also entsprechend auch informiert sein.

Alle drei Varianten ermöglichen es einem Client im Internet ein Token vom internen ADFS-Server zu erhalten, welches sie dann an den gewünschten Dienst weiterleiten können.

Zertifikate und ADFS-Proxy

Eine normale Kette von Servern und Dienste für die Bereitstellung von ADFS mit Office 365 und externen Clients besteht aus einen ADFS-Proxy und dem ADFS-Server. Der ADFS-Server ist dabei Mitglied der Domäne um die Authentifizierung durchzuführen. Der ADFS-Proxy steht aber in der Regel in einer gesonderten Netzwerkzone, damit er von extern erreichbar ist und die Anfragen nach innen weiter gibt. Der ADFS-Server erwartet dabei aber eine Authentifizierung des ADFS-Proxy per Zertifikat.

Bei der Einrichtung es Windows 2012R2 Web Application Proxy werden Sie daher nach "Anmeldedaten" für den ADFS-Server gefragt. Dies dient dazu, ein Clientzertifikat des ADFS-Proxy-Servers im ADFS-Server als Authentifizierung zu hinterlegen. Die Zertifikate kann man gut in den verschiedenen Management Konsolen sehen.

Ab Windows 2012 sind die Zertifikate nicht mehr im Store des Computers, sondern in der SQL-Datenbank / Windows Internal Database hinterlegt und hier nicht mehr zu sehen.

Hier auf einem ADFS-Server.

Falls ihnen mal ein ADFS-Proxy "abhanden" kommt, können Sie mit einem Mausklick die Clientzertifikate des Reverse Proxy auf dem ADFS-Server entfernen.

Allerdings müssen Sie nicht immer überall die gleichen Zertifikate verwenden

Does the proxy SSL certificate have to be the same as the AD FS SSL certificate?

If the proxy is used to proxy AD FS requests that use Windows Integrated Authentication, the proxy SSL certificate must be the same (use the same key) as the federation server SSL certificate
If the AD FS property "ExtendedProtectionTokenCheck" is enabled (the default setting in AD FS), the proxy SSL certificate must be the same (use the same key) as the federation server SSL certificate
Otherwise, the proxy SSL certificate can have a different key from the AD FS SSL certificate, but must meet the same requirements
Quelle: AD FS Frequently Asked Questions (FAQ) https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/overview/ad-fs-faq

In dem Zuge ist die folgende Seite sehr lesenswert:

Third Party Proxy

Es muss aber nicht immer die ADFS-Proxy Rolle von Windows Server sein. Die Funktion des ADFS-Proxy ist mittlerweile recht gut bekannt und es gibt nicht wenige Firmen, die eben keinen Windows Server direkt aus dem Internet erreichbar machen wollen, auch wenn es nur ein ADFS-Proxy ist.

Third party proxies can be placed in front of the Web Application Proxy, but any third party proxy must support the MS-ADFSPIP protocol to be used in place of the Web Application Proxy.
Quelle: AD FS Frequently Asked Questions (FAQ)
https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/overview/ad-fs-faq

Auf der Seite "Using a Third-Party Proxy as a Replacement to an AD FS 2.0 Federation Server Proxy" ( https://technet.microsoft.com/de-de/library/hh852618(v=ws.10).aspx) beschreibt Microsoft sehr gut die Anforderungen an einen 3rd Party Proxy:

  • Body
    Darf den Body nicht verändern
  • Request Header
    Alle Header müssen 1:1 zum Backend gegeben werden. Eigene Header dürfen addiert werden
  • Kein 302 Redirect
  • URL /adfs/services/trust
    All Antworten auf diese URL müssen 1:1 zurückgegeben werden
  • URL /adfs/services/trust/mex
    Anfragen an diese URL müssen auf die URL "/adfs/services/trust/proxymex" das Backend weiter gegeben werden
  • NTLM
    Wenn auch über den Proxy die NTLM-Anmeldung genutzt werden soll, muss eine Affinität gewahrt bleiben, so dass folgrende Anfragen zum gleichen Backend gehen
  • HTTP header (“X-MS-Proxy”)
    Jeder Anfrage muss dieser Header addiert werden, damit der Backend erkennen kann, dass die Anfrage über einen Proxy gekommen ist ud dann die Extranet"-Konfiguration genutzt wird. Dies ist für die Nutzung des "Account Lockout"-Schutz erforderlich.
Hier ein paar weitere Links:

Weitere Links