m1tschen
Goto Top

Adfs 3: WAP funktioniert mit 2 NICs, aber nicht mit einer NIC in DMZ

Hallo,
Ich habe ein Problem in Bezug auf die Kommunikation zwischen WAP und dem ADFS-Server.

Zurzeit ist mein WAP-Server wie folgt konfiguriert:
  • Hat 2 NICs. Eine für das interne LAN und eine für die DMZ
  • Die DMZ NIC hat das GW und den DNS-Server des Internet Gateways (Fritzbox)
  • Die LAN NIC hat als DNS die IP meines DC
  • Der WAP ist nicht meiner Domäne beigetreten (nur in einer Arbeitsgruppe)
  • Auf dem WAP-Server ist nur der Microsoft Firewall Port 443 von der DMZ in Richtung LAN geöffnet
  • Auch wenn nicht notwendig, hat meine Hosts-Datei einen Eintrag adfs.domain.com, der auf die ADFS-Server IP zeigt
  • Der LAN DNS Server hat ein Eintrag adfs.domain.com, der auf die ADFS-Server IP verweist
  • https - Links für Zugriff von intern und extern sind beispielsweise https://remote.domain.com oder https://share.domain.com

Der ADFS-Server ist wie folgt konfiguriert
  • Globale Einstellungen Extranet und Intranet zur Formularauthentifizierung
  • Die Multi-Authentifizierung ist auf eine AD-Sicherheitsgruppe eingestellt
  • Ich habe eine Anspruch basierte Authentifizierung für eine SharePoint-Website
  • Lokale Windows-Firewall ist ausgeschaltet

Ebenfalls
  • Der Fingerprint des Zertifikats adfs.domain.com ist auf dem WAP und auf dem ADFS identisch
  • adfs.domain.com ist aus dem Internet erreichbar und zeigt zu meinem Internet-Gateway (Fritzbox)
  • Das Internet Gateway leitet Port 443 an den WAP-Server weiter
  • Die Mikrotik Firewall hat keine Ports offen wie 443, 53, etc
  • Auf dem internen DNS ist ein A-Record adfs.domain.com vorhanden, der auf den ADFS-Server verweist

Das funktioniert alles soweit hervorragend. Allerdings mag ich dieses Szenario nicht, da ich zwei Firewalls habe: die Microsoft FW auf dem WAP und eine Mikrotik FW. Es gibt eine aus meiner Sicht eine nicht benötigte Firewall. Deswegen:

  • Auf den WAP Server habe ich dann die LAN NIC deaktiviert, so dass nur noch die Mikrotik FW zwischen DMZ und LAN steht.
  • Dann habe ich Port 443 geöffnet (geöffneter Filter und kein NAT) auf der Mircotik FW von der IP des WAP Servers in der DMZ zur IP des ADFS Servers im LAN
  • In der Hosts Datei auf dem WAP Server in der DMZ ist ja immer noch der Eintrag adfs.domain.com, der auf die ADFS-IP im LAN zeigt
  • Zudem existiert ja im LAN noch der der DNS-Eintrag adfs.domain.com, der ebenfalls auf die ADFS-Server-IP verweist
  • Ich brauche eigentlich die Vertrauensstellung zwischen ADFS und WAP nicht wieder herzustellen, da diese noch funktioniert. Dennoch habe ich den WAP neu konfiguriert und habe erneut eine Vertrauensstellung hergestellt. Dafür habe ich einen Domain-Admin-Benutzer benutzt. Mir wurde gesagt, dass dieser Benutzer und das Passwort nicht in der WAP-Konfiguration gespeichert werden. Er ist nur erforderlich, um die Vertrauensstellung herzustellen.

Jetzt kann ich die ADFS Login Seite https://adfs.domain.com/adfs/ls/IdpInitiatedSignon.aspx aufrufen.

