ApplicationPoolIdentity utilisateur ne peut pas modifier les fichiers dans le dossier partagé dans Windows Server 2008

Je suis de la création des répertoires, et l'écriture de fichiers dans un dossier partagé dans mon application web qui est hébergé sur un Serveur Windows server 2008. Je suis en cours d'exécution de l'application de la piscine avec une identité ApplicationPoolIdentity.

Pour vous donner une idée de mon installation jusqu'à présent.. j'ai mis des autorisations à la racine de mon application web de répertoire racine pour deux utilisateurs différents: "IUSR" et "IIS APPPOOL\MYPOOL". Je suis en utilisant le nom de "MYPOOL" comme le nom de mon pool d'applications, de sorte qu'il est facile de référence.

L'application est impossible de la modifier et de les écrire dans un dossier partagé. J'ai bien cliqué sur le dossier partagé que je suis la création de répertoires et de l'écriture, et cliqué sur l'onglet "Sécurité". Puis j'ai cliqué sur "Modifier". Sous objets, j'ai coché "Ordinateur". Puis, sous l'EMPLACEMENT, j'ai essayé la machine/serveur qui exécute mon application web. Je n'ai pas pu trouver mon "MYPOOL" utilisateur, mais en vertu de l'utilisateur. J'ai essayé de suivre ce lien, mais il n'était pas très complet. Je ne sais pas qui de l'utilisateur à utiliser. - Je continuer à avoir un Système.IO exception car elle ne dispose pas d'autorisations. Une fois, je sais qui l'utilisateur à utiliser, je vais le donner à "Modifier" les autorisations pour le "ExportPath" répertoire.

http://grekai.wordpress.com/2011/05/23/permissions-for-shared-folder-for-iis-7-application-pool-identity-across-domain/

Pour un test rapide, j'ai fait une page factice appelé FilePermissionsTest.aspx, et de mettre un peu de code à écrire un fichier pour créer un répertoire et écrire un fichier dans mon événement Page_Load du code derrière. Mais je ne l'ai pas assez loin pour le tester.

...

<div>
Check to see if the file "_File_Permissions_Test.txt" was written to <% Response.Write(Data.ConfigurationHelper.ValueFromConfiguration("ExportPath", Nothing))%> 
</div>

...

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
    Dim exportPath As String = Data.ConfigurationHelper.ValueFromConfiguration("ExportPath", Nothing)
    If exportPath = String.Empty Then Return
    Dim exportDirectory As DirectoryInfo = Directory.CreateDirectory(exportPath)

    Dim writer As StreamWriter = File.CreateText(Path.Combine(exportDirectory.FullName, "_File_Permissions_Test.txt"))
    writer.WriteLine("TESTING... " + DateTime.Now().ToString)
    writer.Flush()
    writer.Close()

End Sub

OriginalL'auteur MacGyver | 2011-05-24

  1. 7

    comme je l'ai écrit dans mon post :
    GreKai.WordPress.com
    Vous devriez avoir entré le nom de l'ordinateur et de ne pas le ApplicationPoolIdentity. C'était votre problème.L'essayer ! Il devrait fonctionner.

    Les étapes sont les suivantes :

    Aller dans le Dossier Partagé –> clic droit –> propriétés -> –>edit –> add (comme d'habitude ) -> choisir les types d'objet –> vérifiez sur les ordinateurs –> maintenant, entrez le nom de l'ordinateur où votre demande de travail , où vous avez publié votre application.

    Pouvez-vous aller de l'avant et détails les étapes de votre réponse, plutôt que de référencement sur le lien? Je vais changer ma réponse à la vôtre si vous le faites. Ma réponse fonctionne bien, mais le tien semble être la façon dont Microsoft a conçu.
    – @MacGyver fait

    OriginalL'auteur

  2. 2

    Pour résoudre celui-ci, notre administrateur du serveur créé un utilisateur de domaine dans le contrôleur de domaine appelé domainuser. Puis je suis allé dans les pools d'applications IIS 7 paramètres avancés, et changé l'Identité de ApplicationPoolUser "{nom de domaine}\domainuser" (en vertu de la Coutume Compte de terrain) et l'entrée du mot de passe pour le compte. Puis-je définir les permissions d'écriture (dans le dossier properties > sécurité) sur le dossier partagé de {nom de domaine}\domainuser. Il a travaillé beaucoup.

    l'inconvénient de votre réponse, c'est que vous n'êtes pas à l'aide de ApplicationPoolIdentity utilisateur et que vous devez entrer le mot de passe.
    Ce n'est pas un correctif pour le problème décrit, plus d'une solution de contournement pour le problème original.
    En fait, à l'aide d'un compte de service qui peut être verrouillé et dédié à un étroit but est la méthode la plus sûre, car elle réduit la surface d'attaque. À l'aide de la machineaccount$ pour l'accès signifie que tous les processus qui s'exécute sous le compte service réseau (comme d'autres sites sur ce serveur) sera également avoir des droits sur cette ressource réseau. Mais oui, le mot de passe de gestion peut être le revers de la médaille.

    OriginalL'auteur MacGyver