Classic ASP Request.ServerVariables ("LOGON_USER") gibt falschen Benutzernamen zurück

Question

Classic ASP Request.ServerVariables ("LOGON_USER") gibt falschen Benutzernamen zurück. Hier ist das Szenario:

Ich habe zwei Konten auf der Domäne, eine für die Verwaltung und eine für den normalen Gebrauch. Das Administratorkonto wird als Administrator (in der Gruppe Administratoren) auf dem Server festgelegt, auf dem das ASP-Skript ausgeführt wird. Server ist Windows 2003 mit IIS 6.0.

Ich melde mich mit meinem normalen Benutzerkonto bei meinem Rechner an und gehe auf die Seite und er gibt den Benutzernamen meines Administratorkontos zurück. Warum passiert dies ? Das funktioniert gut für andere.

<% 
Response.Write "LOGON_USER: " & Request.ServerVariables("LOGON_USER") & "<br>" 
Response.Write "REMOTE_USER: " & Request.ServerVariables("REMOTE_USER") & "<br>" 
Response.Write "AUTH_USER: " & Request.ServerVariables("AUTH_USER") & "<br>" 
Response.Write "<br>" 
'Show all server variables 
For Each Item In Request.ServerVariables 
Response.Write Item & " = " & Request.ServerVariables(Item) & "<br>" 
Next 
%> 

Der anonyme Zugriff ist deaktiviert und die Windows-Authentifizierung ist aktiviert.

Danke,

Jari

Answer 1

Grundlegendes Problem ist wahrscheinlich die Tatsache, dass ich $ Freigabe für den gleichen Server mit dem Benutzernamen admin geöffnet habe, während Asp-Sitzungen auf dem gleichen Server mit IE mit dem normalen Benutzer.

Das Zurücksetzen des Benutzers auf den normalen Benutzer erfolgt über die Systemsteuerung -> Benutzerkonten -> Kennwörter verwalten -> Wählen Sie den gewünschten Server aus und ändern Sie den Benutzernamen in den richtigen Namen. Sie müssen kein Passwort eingeben. Ok, Schließen und Abbrechen. Möglicherweise müssen Sie einen neuen IE öffnen, damit die Änderung wirksam wird.

Dies muss jedes Mal ausgeführt werden, wenn der Benutzer "hinter die Kulissen" wechselt.

Answer 2

Das IIS ist wahrscheinlich unter dem Benutzer Admin ausgeführt und so werden Sie diesen Namen bekommen. Bitte überprüfen Sie es an Ihrer Seite.

Answer 3

Nach der MSDN-Dokumentation zu diesen Variablen:

Die Windows-Konto, dass der Benutzer während der Verbindung mit dem Webserver imitiert. Verwenden Sie REMOTE_USER, UNMAPPED_REMOTE_USER oder AUTH_USER, um den rohen Benutzernamen anzuzeigen, der im Anforderungsheader enthalten ist. Die einzige Zeit, in der LOGON_USER einen anderen Wert als diese anderen Variablen enthält, ist, wenn Sie einen Authentifizierungsfilter installiert haben.

Vielleicht haben Sie einen Authentifizierungsfilter.

Answer 4

Ich kann nicht erklären, was Sie auf der Grundlage der bisher gelieferten Informationen sehen. Ich kann Ihnen sagen, dass das Konto, unter dem der App-Pool läuft, nicht veraltet ist.

Klassisches ASP imitiert immer einen Benutzer entweder das anonyme Benutzerkonto oder der Benutzer, der mit der Verbindung verknüpft ist, auf der die Anforderung ankommt. Darin kann der Schlüssel zu Ihrem Problem liegen.

Authentifizierung in ASP wird auf der Verbindungsebene behandelt, sobald eine Verbindung authentifiziert wurde, ist sie einem Benutzer zugeordnet. Eine Verbindung kann von Clients und anderen nachgeschalteten HTTP-Geräten offengehalten werden. Alle nachfolgenden Anforderungen, die bei der Verbindung eintreffen, müssen nicht erneut authentifiziert werden. Der aktuelle Benutzer, der der Verbindung zugeordnet ist, wird verwendet, um den Benutzerkontext bereitzustellen, den der Thread, der die Anforderung verarbeitet, verfälscht.

Ich habe gesehen, dass intermediäre Geräte oder Debugging-Proxys (wie Fiddler) Verbindungen aufrechterhalten und sie für nachfolgende Anfragen von einer Vielzahl von Clients wiederverwenden. In dieser Situation ist es möglich, dass ein Client in einem Benutzerkontext ausgeführt wird, damit eine Anforderung vom Webserver unter einem anderen Benutzerkontext verarbeitet wird. Böse!

Ich habe die gleiche Sache auf älteren Citrix Terminalservern gesehen. HTTP-Verbindungen wurden von mehreren Clients geteilt, die auf dem Terminalserver ausgeführt wurden, was zu einem Cross-Over des Sicherheitskontextes führte. Autsch!

Eine andere Variante ist, dass der Zugriff einer Ressource auf einem Server für den aktuellen Benutzer im Intranet abgelehnt wird. Der Browser zeigt einen Net-Anmeldedialog an und der Benutzer gibt einen Admin-Benutzer ein. Für die Dauer der Sitzung verwendet der Browser jetzt die Anmeldedaten des Admin-Benutzers, um auf andere Ressourcen auf demselben Server zuzugreifen, obwohl der aktuell angemeldete Benutzer dies tun würde.