Je veux pouvoir définir les permissions de modification pour le compte IIS des nouveaux sites web. J'ai le script suivant :
```
function Set-ModifyPermission ($directory, $username, $domain = 'IIS APPPOOL') {
$inherit = [system.security.accesscontrol.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [system.security.accesscontrol.PropagationFlags]"None"
$acl = Get-Acl $directory
$user = New-Object System.Security.Principal.NTAccount($domain, $username )
$accessrule = New-Object system.security.AccessControl.FileSystemAccessRule($user, "Modify", $inherit, $propagation, "Allow")
$acl.AddAccessRule($accessrule)
set-acl -aclobject $acl $directory
}
```
Cependant, lorsque je l'exécute, j'obtiens des erreurs comme :
>
Set-Acl : La relation d'approbation entre cette station de travail et le domaine principal a échoué.
Je pense que c'est parce que `IIS APPPOOL` n'est pas un vrai domaine, mais un préfixe bizarre sur un compte semi-fictif. Existe-t-il un moyen correct de référencer ce compte pour que cela fonctionne ?
Comment ajouter des permissions ACL pour les comptes IIS APPPOOL\* via PowerShell ?
Re: Comment ajouter des permissions ACL pour les comptes IIS APPPOOL\* via PowerShell ?
Tout d'abord, utilisez Set-Acl comme ceci, car le chemin du répertoire est le premier argument positionnel :
```
Set-Acl $directory $acl
```
Ensuite, vous devez créer l'objet utilisateur avec un seul argument :
```
$user = New-Object System.Security.Principal.NTAccount("$domain\\$username")
```
**MISE À JOUR :** Il semble qu'il n'accepte pas « IIS APPPOOL\AppPoolName » comme identifiant NTAccount. Il y a maintenant deux façons d'accomplir ce que vous essayez de faire :
-
Créer un nouvel objet SID avec le SID des identités AppPool et le traduire en NTAccount, comme ceci : [http://iformattable.blogspot.com/2007/12/convert-sid-to-ntaccount-with.html](http://iformattable.blogspot.com/2007/12/convert-sid-to-ntaccount-with.html), et vous devriez pouvoir le traiter comme n'importe quel autre objet NTAccount. Si vous avez toujours besoin de pouvoir passer des noms domaine/utilisateur pour de vrais comptes, intégrez une logique simple qui utilise par défaut le SID AppPool si le nom d'utilisateur est « AweSomeAppPool » et que le domaine est vide, par exemple.
-
Utilisez PowerShell pour invoquer icacls.exe, et utilisez-le pour accorder/révoquer les permissions souhaitées, comme ceci (d'abord la forme icacls normale depuis l'invite de commandes, puis PowerShell, notez la différence) :
`icacls.exe test.txt /grant "IIS AppPool\DefaultAppPool":(OI)(CI)M`
`cmd /c icacls test.txt /grant "IIS AppPool\DefaultAppPool:(OI)(CI)M"`
Si vous optez pour la seconde option, assurez-vous de les tester manuellement d'abord, je n'ai pas eu l'occasion de tester ces exemples spécifiques moi-même, mais cela devrait fonctionner.
```
Set-Acl $directory $acl
```
Ensuite, vous devez créer l'objet utilisateur avec un seul argument :
```
$user = New-Object System.Security.Principal.NTAccount("$domain\\$username")
```
**MISE À JOUR :** Il semble qu'il n'accepte pas « IIS APPPOOL\AppPoolName » comme identifiant NTAccount. Il y a maintenant deux façons d'accomplir ce que vous essayez de faire :
-
Créer un nouvel objet SID avec le SID des identités AppPool et le traduire en NTAccount, comme ceci : [http://iformattable.blogspot.com/2007/12/convert-sid-to-ntaccount-with.html](http://iformattable.blogspot.com/2007/12/convert-sid-to-ntaccount-with.html), et vous devriez pouvoir le traiter comme n'importe quel autre objet NTAccount. Si vous avez toujours besoin de pouvoir passer des noms domaine/utilisateur pour de vrais comptes, intégrez une logique simple qui utilise par défaut le SID AppPool si le nom d'utilisateur est « AweSomeAppPool » et que le domaine est vide, par exemple.
-
Utilisez PowerShell pour invoquer icacls.exe, et utilisez-le pour accorder/révoquer les permissions souhaitées, comme ceci (d'abord la forme icacls normale depuis l'invite de commandes, puis PowerShell, notez la différence) :
`icacls.exe test.txt /grant "IIS AppPool\DefaultAppPool":(OI)(CI)M`
`cmd /c icacls test.txt /grant "IIS AppPool\DefaultAppPool:(OI)(CI)M"`
Si vous optez pour la seconde option, assurez-vous de les tester manuellement d'abord, je n'ai pas eu l'occasion de tester ces exemples spécifiques moi-même, mais cela devrait fonctionner.