Aber beim Versuch, die SharePoint - Website über anspruchsbasierte Authentifizierung zu öffnen, erhalte ich die Fehlermeldung, dass die Seite nicht gefunden wurde. Auch durch Passthrough funktioniert es nicht. Nach einer Minute erscheint eine Zeitüberschreitung und ich erhalte die Meldung, dass etwas mit dem Server, den ich erreichen möchte, nicht stimmt.

Als Alternative habe ich auf der Mikrotik FW den Weg vom WAP zum ADFS auf NAT geändert und dann in der Hosts-Datei den Eintrag adfs.domain.com auf die DMZ IP der Mikrotik FW geändert. Leider passiert hier genau das Gleiche. Die ADFS-Anmeldeseite funktioniert jedoch nicht der SharePoint per anspruchsbasierter Authentifizierung und Passthrough-Websites.

Ich habe versucht, die folgenden Seiten zu öffnen

Anspruchsbasierte Authentifizierung

https://share.domain.com

Die Anmeldeseite zeigt den ausgehenden Fehler an

Fehler
Es ist ein Fehler aufgetreten. Wenden Sie sich an Ihren Administrator, um weitere Informationen zu erhalten.
Fehlerdetails
• Aktivitäts-ID: 95cbe3ca-472b-0000-10e4-cb952b47d201
• Fehlerzeit: Fr, 25 Nov 2016 18:31:28 GMT
• Cookie: aktiviert
• Benutzeragentzeichenfolge: Mozilla / 5.0 (kompatibel; MSIE 10.0; Windows NT 6.3; WOW64; Trident / 7.0; .NET4.0E; .NET4.0C)

Passthrough

https://remote.domain.com/rdweb

Ereignisprotokolleinträge
Das Ereignisprotokoll zeigt Fehler, für die ich nichts Hilfreiches gefunden habe.
Microsoft-Windows-Webanwendung Proxy / Admin - Ereignis 13007
Die HTTP-Antwort vom Back-End-Server wurde nicht gefunden. Erwartetes Intervall: 300 Sekunden.

Einzelheiten:
Transaktions-ID: {95cbe3ca-472b-0003-77d-cb952b47d201}
Sitzungs-ID: {95cbe3ca-472b-0003-77d-cb952b47d201}
Name der veröffentlichten Anwendung
ID der veröffentlichten Anwendung: 8ED2698F-806C-6D84-0DAF-91904B7C2C84
Externe URL der veröffentlichten Anwendung: https://remote.domain.com/
Veröffentlichte Back-End-URL: https://remote.domain.com/
Benutzer: <Unknown>
Benutzer-Agent: Mozilla / 5.0 (Windows NT 6.3; WOW64; Trident / 7.0; rv: 11.0) wie Gecko
Geräte-ID: <Nicht zutreffend>
Tokenstatus: Nicht gefunden
Cookiestatus: Nicht gefunden
URL der Clientanforderung: https://remote.domain.com/rdweb
URL der Back-End-Anforderung: https://remote.domain.com/rdweb
Vorauthentifizierungsfluss: PassThrough
Authentifizierungsmodus des Back-End-Servers: PassThrough
Zustandsautomatstatus: BEBodyWriting
Antwortcode an Client: <nicht anwendbar>
Antwortnachricht an Client: <nicht anwendbar>
Aussteller des Clientzertifikats: <Not Found>
AD FS / Admin - Ereignis 511
Die eingehende Anmeldeanforderung ist aus einer ungültigen Verbunddienstkonfiguration nicht zulässig.

Anforderungs-URL:
/adfs/ls?version=1.0&action=signin&realm=urn'%'3AAppProxy'%'3Acom&appRealm=beeb3c84-d60d-e611-80db-00165d0ac802&returnUrl=https'%'3A'%'2F'%'2Fshare.domain.com ' % '2F & client-request-id = 95CBE3CA-472B-0000-0FE4-CB952B47D201

