none
Durchgehende Windows Authentifizierung von externem Reverse Proxy zu IIS Websites auf internem Server RRS feed

  • Frage

  • Hallo zusammen,

    das ist meine erste Frage hier, bin mal gespannt wie das ankommt ;-)

    Aktuell habe ich einen öffentlich erreichbaren Reverse Proxy (beispielhaft "reverse.proxy.com") unter IIS 8.5 mit URL-Rewrite 2.0 eingerichtet. Der Reverse Proxy befindet sich in einem Active Directory und vermittelt zwischen mehreren Websites, die auf einem internen IIS 7.5 Server (beispielhaft "internalserver") laufen (ebenfalls im AD) und dem Client, der von außen anfragt.

    Z.B. vermittelt der Reverse Proxy bei einem externen Aufruf von "internalsite.reverse.proxy.com" zur Website "internalsite" auf dem internen Server "internalserver".

    Ich habe nun unter der Hauptadresse "reverse.proxy.com" eine kleine Website geschaffen, auf der mehrere Links sind, die auf die einzelnen Websites verlinken (z.B. internalsite.reverse.proxy.com, internalsite2.reverse-proxy.com etc.).

    Sowohl beim Reverse Proxy als auch beim internen Server ist überall die Windows Authentifizierung (NTL und Negotiate) aktiv. Das heißt, browst man auf reverse.proxy.com, wird nach Windows Credentials gefragt. Die Authentifizierung klappt auch wunderbar. Klickt man nun auf einen der Links wie z.B. internalsite.reverse.proxy.com, wird man natürlich erneut nach Windows Credentials gefragt, da die Windows Authentifizierung auch auf dem internen Server aktiv ist. Auch dort kann ich mich erfolgreich anmelden. Dies wiederholt sich allerdings für alle internen Websites, die man von außen über den Reverse Proxy ansurft.

    Jetzt kommen (endlich) meine eigentlichen Fragen:

    Wie kann ich es realisieren, dass man sich nur EINMAL mit den Windows Credentials einloggen muss, und zwar auf der Hautpwebsite (reverse.proxy.com)?
    (Quasi session-based)

    Lässt sich das mit NTLM überhaupt realisieren?
    (NTLM ist ja soweit ich weiß nicht stateless, also eigentlich nicht HTTP konform und authentifiziert wohl auch nur die TCP Verbindung. Kerberos kommt bei mir wahrscheinlich nicht in Frage, da ich keinen öffentlich erreichbaren Domain Controller habe.)

    Da sich der Reverse Proxy ja im Active Directory befindet, muss es doch irgendwie möglich sein, dass er die Windows Authentifizierung auf den internen Server weitergibt.

    Zu diesem Szenario konnte ich leider keine wirklich relevanten Infos im Web finden, da sich fast alles um Kerberos dreht.
    Ich hoffe ich konnte mich einigermaßen klar ausdrücken (ansonsten laut schreien) und freue mich auf alle Vorschläge :-).


    • Bearbeitet StefanAhua Mittwoch, 29. November 2017 10:58
    Mittwoch, 29. November 2017 10:57

Antworten

  • Moin,

    für solche Szenarien ist das im IIS mittels URL Rewrite implementierte Verfahren weder gedacht noch geeignet. Was Du brauchst, ist ja ein Proxy-Verfahren, das die Authentifizierung weitergibt. Der ISA und später TMG konnte das, ebenso wie die zahlreichen Produkte, die zu deren Ablösung angetreten sind.

    Eine Alternative wäre freilich der Web Application Proxy, der seit 2012R2 als Feature vorhanden ist. Dafür brauchst Du ADFS, wofür das Ganze ja ursprünglich entwickelt worden ist (der erste Wurf hieß auch "ADFS Proxy"). Schau mal hier: https://technet.microsoft.com/en-us/library/dn584113(v=ws.11).aspx 


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    • Als Antwort markiert StefanAhua Mittwoch, 10. Januar 2018 12:21
    Mittwoch, 29. November 2017 11:30

