Une application Web IIS 7.5 avec authentification Windows nécessite-t-elle que les utilisateurs finaux disposent d'autorisations sur les fichiers?

Question

Version courte:

Pour IIS 7.5 applications Web avec authentification Windows, l'utilisateur final doit-il avoir accès aux fichiers en lecture?

Version longue:

J'ai une application Web intranet ASP.NET qui utilise l'authentification Windows. Il est installé dans des dizaines d'entreprises différentes et normalement l'authentification fonctionne bien: les utilisateurs naviguent sur le site, par exemple http://appserver/MyApp, l'application reconnaît qui est connecté et affiche les pages en conséquence. Je viens de l'installer sur un nouveau client et j'ai rencontré un problème:

Lors de la connexion, par exemple à http://appserver/MyApp Je suis invité à entrer des informations d'identification Windows, mais après les avoir saisies, je suis invité à plusieurs reprises. Après plusieurs saisies d'informations d'identification, une page d'erreur 401 s'affiche, indiquant "401 - Non autorisé: l'accès est refusé en raison d'informations d'identification non valides". Donc, non seulement il ne passe pas par mon identité, mais même en entrant le nom d'utilisateur et le mot de passe, il refuse toujours l'accès.

Donner des autorisations de lecture et d'exécution aux utilisateurs finaux de l'application résout ce problème , mais je ne pense pas que cela devrait être nécessaire du tout.

Dans le journal des événements d'application Windows, il y a un message "Échec de l'autorisation de fichier pour la demande" avec le nom du compte Thread: NT AUTHORITY\NETWORK SERVICE et l'utilisateur: [le compte de domaine des utilisateurs du poste de travail correct]. Cela suggère que l'accès au fichier est effectué avec l'identité de l'utilisateur, et non l'identité AppPool du service réseau. Effectivement, si j'accorde à l'utilisateur final l'autorisation de lecture et d'exécution (je n'ai pas essayé la lecture uniquement) sur le répertoire de l'application, alors tout fonctionne correctement: lorsque l'utilisateur accède au site, il est authentifié automatiquement, sans invite et sur le site Web reconnaît correctement leur identité! Par conséquent, ma solution de contournement consiste à donner l'autorisation de lecture et d'exécution à tout le monde sur le répertoire de l'application ... mais ce n'est pas une solution idéale.

Cela semble très étrange. Je n'ai jamais eu besoin de le faire auparavant en IIS 7.5, pour autant que je m'en souvienne, et je n'en ai certainement jamais eu besoin en IIS 6 ou IIS 7. Est-ce une nouvelle chose IIS7.5? La documentation indique que l'emprunt d'identité est désactivé par défaut. J'ai ajouté un élément au web.config pour être sûr, supprimé les autorisations de fichiers autres que le service réseau, mais le problème est resté.

Des pensées? Est-il normal que les sites Windows authentifiés sur IIS 7.5 pour les utilisateurs finaux aient besoin d'autorisations de fichiers sur les fichiers du serveur Web?

Quelques détails pertinents:

• Le service réseau dispose d'autorisations de fichier de contrôle total sur le dossier de l'application.
• Lors de la connexion à partir du serveur lui-même, j'ai été invité à fournir des informations d'identification, mais après les avoir saisies, je suis authentifié et l'application fonctionne correctement, notamment l'affichage de ma connexion Windows et la connexion et la récupération des données de la base de données. J'ai par la suite déterminé qu'il demandait des informations d'identification car http://localhost se trouvait dans les sites de confiance et n'était donc pas reconnu comme la zone intranet et ne passait donc pas d'identité. J'ai également déterminé que cela fonctionnait en tant qu'identité d'utilisateur, car il s'agit d'un utilisateur administrateur qui dispose d'autorisations de fichier.
• Le serveur Web exécute Windows Server 2008 R2/IIS 7.5. Il n'y avait pas IIS dessus) tant que je ne l'ai pas installé. J'ai installé les fonctionnalités par défaut comme ainsi que l'authentification Windows, ASP.NET et peut-être quelques autres éléments. Une application WCF distincte que j'ai installée qui utilise IIS, l'authentification anonyme et .net 2.0 fonctionne bien sur ce serveur Web.
• Le processus d'installation de l'application est une copie manuelle des fichiers, la création de IIS Pools d'applications et d'applications Web, la mise à jour des chaînes de connexion, etc.
• J'ai vérifié les paramètres de sécurité IE. Il reconnaissait le serveur comme dans la zone Intranet et avait l'option 'Connexion automatique uniquement dans la zone Intranet' sélectionnée. Également sur Paramètres avancés 'Activer l'authentification Windows intégrée 'option a été cochée.
• Après avoir installé IIS j'ai exécuté aspnet_regiis -i pour .net 2.0 et aspnet_regiis -iru pour .net 4.0.
• L'authentification anonyme est désactivée pour mon application et l'authentification Windows activée.
• L'application s'exécute sur ASP.NET v4 mais il y a une autre application que j'ai installée rencontrant le même problème en exécutant ASP.NET v2.
• L'application fonctionne avec Identity = Network Service et en mode 32 bits.
• La chaîne de connexion à la base de données comprend Trusted Connection=True et les autorisations de base de données sont accordées au compte du serveur Web [domain]\[server]$ par exemple. DGM\MyServer$.
• Dans IIS> Authentification> Authentification Windows> Fournisseurs, la liste était Négocier d'abord puis NTLM. J'ai essayé de réorganiser afin que NTLM soit le premier.
• Dans le journal des événements de sécurité Windows, il y avait une série d'événements d'audit de sécurité Microsoft Windows: ouverture et fermeture de session. Ils ont indiqué que la connexion avait réussi et affichait l'ID utilisateur de l'utilisateur du poste de travail. Cela vient de quand je me connecte depuis un autre poste de travail et que je reçois un 401 non autorisé après plusieurs tentatives.