Benutzerprofil:
Untersuchen Sie die Verbunddienstkonfiguration, und führen Sie die folgenden Aktionen aus:
Überprüfen Sie, ob die Anmeldeanforderung alle erforderlichen Parameter und ordnungsgemäß formatiert ist.
Opinions Sie, ob Eine Vertrauensstellung der vertrauenden Seite des Webanwendungsproxys vorhanden und aktiviert ist, und ob sie Bezeichner aufweist, mit den Anmeldeanforderungsparametern übereinstimmen sterben.
Opinions Sie, ob das Zielobjekt der Vertrauensstellung der vertrauenden Seite vorhanden und über den Webanwendungsproxy veröffentlicht ist, und ob es Bezeichner aufweist, sterben mit den Anmeldeanforderungsparametern übereinstimmen
AD FS / Admin - Ereignis 364
Bei einer passiven Verbundanforderung.

Zusätzliche Daten

Protokollname:


Vertrauende Seite:


Ausnahmedetails:
Microsoft.IdentityServer.Web.InvalidRequestException: MSIS7009: Die Anforderung ist fehlerhaft oder ungültig. Wenden Sie sich für weitere Informationen an Ihren.
bei Microsoft.IdentityServer.Web.Protocols.MSISHttp.MSISHttpProtocolHandler.ValidateSignInContext (MSISHttpSignInRequestContext msisContext, WrappedHttpListenerRequest Anfrage)
bei Microsoft.IdentityServer.Web.Protocols.MSISHttp.MSISHttpProtocolHandler.CreateProtocolContext (WrappedHttpListenerRequest Anfrage)
bei Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler (WrappedHttpListenerRequest Anfrage, ProtocolContext & protocolContext, PassiveProtocolHandler & protocol)
Bei Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext (WrappedHttpListenerContext-Kontext)

Ich hoffe ihr könnt mir helfen. Findet der ADFS vielleicht nicht den Weg zurück zum WAP?

Vielen Dank im Voraus
Michael

Content-Key: 323686

Url: https://administrator.de/contentid/323686

Printed on: April 19, 2024 at 15:04 o'clock

Member: aqui
aqui Dec 13, 2016 updated at 14:54:53 (UTC)
Goto Top
Vermutlich machst du einen Denkfehler was die DNS Konfig anbetrifft ?!
Auch wenn du den DNS Eintrag scheinbar verteilst auf deine NIC ist es keineswegs so das der MS Server wenn er über NIC A rausgeht auch den DNS Server an NIC A fragt und bei NIC B den DNS Server an B.
Durch deine unterschiedliche DNS Konfig würdest du bzw. stürzt du den MS Server in ein Dilemma, deshalb verfährt er hier bei DNS ebenso wie auch mit unterschiedlichen Gateways die fälschlicherweise an NIC A und B konfigurioert wurden:
Es gilt immer nur der DNS (und das Gateway) was auf dem NIC Adapter konfiguriert ist, der in der NIC Bindungsreihenfolge des Betriebssystems an erster Stelle steht !
Den anderen DNS (oder Gateway) ignoriert das OS schlichtweg.
Ist das die FB als DNS kann der Server logischerweise keine internen DNS Namen auflösen (klar, kennt die FB als Proxy jDNS ja nicht)
Ist das dein interner DNS kann der wieder keine Internet DNS Namen auflösen wenn du in deinem DNS keine Weiterleitung auf die Fritzbüx konfiguriert hast.
Diese DNS Weiterleitung greift aber natürlich nur wenn der Server auch routen kann (FB liegt ja auf der "anderen" NIC Seite und da geht nur Routing), was du aber vermutlich wohl nicht willst und wenn doch dann sicher nicht konfiguriert hast ?!
Per Default macht kein MS Produkt Routing oder IP Forwarding bei 2 oder mehr NICs:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router

Gut möglich also das das Problem aus diesem DNS Dilemma resultiert und/oder aus fehlendem oder falschen IP Routing.