Alle Antworten

  • Moin,

    für solche Szenarien ist das im IIS mittels URL Rewrite implementierte Verfahren weder gedacht noch geeignet. Was Du brauchst, ist ja ein Proxy-Verfahren, das die Authentifizierung weitergibt. Der ISA und später TMG konnte das, ebenso wie die zahlreichen Produkte, die zu deren Ablösung angetreten sind.

    Eine Alternative wäre freilich der Web Application Proxy, der seit 2012R2 als Feature vorhanden ist. Dafür brauchst Du ADFS, wofür das Ganze ja ursprünglich entwickelt worden ist (der erste Wurf hieß auch "ADFS Proxy"). Schau mal hier: https://technet.microsoft.com/en-us/library/dn584113(v=ws.11).aspx 


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    • Als Antwort markiert StefanAhua Mittwoch, 10. Januar 2018 12:21
    Mittwoch, 29. November 2017 11:30
  • Danke für die Info! Aktuell gibt es leider keinen AD-FS Server in unserer Domäne (der ja für die Einrichtung der Server Rolle als Web Application Reverse Proxy zur Authentifizierung gegen die Domäne notwendig ist), jedoch besteht eventuell die Möglichkeit den Office365 AD-FS zu verwenden, da sich dieser gegenüber unserer Domäne authentifizieren kann.

    Soll ich diesen Post solange offen halten (kann man den überhaupt schließen?), damit noch weiterer Input kommen kann (der eventuell anderen weiterhilft)?

    Vielen Dank schonmal!

    Edit: Ich habe das Thema nicht mit dem ADFS vom Office365 umgesetzt, sondern mit einem eigenen.

    • Bearbeitet StefanAhua Mittwoch, 10. Januar 2018 13:02
    Mittwoch, 29. November 2017 13:22
  • Nochmal zusammengefasst:

    Das Szenario lässt sich mit einem ADFS Server und einem Web Application Proxy durchsetzen. Folgendes Szenario lies sich dadurch erfolgreich einrichten:

    Die AD Domäne lautet hier domain.local.

    Ein IIS Server (in der AD Domäne):
    - Hostet einzelne Sites, die nur im Intranet erreichbar sind (z.B. https://app1.domain.local)
    - Die Sites haben die Windows Authentifizierung eingerichtet

    Ein ADFS Server (in der AD Domäne):
    - Hat die Serverrolle ADFS und ist für die Authentifizierung des Web Application Proxy gegenüber de Domäne verantwortlich

    Ein Web Application Proxy:
    - steht je nach Szenario außerhalb oder innerhalb der AD Domäne, meistens außerhalb und in einer DMZ. In Meinem Fall ist er Mitglied der Domäne, damit das Delegieren der Windows Authentifizierung an den IIS funktioniert (mehr dazu weiter unten)
    - hat zwei Netzwerkverbindungen (eine ins Intranet zum ADFS, eine ins Internet)
    - bekommt bei der Rollenkonfiguration als ADFS Server den Public FQDN des ADFS adfs.kaffatos.com
    - Auf dem Web Application Proxy zeigt der Public FQDN des ADFS (adfs.domain.com) auf die interne IP des ADFS (Muss so sein!). Ich habe das mit der lokalen Hosts Datei auf dem Web Application Proxy gelöst, keine Ahnung ob das der beste Weg so ist...

    Der Public FQDN des ADFS (z.B. adfs.domain.com) zeigt auf die Public IP des Web Application Proxy (!).
    Der Public FQDN des Web Application Proxy (z.B. wap.domain.com) zeigt auf die Public IP des Web Application Proxy.
    Die Public FQDNs der einzelnen Web Applications auf dem Web Application Proxy zeigen auf den Web Application Proxy.

    Wenn man nun https://app1.domain.com von einem Client aufruft, der im AD ist und auf dem ein AD User angemeldet ist (also im Intranet oder via VPN), wird der IIS trotzdem noch nach Windows Anmeldeinformationen fragen, da ja auf dem IIS nach wie vor die Windows Authentifzierung aktiv ist. Damit dies nicht passiert sondern ein Single Sign On verwendet wird, empfehle ich folgenden Link (Step 3 und 4 im Besonderen):
    https://technet.microsoft.com/en-us/library/dn280943(v=ws.11).aspx#Step 3: Configure and test accessing a website using Integrated Windows authentication

    Hierdurch werden die Anmeldeinformationen, die man an den ADFS weitergibt, automatisch auch für die Windows Authentifizierung auf dem IIS Server verwendet.
    Hierfür muss der Web Application Proxy Mitglied der Domäne sein!

    Bitte seht mein Vorgehen nicht als Best Practice, ich habe das zum ersten Mal gemacht. Das ganze läuft auch in keiner Produktivumgebung ;-)












    • Bearbeitet StefanAhua Mittwoch, 10. Januar 2018 17:24
    Mittwoch, 10. Januar 2018 13:00