Ich habe eine ASP.Net-Site, die in IIS 10 auf dem Windows Server 2019 DataCenter in Azure gehostet wird. Für diese Site ist nur die Windows-Authentifizierung aktiviert.
Wenn ich die Site direkt aufrufe (http://mysite-backend.example.com) Ich werde nach Anmeldeinformationen gefragt, danach funktioniert alles wie erwartet. Wenn ich über das App Gateway (konfiguriert mit privater IP) auf die Site zugreife (https://mysite.example.com) Ich werde zur Eingabe meiner Anmeldeinformationen aufgefordert und danach erneut zur Anforderung zusätzlicher Ressourcen (gehostet auf derselben Site, ohne besondere Regeln für Unterordner). Ich werde wiederholt dazu aufgefordert, bis ich auf „Abbrechen“ klicke. An diesem Punkt wird im Netzwerkprotokoll von Chrome eine 401-Fehlermeldung für die Anforderung der Ressource angezeigt.
Eine der Ressourcen, bei denen dieses Problem auftritt, ist eine GET-Anforderung für favicon.png. Wenn ich direkt auf die Ressource zugreife (https://mysite.example.com/favicon.png) funktioniert alles, aber wenn ich auf die Seite der Site zugreife und eine Anforderung für diese Ressource durch den Browser als Teil der Ressourcen der Seite sende, wird mir der Fehler angezeigt. Dies bedeutet, dass auf die Ressource zugegriffen werden kann; aber etwas an der Art und Weise, wie sie innerhalb der „Transaktion“ gehandhabt wird, verursacht Probleme.
Ich habe es mit verschiedenen Browsern versucht, darunter mit einer Neuinstallation/von einem anderen Client-Gerät, um sicherzustellen, dass nichts zwischengespeichert ist, was Probleme verursacht. Zusätzlich habe ich Disable Cachedie F12-Netzwerkeinstellungen überprüft, um sicherzustellen, dass ich vollständige Anfragen/faire Vergleiche zwischen den beiden Sites durchführe.
Der Backend-Pool hat nur 1 Knoten. Die Backend-Einstellungen besagen, dass der Hostname des Backend-Pools anstelle des Hostnamens des Frontends verwendet werden soll. Aus Sicht des Webservers sehen die Anforderungen also ähnlich aus.
Im Sicherheitsereignisprotokoll des Webservers werden mir fehlgeschlagene Anmeldungen (Ereignis-ID 4625) mit meinem Testbenutzernamen angezeigt. Dies bestätigt, dass die Anforderung mit dem richtigen Benutzernamen an den Backend-Server gesendet wird (und ich habe sehr sorgfältig darauf geachtet, immer das richtige Kennwort einzugeben / habe dies viele Male getan, um die Möglichkeit menschlicher Fehler auszuschließen / habe versucht, das gespeicherte Kennwort sowohl zu verwenden als auch zu überschreiben). Wenn ich es zu oft versuche, wird mein Testkonto gesperrt (d. h. in AD lockedoutwird das Attribut auf gesetzt true); danach erhalten alle Anforderungen 401-Antworten (verständlicherweise).
Ich habe die App Gateway-Protokolle überprüft, um zu bestätigen, dass nichts blockiert wird. Ich habe auch eine benutzerdefinierte WAF-Regel für diese Site eingerichtet und sie auf den detection onlyModus eingestellt, um sicherzustellen, dass sie keine Anfragen blockieren kann; nur für den Fall, dass etwas blockiert, aber nicht protokolliert wird.
Ich habe die Ablaufverfolgung fehlgeschlagener Anfragen für den Status 401 auf dem Backend-Server aktiviert. Daraus wird ersichtlich, dass der 401-Fehler von folgendem Server kommt:
-MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName: IIS Web Core
Notification: AUTHENTICATE_REQUEST
HttpStatus: 401
HttpReason: Unauthorized
HttpSubStatus: 2
ErrorCode: Access is denied. (0x80070005)
ConfigExceptionInfo
Hinweis: Die Ressourcen, die blockiert werden (d. h. 401-Antworten erhalten), sind im Allgemeinen konsistent, wenn ich innerhalb eines bestimmten Zeitraums auf demselben Gerät teste. Wenn ich jedoch an einem anderen Tag oder auf einem anderen Gerät teste, werden möglicherweise andere Ressourcen blockiert. Wenn ich zum ersten Mal auf einem Gerät teste (meistens), sehe ich, dass zwei XHR- POSTAnfragen an /subfolder###/SearchSeiten fehlschlagen. Nach einigen Tests auf diesem Gerät scheinen dann andere Ressourcen beeinträchtigt zu sein. Dies scheint die Hauptursache zu sein – aber dann verursacht etwas ein Problem mit der Sitzung.
Ich versuche, Zugriff auf den Quellcode der Backend-Site zu erhalten, um besser zu verstehen, was in diesen Suchendpunkten codiert ist, um festzustellen, ob dies das Problem verursachen könnte.
In der Zwischenzeit sind alle Ideen, die jemand hier hat, sehr willkommen. Vielen Dank im Voraus.
Update: Der direkte Aufruf des Suchendpunkts führt ebenfalls zu einer HTTP 200 / gültigen Antwort:
$resp = Invoke-RestMethod -Method Post -Uri 'https://mySite.example.com/subfolder###/Search' -Form @{recordsToTake=25;recordsToSkip=0;sortColumn='CategorieName';sortDirection='Ascending'} -Credential $cred -StatusCodeVariable sc;"Status $sc";$resp
Antwort1
NTLM ("Windows-Authentifizierung") wird vom App Gateway nicht unterstützt (MS-Dokumente).
Es scheint, dass Reverse-Proxys im Allgemeinen aus Sicherheitsgründen keine NTLM-Unterstützung implementieren (MS YARP NTML Diskussion).
Es gibt einige alternative Reverse-Proxys, die damit umgehen können; zBnginx plus(das kommerzielle Nginx-Angebot).