Auteur de questions
Powershell problème d'ajout computer dans un groupe AD.

Question
-
Bonjour,
J'ai effectué un script installant CMCB sur des VMs puis qui rajoute ces VMs dans un groupe AD.
Dans mon script .cmd, j'ai ajouté cette ligne pour appeler mon script PS :
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""C:\XXX\post_install\Move_OU-Exclu.ps1""' -Verb RunAs}"
Mon script PS :
#Commande pour ressortir certaines erreurs de frappe ou codage
Set-StrictMode -Version 2.0
#Autoriser l'exécution de Scripts Powershell
Set-ExecutionPolicy Unrestricted -Force
#Déclaration de variables
$com=hostname
$nme=Get-ADComputer $com | select -ExpandProperty SamAccountName
$grp=Get-ADGroup CSNV_VM-Exclu-Secu-CMCB_tst_GG | select -ExpandProperty DistinguishedName
#Ajout de la machine dans le groupe AD
Add-ADGroupMember -Identity $grp -Members $nme -Server "XXX"Lorsque je test mes scripts, je n'ai pas d'erreur.
Par contre lorsque le compte de service exécute ses scripts, il ne rajoute pas les VMs dans le groupe AD.
Auriez-vous des pistes ou des questions si jamais j'ai omis d'énoncer d'autres détails ?
Pour info, j'ai testé l'ajout dans le groupe AD avec le compte de service (en ayant rajouté au préalable NOLOGON-RunAs) et cela fonctionne, du coup je ne vois pas où est le problème.
Merci d'avance.
JOSEPH Michel
Toutes les réponses
-
-
Merci pour votre réponse rapide
C'est ce que je me suis dit, mais travaillant dans une grosse boîte séparant chaque service, je n'ai pas les droits sur l'AD, ce qui est très contraignant.
Je vais me rapprocher de l'équipe concernée et leur demander si le compte a bien la délégation de contrôle.
Pourtant lorsque l'on a testé avec le compte de service (avec le NoLogon-RunAs), le script fonctionnait correctement, ce qui voudrait dire que les droits sont bons.
Si vous avez d'autres pistes je suis preneur.
Dans tous les cas, je mettrai à jour ce thread.
JOSEPH Michel
-
Après une entrevue avec l'interlocuteur adéquat, il ne s'agirait pas d'un problème de droit mais plutôt de timeout ou alors de l'objet inexistant.
Je ferai des tests avec une boucle et un get de l'objet de la machine jusqu'à ce qu'il l'a trouve puis faire l'ajout dans le groupe AD.
N'hésitez pas à me donner des idées ou me confirmer que je suis sur la bonne piste.
Merci.
JOSEPH Michel
-
bonjour MichelJ
je ne crois pas a "l'objet inexistant" sauf si tu viens juste de créé la VM dans le script !
par contre comme disais François un problème de droit du au "double hop"
quelques solutions ici ou la
en espèrent que ça puisse être le soucis chez toi !
-
Merci 6ratgus,
Je vais effectuer en premier lieu un scope + log, et voir ce qui pose problème et en parallèle voir le problème de droit du au double hop même si ça ne me dit rien là de suite.
Je vais lire les liens que vous avez mis et essayer de voir si cela rentre dans ma problématique.
Je vous remercie.
JOSEPH Michel
-
tu peut faire un log pour voir ce qui ce passe quand le compte system ne fonctionne pas avec cette écriture *> c:\temp\temp.txt :
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""C:\XXX\post_install\Move_OU-Exclu.ps1 *> c:\temp\temp.txt""' -Verb RunAs}"
choisi un dossiers local pour le log pour évité les problèmes de droits et sous Windows 8 et 10 il devient difficile d'écrire a la racine du disque
bonne chance pour tes recherches
-
Bonjour,
J'ai modifié mon script afin qu'il y ait un log au début de mon PS, j'ai également fait une boucle jusqu'à ce que la machine soit dans le groupe AD souhaité et à la fin j'ai rajouté une vérification.
Par contre, j'ai eu cette erreur sur mes VMs :
AVERTISSEMENT : Erreur d'initialisation du lecteur par défaut : « Impossible de trouver un serveur par défaut avec les services Web Active Directory en cours d'exécution. ».
Du coup, j'ai vérifié que le RSAT était bien installé sur mes VMs : Oui bien installé.
Par contre, impossible d'importer les modules AD sur les VMs.
Puis j'ai trouvé dans un lien ceci :
Le client ADAC envoie des requêtes PowerShell à un contrôleur de domaine disposant du service ADWS sur le port 9389, qui interrogera directement la base LDAP d’active directory sur le port 389 ou le catalogue global sur le port 3268.
Il se pourrait donc que le script fonctionne mais sans les modules AD et la connexion vers la base LDAP, ça va être compliqué.
JOSEPH Michel
-
peut tu regarder ce sujet qui a peut être la solution pour ton message d'avertissement
sinon regarde cote firewall si les port sont ouvert
il est quand bizarre d'avoir ce message sur le compte service alors que tu ne la pas sur ton compte avec la même machine !
-
-
-
Je n'ai pas la main sur les serveurs :/, mais uniquement sur mon poste et l'infra VDI.
Travaillant dans une grosse boîte, ils ont tout découpé. Mais je vais me rapprocher de l'équipe concerné pour leur demander.
Après je n'ai pas de problème depuis mon poste avec ces commandes PS, du coup le service est bien activé.
Mais vaut mieux prévenir que guérir, je demanderai quand même pour avoir la conscience tranquille.
JOSEPH Michel
-
Bonjour,
Je viens mettre à jour car je pense arriver au bout.
Suite à mon retour log, j'ai constaté que le compte utilisé était le compte machine qui n'a pas les droits nécessaires pour l'exécution de mon script.
J'essaie de faire un run as :
$username = 'XX'
$password = 'YY'$securePassword = ConvertTo-SecureString $password -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential $username, $securePasswordMais par contre je ne sais pas si je dois faire le run as dans mon cmd quand j'appelle mon script PS, ou est ce que je dois faire un run as au début du script PS, ou alors appeler un script PS depuis le cmd qui fera un run as puis exécute le script(ajoutant la machine dans l'AD) avec les bons credentials ?
Je vous avoue j'ai un peu de mal à comprendre le fonctionnement du RunAs.
Merci d'avance.
JOSEPH Michel