Usurpation d'identité dans IIS 7.0

Question

J'ai un site web qui fonctionne correctement sous IIS 6.0 :Il authentifie les utilisateurs avec les informations d'identification Windows, puis lorsqu'il parle au service qui accède à la base de données, il transmet les informations d'identification.

Dans IIS 7.0, les mêmes paramètres de configuration ne transmettent pas les informations d'identification et la base de données est touchée par NT AUTHORITY\ANONYMOUS.

Y a-t-il quelque chose qui me manque ?J'ai désactivé l'accès ANONYME sur mon site Web IIS 7.0, mais je n'arrive pas à faire fonctionner l'appareil.

Voici les paramètres que j'utilise sur IIS 6.0 et 7.0 :

<authentication mode="Windows">
<identity impersonate="true">

Qu'est-ce qui a changé entre la version 6.0 et la version 7.0 ?

Answer 1

Des changements ont été apportés entre IIS7 et IIS6.0.J'ai trouvé pour vous un article de blog qui pourrait réellement vous aider (Cliquez ici pour le voir).

Exécutez-vous votre application en mode intégré ou en mode classique ?D'après ce que j'ai vu, mettre l'attribut Impersonate à true devrait vous afficher une erreur 500 avec le message d'erreur suivant :

Erreur interne du serveur.Il s'agit d'une erreur HTTP 500.19:La page demandée ne peut pas être consultée car les données de configuration connexes pour la page ne sont pas valides.

Voici la solution de contournement qui est proposée :

Solution de contournement:

1) Si votre application ne s'appuie pas sur l'identité de l'utilisateur demandeur dans les étapes BeginRequest et AuthenticateRequest (les seules étapes où l'identité n'est pas possible en mode intégré), ignorez cette erreur en ajoutant ce qui suit à Web.Config de votre application:

<validation validateIntegratedModeConfiguration="false"

/>

2) Si votre application s'appuie sur une usurpation d'identité dans BeginRequest et AuthenticateRequest, ou si vous n'êtes pas sûr, passez en mode classique.

J'espérais que cela serait utile pour comprendre comment fonctionne désormais IIS 7.0.

Answer 2

Votre serveur IIS est-il configuré pour être approuvé pour la délégation par SQLServer ?J'ai déjà rencontré ce problème avec WebDAV, où nous devions faire en sorte que le serveur exécutant IIS soit approuvé par le serveur de fichiers pour s'authentifier au nom du serveur de fichiers.

Answer 3

Intéressant...J'ai le problème inverse - Ne pas être capable pour que l'authentification soit transmise depuis le navigateur client, via le serveur Web et sur la base de données au sein d'un grand réseau d'entreprise via des pare-feu.

Je pense également que l'authentification « de bout en bout de l'utilisateur » sur la base de données est une mauvaise idée et un risque potentiel pour la sécurité.Rien n'empêche l'utilisateur final de charger une requête SQL et de se connecter directement à votre base de données, vous feriez donc mieux de verrouiller votre schéma !

@Esteban - J'ai clarifié mon pas très utile pour t'aider répondre.

Answer 4

Généralement, si vous effectuez une authentification double saut comme celle-ci, Kerberos est généralement impliqué, sauf si la première authentification est de base.

Je vérifierais l'authentification sur les serveurs IIS 6 et m'assurerais qu'elle est la même sur IIS 7.

Si la case IIS 6 est définie sur Windows Integrated, vous devez alors vérifier les paramètres Kerberos - SPN, délégation, etc.