none
L'accès au chemin d'accès '\\monserveur\fichier.txt' est refusé. RRS feed

  • Question

  • Bonjour à tous,

    J'ai un script qui fait ça :

    Invoke-Command -ComputerName serveur1 -ScriptBlock {
    
    $IsRebootRequired=(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired")
    If ($IsRebootRequired -eq 1)
     {
        echo "$env:computername test ok";
    	echo "$env:computername" >> \\serveur2\fichier.txt;
     }

    Ce qui est censé venir écrire le nom de mon serveur1 dans le fichier fichier.txt si la clef de registre est présente.

    J'ai appliqué les droits NTFS et de partage en full pour tous les utilisateurs et tous les ordinateurs du domaine.

    Je lance bien mon script en tant qu'administrateur.

    J'ai comme erreur ceci :

    L'accès au chemin d'accès '\\serveur2\fichier.txt' est refusé.
        + CategoryInfo          : OpenError: (:) [], UnauthorizedAccessException
        + FullyQualifiedErrorId : FileOpenFailure
        + PSComputerName        : serveur1
    

    Info complémentaire : si je lance ce même script en remplaçant serveur1 par serveur3 (qui lui est contrôleur de domaine), là, ça passe.

    La question est donc : Quels sont les droits à attribuer à des ordinateurs (non DC) pour qu'ils puissent écrire dans mon fichier partagé.

    Si quelqu'un peut m'aider ce serait bien apprécié.

    Merci à tous.

    vendredi 19 avril 2019 13:25

Toutes les réponses

  • Bonjour, lorsque vous faites de l'invoke command vous êtes forcements soumis à des autorisations.

    le lien ci-dessous explique en détails la configuration des droits:

    https://blog.piservices.fr/post/2013/10/30/Powershell-Gestion-a-distance

    Cordialement.

    vendredi 19 avril 2019 14:09
  • Merci pour cette réponse.

    Est-ce que les droits indiqués dans le chapitre Gestion WMI à distance peuvent être en cause dans mon cas ?

    vendredi 19 avril 2019 14:39
  • Oui je pense.

    Je vous laisse tout vérifier et revenir vers nous.

    Cordialement.

    vendredi 19 avril 2019 14:40
  • Je viens de vérifier, je lance mon script depuis un compte admin du domaine.

    Du coup, j'ai déjà tous les droits mentionnés dans l'article.

    vendredi 19 avril 2019 14:53
  • Bonjour, ok merci de votre retour.

    Pouvez-vous lancer la commande suivante: "Enter-PsSession -ComputerName "nom du serveur"

    Si vous tentez un accès sur le c$ du serveur, est-ce que cela fonctionne?

    Cordialement. 

    mardi 23 avril 2019 06:30
  • Bonjour,

    Oui, en lançant Enter-PsSession -ComputerName monserveur

    je tombe dans c:\users\...

    Je peux naviguer et lister les fichiers pour constater que ce sont bien ceux de mon serveur distant.

    mardi 23 avril 2019 15:32
  • Bonjour, ok donc c'est un problème du double saut.

    Explications ci-dessous:

    http://www.metsys.fr/blog/troubleshooting-double-saut/

    Cordialement.

    mercredi 24 avril 2019 07:19
  • Merci encore pour cette réponse.

    Malheureusement, ça ne change rien :

    Sur mon serveur distant (après application du script) :

    PS C:\Windows\system32> Get-WSManCredSSP
    L'ordinateur est configuré afin d'autoriser la délégation de nouvelles informat
    ions d'identification aux cibles suivantes : wsman/*.<domaine>.lan
    Cet ordinateur n'est pas configuré pour recevoir les informations d'identificat
    ion d'un ordinateur client distant.

    Mais le résultat reste le même sur mon serveur de contrôle.

    Une autre idée que j'avais mais que je n'ai pas réussi non plus à mettre en place, c'était de placer $env:computername dans un tableau temporaire que je pourrai afficher en fin de script (l'idée étant de faire tourner mon invoke-commande sur une liste de serveur).

    mercredi 24 avril 2019 14:27
  • Tu as crée un partage car ton chemin me parait bizarre :

    echo "$env:computername" >> \\serveur2\fichier.txt;

    Ca ne serait pas plutot :

    \\serveur2\partage\tichier.txt

    ou

    \\serveur2\c$\tichier.txt

    mercredi 24 avril 2019 14:39
  • oui oui, il y a bien un partage.

    J'ai tronqué un peu court après avoir collé mon script.

    mercredi 24 avril 2019 15:06
  • Meme en rajoutant ceci :

    Invoke-Command -ComputerName serveur1 -authentication credssp -credential domain\user -ScriptBlock {
    
    $IsRebootRequired=(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired")
    If ($IsRebootRequired -eq 1)
     {
        echo "$env:computername test ok";
    	echo "$env:computername" >> \\serveur2\partage\fichier.txt;
     }
    mercredi 24 avril 2019 15:32
  • J'ai cette réponse :

    [serveur] La connexion au serveur distant serveur a échoué avec le message d'erreur suivant: Le client WinRM ne peut
    pas traiter la demande. L'authentification CredSSP est actuellement désactivée dans la configuration du client.
    Modifiez la configuration du client et renouvelez la demande. L'authentification CredSSP doit aussi être activée dans
    la configuration du serveur. Par ailleurs, la stratégie de groupe doit être modifiée de manière à autoriser la
    délégation des informations d'identification à l'ordinateur cible. Utilisez gpedit.msc et examinez la stratégie
    suivante: Configuration ordinateur -> Modèles d'administration -> Système -> Délégation d'informations
    d'identification -> Autoriser la délégation de nouvelles informations.  Vérifiez qu'elle est activée et configurée
    avec un SPN approprié pour l'ordinateur cible. Par exemple, pour le nom d'ordinateur cible «monserveur.domaine.com»,
    le SPN peut être l'un des noms suivants: WSMAN/monserveur.domaine.com ou WSMAN/*.domaine.com Pour plus d'informations,
    voir la rubrique d'aide about_Remote_Troubleshooting.
        + CategoryInfo          : OpenError: (SRVSIGMA:String) [], PSRemotingTransportException
        + FullyQualifiedErrorId : -2144108126,PSSessionStateBroken

    Alors que le serveur distant indique bien :

    L'ordinateur est configuré afin d'autoriser la délégation de nouvelles informat
    ions d'identification aux cibles suivantes : wsman/*.<domaine>.lan

    Je crains qu'il n'y ait trop d'autorisations à modifier pour faire ce que je veux et je ne maîtrise pas toutes les failles de sécurité que ça peut engendrer.

    Je ne vais donc pas poursuivre sur cette voix.

    jeudi 25 avril 2019 07:20