Problème d'autorisation avec le répertoire virtuel sur le chemin UNC

J'ai un répertoire virtuel sur mon site (environnement de test). Il s'agit d'un partage UNC qui est également utilisé comme FTP public.

Il est configuré pour se connecter en tant que compte d'administrateur de domaine et "Paramètres de test" indique que tout semble fonctionner. Cependant, lorsque j'essaie de me connecter, j'obtiens:

500 - "Impossible de démarrer la surveillance des modifications sur \ INTRANET \ FTP \ test \ web.config car l'accès a été refusé"

Il s'agit d'un ASP.NET YSOD. Je ne sais pas pourquoi ASP.NET s'implique du tout car c'est un fichier .jpg statique que je demande.

J'ai essayé d'activer le suivi des demandes ayant échoué et voici l'erreur spécifique:

• ModuleName WindowsAuthentication
• Notification 2
• HttpStatus 500
• Erreur du serveur interne HttpReason
• HttpSubStatus 0
• ErrorCode 0
• ConfigExceptionInfo
• Notification AUTHENTICATE_REQUEST
• ErrorCode L'opération s'est terminée avec succès. (0x0)

Si je change le "Type de connexion au chemin physique" de ClearText à Réseau. J'obtiens l'erreur IIS suivante:

Erreur HTTP 500.19 - Serveur interne

Erreur La page demandée n'est pas accessible car les données de configuration associées à la page ne sont pas valides.

Informations détaillées sur les erreurs

• Module IIS Web Core
• Notification BeginRequest
• Gestionnaire Pas encore déterminé
• Code d'erreur 0x80070005
• Erreur de configuration Impossible de lire le fichier de configuration en raison d'autorisations insuffisantes
• Fichier de configuration \\?\UNC\INTRANET\FTP\test\web.config

• URL demandée http://test.mydowmain.com:80/uploads/images/ca49acf6-6174-412e-8abd-59fab983e931.jpg

• Chemin physique \\INTRANET\FTP\test\images\ca49acf6-6174-412e-8abd-59fab983e931.jpg

• Méthode de connexion Pas encore déterminée

• Utilisateur de connexion Pas encore déterminé
• Répertoire des journaux de suivi des demandes ayant échoué C:\inetpub\logs\FailedReqLogFiles

Cela ne génère pas un journal des demandes ayant échoué de manière assez étrange: j'ai défini le suivi des demandes ayant échoué pour tracer les erreurs avec les codes d'erreur 400 à 999.

Il convient également de noter que si j'ouvre la fonctionnalité de configuration à partir d'IIS, je vois une erreur d'accès refusé.

J'ai exactement la même configuration sur ma machine de développement locale sur le même chemin UNC et le même utilisateur que cela fonctionne. Ce n'est pas le cas sur le serveur de test.

Qu'est-ce que je fais mal?

Le fait qu'il s'agisse d'une application ASP.net est probablement exactement le problème ici. Votre identité de pool d'applications doit avoir des droits (pas nécessairement l'identité IIS; par défaut, l'identité du pool d'applications est le compte de service réseau local.) Vous devez également probablement exécuter caspol.exe sur votre machine IIS.

http://msdn.microsoft.com/en-us/library/cb6t8dtz%28v=vs.80%29.aspx

http://learn.iis.net/page.aspx/50/aspnet-20-35-shared-hosting-configuration/

%windir%\Microsoft.NET\Framework\v2.0.50727\caspol -m -ag 1.  -url "file://\\remotefileserver\content$\*" FullTrust

J'ai résolu notre problème en créant des comptes correspondants sur le serveur Web et sur le serveur UNC. J'ai ensuite modifié le pool d'applications pour qu'il s'exécute à l'aide de ce compte correspondant et non du service réseau. Cela m'a donné la flexibilité de synchroniser le mot de passe sur les deux serveurs sans affecter les autres fonctions dépendantes du service réseau.

Si cette source partagée n'est pas une application (par exemple un dossier d'image), essayez de configurer le répertoire virtuel pour qu'il soit ignoré par l'application racine qui inclut le répertoire virtuel (dans mon cas, je l'ai terminé en modifiant le type de pool d'applications racine comme Classique au lieu du mode intégré). Mais s'il y a une application dans le point partagé, vous pouvez suivre la manière indiquée par @mfinni.

Vous pouvez vérifier que le compte sous lequel IIS est exécuté dispose des droits appropriés / nécessaires sur l'UNC gênant.

J'ai eu le même problème sur IIS 7.5, j'ai trouvé la solution:

1. Créer un utilisateur local sur le serveur avec le partage
2. Créez le partage réseau, en donnant à l'utilisateur créé à l'étape 1 les autorisations souhaitées. Windows configurera les autorisations pour l'utilisateur que vous avez spécifié
3. Accédez au répertoire virtuel sur IIS et ouvrez les "paramètres avancés"
4. Entrez l'URL dans le chemin d'accès physique pour le partage réseau comme \\<servername>\<sharename>
5. cliquez sur Identifiants du chemin physique; ajouter les informations d'identification pour l'utilisateur créé à l'étape 1

Je viens d'avoir le même problème avec un serveur Web n'appartenant pas au domaine qui accède à certaines ressources de domaine à l'aide d'un compte de domaine. Nous obtenions un comportement étrange (les «informations d'identification de test» échouaient même si nous savions que les informations d'identification étaient correctes, nous pouvions voir les dossiers et les fichiers dans l'affichage du contenu, mais nous ne pouvions pas les «parcourir»). La solution était de créer un utilisateur local sur la machine avec le même nom que l'utilisateur du domaine.

Je pense que c'est ce qui se serait passé si le serveur Web était membre du domaine, et l'utilisateur local était nécessaire pour accéder à certaines ressources locales (config?) Afin de mapper le virtuel.

J'espère que cela aide quelqu'un.