créer une publication http à partir du serveur à l'aide des informations d'identification de l'utilisateur - sécurité intégrée

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

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/275269ee-1b9f-4869-8d72-c9006b5bd659.mspx?mfr=true

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

Answer 1

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é.