créer une publication http à partir du serveur à l'aide des informations d'identification de l'utilisateur - sécurité intégrée
-
20-08-2019 - |
Question
J'essaie de publier un message, à partir d'une page asp classique côté serveur, à l'aide des informations d'identification de l'utilisateur ...
J'utilise msxml2.ServerXMLHTTP pour programmer le post par programme
J'ai essayé plusieurs configurations sur le site IIS 5.1, mais je ne parviens pas à faire fonctionner IIS avec un compte spécifié ...
J'ai créé une petite page asp qui exécute whoami pour vérifier le compte utilisé par le processus iis ...
avec IIS 5.1, en utilisant la sécurité intégrée, le processus utilise:
ma_machine \ IWAM_my_machine
Je désactive la sécurité intégrée et laisse un compte de domaine sous forme d'accès anonyme. Je reçois le même résultat (& # 191;?)
pour tester l'utilisateur, je fais ce qui suit
private function whoami()
dim shell, cmd
set shell = createObject("wscript.shell")
set cmd = shell.exec( server.mapPath( "whoami.exe" ) )
whoami = cmd.stdOut.readAll()
set shell = nothing: set cmd = nothing
end function
est-ce parce que j'émets une commande shell?
Je souhaite passer des appels http à un autre site fonctionnant avec la sécurité intégrée ...
J'ai donc besoin d'un moyen de transmettre les informations d'identification, ou au moins de m'exécuter avec un compte spécifique, puis de configurer le site distant pour qu'il mette ce compte en place ...
Je pensais qu'il suffirait de configurer le site pour qu'il fonctionne avec la sécurité intégrée ...
Comment puis-je réaliser une telle chose?
ps: avec IIS6, se passe la même chose mais si je change la configuration de la piscine, je reçois les informations suivantes de whoami
NT AUTHORITY \ NETWORK SERVICE
AUTORITÉ NT \ SERVICE LOCAL
NT AUTHORITY \ SYSTEM
si je crée un compte de domaine, je reçois un & service non disponible &>; message ...
modifier: trouvé ceci
il dit ce que j'ai supossé, & "Si un utilisateur authentifié fait une demande, le jeton de thread est basé sur le compte authentifié de l'utilisateur &"; que ... qu'est-ce que je pourrais éventuellement manquer?
modifier:
eh bien la chose whoami me trompe évidemment, j'ai essayé avec la fonction suivante
private function whoami_db( serverName, dbName )
dim conn, data
set conn = server.createObject("adodb.connection")
conn.open "Provider=SQLOLEDB.1;Integrated Security=SSPI;" & _
"Initial Catalog=" & dbName & ";Data Source=" & serverName
set data = conn.execute( "select suser_sname() as user_name" )
whoami_db = data("user_name")
data.close: conn.close
set data = nothing: set conn = nothing
fonction de fin
et tout semblait bien fonctionner ...
mais comment puis-je faire en sorte que msxml2.ServerXMLHTTP fonctionne avec les informations d'identification de l'utilisateur ???
La solution
Vous avez raison, whoami.exe vous a dérouté. Le lancement d'un processus séparé a entraîné l'exécution du nouveau processus en tant qu'utilisateur du processus actuel. Sous XP, il s’agit de l’hôte d’application COM + (DLLHOST) et s’exécute normalement en tant que IWAM_<machine>
. Sous IIS6, le processus de travail w3wp.exe s'exécute généralement sous le nom NT AUTHORITY \ Network Service.
Cependant, un thread traitant une requête HTTP empruntera l'identité d'un autre jeton de sécurité. Avec la sécurité intégrée telle que vous l'avez découverte, ce serait le jeton de sécurité de l'utilisateur à l'origine de la demande, comme le prouve votre expérience SSPI. Avec un accès anonyme, l’utilisateur anonyme configuré sur le site / l’application est utilisé (il s’agit généralement de <MACHINE>\IUSR_<machine>
.
En ce qui concerne votre problème spécifique avec ServerXMLHTTP, cela revient au composant sous-jacent WinHTTP. Par défaut, cela n’enverra les informations d’identification des utilisateurs actuels que si le serveur auquel on accède est la liste de contournement du proxy. Même dans ce cas, ServerXMLHTTP peut le configurer pour ne jamais envoyer les informations d'identification de l'utilisateur. Je n'ai pas testé ce scénario moi-même.
Malheureusement, ServerXMLHTTP fournit un accès très limité aux détails de la configuration sur WinHTTP. Cependant, s'il s'agit d'un show stopper, vous pouvez toujours utiliser le composant WinHTTP directement vous-même: -
Dim oWinHTTP
Dim oDOM
Const AutoLogonPolicy_Always = 0
Set oWinHTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
oWinHTTP.SetAutoLogonPolicy AutoLogonPolicy_Always
oWinHTTP.Open "GET", "http://remoteserver.org/getsomexml.xxx", False
oWinHTTP.Send
If oWinHTTP.Status = 200 Then
Set oDOM = CreateObject("MSXML2.DOMDocument.3.0")
oDOM.async = false
oDOM.Load oWinHTTP.ResponseStream
End If
Set oWinHTTP = Nothing
Cela devrait fonctionner pour http, pour https, cela devient vraiment compliqué.