2010-02-24 4 views
9

ASP classique Request.ServerVariables ("LOGON_USER") renvoie un nom d'utilisateur incorrect. Voici le scénario:ASP classique Request.ServerVariables ("LOGON_USER") renvoyant un nom d'utilisateur incorrect

J'ai deux comptes sur le domaine, un pour l'administration et un pour l'utilisation normale. Le compte admin est défini comme admin (dans le groupe Administrateurs) sur le serveur sur lequel le script ASP est exécuté. Le serveur est Windows 2003 exécutant IIS 6.0. Je me connecte à mon ordinateur avec mon compte d'utilisateur normal et j'accède à la page qui renvoie mon nom d'utilisateur de compte administrateur. Pourquoi cela arrive-t-il ? Cela fonctionne bien pour les autres.

<% 
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 
%> 

L'accès anonyme est désactivé et l'authentification Windows est activée.

Merci,

Jari

+2

À quel compte le pool d'applications IIS s'exécute-t-il? – Kane

+0

Est-ce que AUTH_USER dit la même chose? L'accès anonyme est-il activé? Si oui, quel compte est configuré pour l'utilisateur anonyme? – AnthonyWJones

+0

Il fonctionne sous le compte système – Jari

Répondre

5

Le problème sous-jacent est probablement le fait que j'ai $ share ouvert sur le même serveur avec le nom d'utilisateur admin tout en ayant des sessions ASP sur le même serveur avec IE avec l'utilisateur normal.

Vous pouvez revenir à l'utilisateur normal à partir du Panneau de configuration -> Comptes d'utilisateurs -> Gérer vos mots de passe -> Sélectionnez le serveur en question et remplacez le nom d'utilisateur par le bon. Pas besoin d'entrer un mot de passe. Ok, fermez et annulez. Vous devrez peut-être ouvrir un nouvel IE pour que la modification prenne effet.

Ceci doit être fait chaque fois que l'utilisateur change de «coulisses».

+0

Quelle version du serveur utilisez-vous car cela ne correspond pas aux écrans que je vois et je souffre du même problème – pee2pee

+0

Si vous avez coché "souvenez-moi" sur le mappage du lecteur réseau inital, alors même après la déconnexion, le les informations d'identification sont stockées dans cet emplacement. – svandragt

0

IIS est probablement en cours d'exécution sous l'utilisateur Admin et ainsi vous obtiennent ce nom. Veuillez le vérifier à vos côtés.

+0

Il fonctionne sous le compte système – Jari

1

Selon la documentation MSDN sur cette variable:

Le compte Windows que l'utilisateur emprunte l'identité lorsqu'il est connecté à votre serveur Web. Utilisez REMOTE_USER, UNMAPPED_REMOTE_USER ou AUTH_USER pour afficher le nom d'utilisateur brut contenu dans l'en-tête de la demande. La seule fois où LOGON_USER contient une valeur différente de ces autres variables est si un filtre d'authentification est installé.

Peut-être avez-vous un filtre d'authentification.

+0

Si le filtre d'authentification signifie le filtre ISAPI, aucun n'est installé. – Jari

2

Je ne peux pas expliquer ce que vous voyez sur la base des informations fournies jusqu'à présent. Je peux vous dire que le compte sous lequel App Pool est en cours d'exécution est irrelevent.

ASP classique usurpe toujours l'identité d'un utilisateur, soit le compte d'utilisateur anonyme, soit l'utilisateur associé à la connexion à laquelle la requête parvient. Là peut être l'indice de votre problème.

L'authentification dans ASP est gérée au niveau de la connexion, une fois qu'une connexion a été authentifiée, elle est associée à un utilisateur. Une connexion peut être maintenue ouverte par les clients et autres périphériques HTTP en aval. Toutes les demandes suivantes arrivant sur la connexion n'auront pas besoin d'être ré-authentifiées, l'utilisateur actuel associé à la connexion est utilisé pour fournir le contexte utilisateur que le thread traitant la requête emprunte l'identité. J'ai vu des périphériques intermédaires ou des proxys de débogage (tels que fiddler) maintenir des connexions et les réutiliser pour une demande ultérieure d'une variété de clients. Dans cette situation, il est possible d'avoir un client s'exécutant dans un contexte utilisateur pour qu'une requête soit traitée par le serveur Web dans le contexte d'un utilisateur différent. Méchant! J'ai vu le même genre de chose sur des serveurs Citrix Terminal plus anciens. Les connexions HTTP ont été partagées par plusieurs clients s'exécutant sur le serveur Terminal Server, ce qui a entraîné le croisement du contexte de sécurité. Aie! Une autre variante pour cela est où l'accès d'une ressource sur un serveur est rejeté pour l'utilisateur actuel sur l'intranet. Le navigateur affiche une boîte de dialogue Net Logon et l'utilisateur entre un utilisateur Admin. Pendant la durée de la session, le navigateur utilise désormais les informations d'identification de connexion de l'utilisateur Admin pour accéder à d'autres ressources sur ce même serveur, même si l'utilisateur connecté actuel le ferait.