Je vois que quelqu'un a eu ce problème signalé ici mais sans solution. À l'origine, j'ai posté sur les forums ASP puis sur les forums IIS sans réponse jusqu'à présent .

Mise à jour: Cet article msdn dit

Lorsque l'authentification Windows est activée mais que l'emprunt d'identité est désactivé, ASP.NET effectue des vérifications d'accès aux fichiers dans le module autorisation de fichier à l'aide des informations d'identification envoyées par le navigateur (c'est moi qui souligne). L'emprunt d'identité n'a pas besoin d'être activé, car le module FileAuthorizationModule garantit que l'utilisateur demandeur est autorisé à accéder en lecture ou en écriture à la ressource, selon le verbe de la demande (par exemple, GET ou POST) avant d'exécuter la demande. Ce comportement s'applique à toutes les demandes qui entrent du code managé. Dans les versions antérieures d'ASP.NET, l'accès aux fichiers basés sur des URI tels que "Default.aspx" a déclenché la vérification d'accès. Dans les applications ASP.NET MVC, où l'accès aux ressources est généralement effectué à l'aide d'URL sans extension, cette vérification ne s'applique généralement pas, car il n'y a pas de fichier physique à vérifier. Dans ce cas, la classe FileAuthorizationModule revient à la vérification des listes de contrôle d'accès (ACL) pour le dossier.

Cela suggère que l'utilisateur final a besoin d'autorisations sur les fichiers (dans le cas de .aspx) ou le dossier (pour MVC) ... bien que cela semble toujours légèrement caché et non définitif. Cet article sur les pools d'applications indique qu'ils sont utilisés comme identité pour sécuriser les ressources, ce qui contredit l'idée de devoir accorder des privilèges aux utilisateurs finaux. À moins que les règles ne soient différentes pour les pools d'applications et le SERVICE RÉSEAU, ce qui pourrait être le cas mais serait surprenant.

Answer 1

La réponse courte est non. Vous n'êtes pas obligé d'accorder des autorisations d'accès aux fichiers lorsque vous utilisez l'authentification Windows dans IIS 7.0 et IIS 7.5.

Nous n'avons pu le découvrir que parce que notre administrateur de serveur a senti les problèmes de sécurité et de gestion qui découlent de la décision d'accorder un accès de niveau fichier aux utilisateurs et aux groupes.

Pour toute personne confrontée à ce problème ou si vous configurez un nouveau serveur IIS7/IIS7.5 et/ou que vous passez de IIS 6, voici un article qui vous donne toutes les options d'authentification Windows et les configurations qui doivent être modifiées pour éviter d'accorder un accès de niveau fichier à des individus ou à des groupes.

Veuillez lire les deux commentaires à la fin du POST pour des critiques valides des méthodes utilisées dans cet article.

http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk

En plus des informations contenues dans l'article, sachez que IIS 7.5 n'utilise pas les balises de configuration Web pour system.web (du moins pas dans mon application MVC 4).

Il recherche dans les balises system.webserver la configuration des autorisations (où vous devrez répertorier le domaine\groupes Windows dans lequel un utilisateur doit se trouver pour accéder à votre application).

- DSB

Answer 2

Les utilisateurs authentifiés sont-ils autorisés à accéder au dossier de l'application?

Answer 3

Nous nous battions également contre ce problème et avons commencé à configurer des groupes de sécurité afin de donner à nos utilisateurs des autorisations de niveau fichier. Ensuite, l'un de nos administrateurs de serveur est tombé sur quelques nouvelles propriétés qui permettent à l'application de s'authentifier auprès du système de fichiers sous des informations d'identification définies, et a résolu le besoin pour les utilisateurs d'avoir accès. Voici ce qu'il a trouvé…

Il existe deux paramètres IIS qui contrôlent cela:

Informations d'identification du chemin d'accès physique Informations d'identification du chemin d'accès physique Type de connexion

Par défaut, les informations d'identification du chemin physique sont définies sur Utilisateur de l'application (authentification unique). Cela signifie que IIS ne fait aucune usurpation d'identité lors du traitement des demandes d'authentification Windows. Cela peut toutefois être défini pour un utilisateur spécifique (mais pas, malheureusement, l'identité du pool d'applications, qui serait Idéal). Le type de connexion des informations d'identification du chemin physique est défini par défaut sur Texte clair. Pour mes tests, je l'ai défini sur Interactif (bien que ce ne soit pas la valeur correcte). Les valeurs possibles sont Texte clair, Lot, Interactif et Réseau.

Pour configurer cela, j'ai fait ce qui suit:

1. Création d'un compte local (IIS-AccessUser)
2. Accordé à IIS-AccessUser l'accès en lecture et en exécution au répertoire/home du site.
3. Ajout d'IIS-AccessUser au groupe IIS_IUSRS (nécessaire pour accéder aux fichiers temporaires .NET)
4. Définissez IIS-AccessUser comme informations d'identification du chemin physique
5. Définir le type de connexion des informations d'identification du chemin physique sur Interactif

Faire ce qui précède m'a permis de me connecter directement à l'application, sans avoir à autoriser les utilisateurs authentifiés, ni à être membre d'un des groupes du dossier/home. Il a également conservé les rôles d'autorisation .NET, donc je ne pouvais toujours pas accéder aux parties du site auxquelles je n'étais pas autorisé.