Quel compte utilise ASP (classique) lorsqu'une authentification Windows intégrée est activée ?

Classic ASP s'exécute en se faisant passer pour l'utilisateur authentifié sur le serveur dans la session HTTP. Vous devez accorder aux utilisateurs qui s'authentifient l'autorisation d'exécuter l'application classic ASP ou autoriser l'accès anonyme.

Si vous avez déjà essayé avec "Utilisateurs authentifiés" et que cela ne fonctionne pas, je dirais que vous n'avez pas de problème de permission de fichier.

Que voulez-vous dire lorsque vous dites "...le fichier ASP essaie d'invoquer le webservice..."? Voulez-vous dire que le script ASP fait une requête HTTP vers le serveur? Si c'est le cas, les informations d'identification de l'utilisateur ne seront pas transmises dans cette requête car "l'authentification Windows intégrée" ne donne pas au serveur de mot de passe en texte clair à utiliser lors de l'authentification auprès d'autres serveurs (ou lui-même).

Modifier :

D'après votre commentaire, alors, comme indiqué ci-dessus, le serveur n'aura pas d'informations d'identification avec lesquelles authentifier l'utilisateur car l'authentification Windows intégrée ne donne pas de mot de passe en texte clair à transmettre à d'autres serveurs (ou lui-même, qui est un autre serveur dans ce cas).

Vous pourriez essayer trois choses :

• Si vous pouvez permettre l'accès anonyme à WebService.asmx, votre appel HTTP serveur-vers-serveur devrait fonctionner (vous devrez explicitement permettre l'accès anonyme en autorisant IUSR_xxx à lire le fichier et en modifiant le paramètre "Contrôle d'accès et d'authentification anonymes" pour "Accès anonyme" sur le fichier lui-même via la console de gestion IIS puisque ce fichier héritera des paramètres activés "Authentification Windows intégrée" et désactivés "Accès anonyme" du répertoire dans lequel il se trouve).

• Si le contrôle que vous utilisez pour la requête HTTP prend en charge la fourniture transparente des informations d'identification de l'utilisateur connecté au serveur distant, vous pourriez activer l'authentification de base sur le script classic ASP (ce qui donne effectivement au serveur un mot de passe en texte clair à transmettre à d'autres serveurs) afin que votre contrôle de requête HTTP puisse transmettre ce mot de passe en clair lors de la requête pour WebService.asmx. Vous devrez alors exiger SSL pour l'accès au script classic ASP, à ce moment-là, pour éviter de transmettre des mots de passe en clair sur le réseau.

• Enfin, vous pourriez simplement codé en dur des informations d'identification de base dans le script classic ASP et activer l'authentification de base sur le fichier WebService.asmx. Cela signifie que WebService.asmx verra toujours un accès du même utilisateur.

Aucune de ces solutions n'est très élégante. Vous rencontrez un problème "classique" que nous avons rencontré avec "classic ASP" lorsque nous essayons de nous authentifier à un niveau backend (base de données, etc) en tant que l'utilisateur qui s'est authentifié pour exécuter le script classic ASP.