PI Services

Nous allons voir comment effectuer une recherche sur un objet utilisateur dans Active Directory à l’aide du SamAccountName. Et ainsi avoir accès aux propriétés du compte.

Tout d’abord on initialise une variable contenant la connexion à un contrôleur de domaine avec les éléments d’identification.

$dc= New-Object system.directoryservices.directoryEntry('LDAP://192.168.1.1','login','mdp')

Ensuite on initialise notre variable de recherche.

$Search_DC=New-Object system.directoryservices.directorysearcher($dc)

Nous allons maintenant rechercher l’utilisateur ayant pour SamAccountName “alphonse.dupuit”

$Search_DC.filter="(&(objectClass=user)(samaccountname=alphonse.dupuit))"

On affiche le résultat.

$search.findone()

On peut maintenant afficher et donc récupérer les différentes propriétés de l’objet utilisateur.

($search.findone()).properties

Nous pouvons également accéder a ces informations en utilisant d’autres méthodes :ajout de module tel que Active-Directory, Quest, etc..

Exemple avec les cmdlets Quest

Ajout des cmdlets Quest au shell :

Add-PSSnapin Quest.ActiveRoles.ADManagement

initialisation de variables pour identification

$U="login"
$PU="mdp"
$D=convertto-securestring -string $pu -AsPlainText –force (mot de passe crypté)

Connexion au contrôleur de domaine

Connect-QADService 192.168.1.1 –ConnectionAccount $U -ConnectionPassword $D

Recherche de l’utilisateur cedrick.vaccard

Get-qaduser cedrick.vaccard

On peut désormais accéder et récupérer les propriétés de l’utilisateur

Get-qaduser cedrick.vaccard |fl

Vous aviez sur votre poste Windows 7 et vous venez d’installer Windows 8 sur une seconde partition.

Windows 8 étant le dernier système d’exploitation à avoir été installé, vous serez donc confronté au bootloader de Windows 8. Cependant, la procédure de démarrage de Windows 8 détient une petite subtilité. Contrairement au gestionnaire de boot de Windows 7, celui de Windows 8 ne sera affiché qu’après chargement de ce nouvel OS.

Cela signifie que si vous souhaitez démarrer sous Windows 7, l’ordinateur va alors de nouveau redémarrer pour booter sur Windows 7. Cette situation peut être contraignante en termes de temps.

Nous allons donc voir comment remettre le BootLoader de Windows 7.

Démarrons par exemple sous Windows 8. (La méthode fonctionne également sous Windows 7)

Dans notre explorateur, on peut voir que la partition C : correspond à notre Windows 8.

Sur la partition D : est donc présente l’installation de Windows 7.

Ouvrez une commande cmd avec les droits administrateurs.

Tapez :

bcdboot d:\windows

(d: étant la partition hébergeant Windows 7)

la réponse suivante s’affiche

Les fichiers de boot viennent alors de se mettre à jour.

Maintenant en redémarrant,

Le bootLoader de Windows 7 est désormais restauré.

Lors de l’utilisation de scanstate (outil USMT), il se peut que vous ayez des problèmes d’accès sur certains profils. Cela peut se produire quand un profil sur l’ordinateur n’a pas été supprimé proprement.

Par exemple un profil utilisateur a été supprimé depuis l’explorateur et non depuis les paramètres système avancés è Profil des utilisateurs .

Dès que cela se produit, le mécanisme par défaut de USMT tente sous 20 reprises de charger le NTUSER.dat de ce profil non trouvé.

Cela a pour cause de prolonger le temps de traitement de scanstate.

Pour désactiver les tentatives répétés d’accès à des profils supprimé, une variable peut être définit : MIG_IGNORE_PROFILE_MISSING

Il suffit de définir cette variable à 1 et l’outil Scanstate ne tentera plus d’accéder de manière répété aux profils absent : SET MIG_IGNORE_PROFILE_MISSING=1

Imaginons que vous deviez effectuer un net use dans un script sur plusieurs machines mais que les disks drive disponible ne soit pas les mêmes. Pour cela, nous allons consulter le registre.

Dans le registre, chaque disk drive monté apparait dans HKCU\Network

Exemple :

Un net use

Sous le registre

Avec la cmdlet Get-Random, nous pouvons emprunter une lettre pour un disk drive aléatoire et voir si la clé dans le registre au niveau de HKCU\network est retrouvé par notre valeur obtenu du Get-Random . Si cela n’est pas le cas, cela veut dire que la lettre est disponible pour notre disk drive.

Récupérer une lettre disponible dans une variable

Pour notre cmdlet get-random, nous définissons une collection de valeur allant de o à z.

Pour chaque valeur obtenue, nous allons vérifier si la clé correpondante dans le registre sous HKCU\Network existe. La variable récupérera donc une valeur qu’il comparera au registre.

do {$MapDest=get-random -input "o","p","q","r","s","t","u","v","w","x","y","z"; get-childitem "registry::HKEY_CURRENT_USER\Network\$MapDest"; $check=$?} while ($check -eq "true")

Notre variable a maintenant une lettre de lecteur disponible pour un mappage de lecteur réseau. Il ne reste plus qu’à ajouter à notre variable $MapDest le caractere “:”

$MapDest=("$MapDest :").replace(" ","")

La variable peut maintenant être utilisé pour un mappage : net use $MapDest \\path

La commande get-credential obtient un objet credential (informations d'identification) basé sur le nom et mot de passe d'un utilisateur.

Cependant, cette commande est incompatible avec les fournisseurs installés avec Windows Powershell.

Exemple d’une copie de fichier sans crédential

Maintenant, essayons en spécifiant un utilisateur.

On peut donc voir que le fournisseur n’est pas compatible en définissant un crédential.

Maintenant, nous allons voir comment permettre une authentification via le module impersonation disponible à cette adresse : http://poshcode.org/get/1867

Cette astuce devra être exécuté avec Powershell en mode STA : Single-Threaded Apartments car le module que nous allons importer n’est compatible que dans ce mode.

Exécuter :

(En mode STA, la fenêtre Powershell est noir par défaut)

Maintenant on récupère notre variable d’authentification comme auparavant.

Si on exécute une copie de fichier avec la variable $cred, on peut voir que cela ne fonctionne toujours pas.

Maintenant, on va importer le module « impersonation » qui va mettre à notre disposition trois nouvelles commandlets.

A l’aide de Push-ImpersonationContext, on va maintenant récupérer notre variable $cred. Et à partir de là, on peut réessayer une copie de fichier qui auparavant ne fonctionnait pas.

Cela fonctionne désormais.

Pour effacer de la mémoire l’authentification, nous avons la variable Pop-impersonationContext disponible.

Exemple :

Nous supprimons le fichier copié là où celui-ci a fonctionné auparavant et nous utilisons la cmdlet Pop-impersonationContext. Nous réessayons donc une nouvelle fois notre copie de fichier :

Cela a bien supprimé l’authentification gardé en mémoire.

Autre exemple d’authentification pour la création d’un item  (même principe):

Il existe un module nommé NTFSSECURITY permettant une manipulation simplifié des droits NTFS sur des dossiers et/ou fichiers.

Ce module peut être trouvé sur la galerie Technet http://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85/file/48905/1/NTFSSecurity%201.3.zip

Une fois téléchargé, mettez le dossier du module NTFSSecurity ici C:\Windows\System32\WindowsPowerShell\v1.0\Modules

Maintenant, nous allons charger le module dans powershell

Une fois celui-ci chargé, de nouvelles cmdlets sont désormais disponible.

                                    …

Récupération du SID d’un utilisateur dans une variable.

Nous allons définir dans une variable $SamMember le nom de l’utilisateur que nous voulons récupérer.

Ensuite nous allons utiliser l’object System.Security.principal.NtAccount(« domaine »,utilisateur) qui va nous permettre de récupérer notre utilisateur dans un domaine spécifié.

Maintenant, récupérons le SID de notre utilisateur grâce à une méthode de notre variable $account.

Nous avons ainsi récupéré dans notre variable $accountsid le SID de notre utilisateur spécifié dans la variable $SamMember.

Modification du propriétaire d’un répertoire.

Avec le chargement du module NTFSSecurity, une cmdlet get-owner est apparue nous permettant de connaitre simplement le propriétaire d’un élément (fichier ou répertoire).

Exemple :

Nous allons maintenant changer le propriétaire de ce répertoire avec l’utilisateur contenu dans notre variable $accountsid

Voyons maintenant le résultat :

Le propriétaire à bien été changé.

Modification des ACE du répertoire.

Nous allons maintenant modifier les ACE du répertoire de façon à ne laisser que l’utilisateur de notre variable $accountsid en FullControl et aucune autre ACE.

Rajout de l’ACE :

Suppression des autres ACE :

(Ce lien permet de connaitre les SID connu dans les OS Windows http://support.microsoft.com/kb/243330)

Si on consulte maintenant nos ACE, on peut remarquer que notre ajout d’ACE s’est bien passé mais que la suppression des autres ACE ne s’est pas déroulée correctement.

Cela est normal, car ses ACE sont hérité du répertoire parent. Il faut donc pour cela retirer l’héritage.

Et maintenant si on essaie de nouveau de supprimer nos ACE on peut remarquer que celle-ci ont bien disparu.

Il est maintenant facile d’imaginer la création d’un script pouvant réappliquer correctement des droits sur une toute une arborescence de répertoires profils en récupérant par exemple le nom du répertoire profil et en réaffectant celui-ci dans une boucle pour notre variable $account.

Ainsi, l’utilisateur authentifié en user2, ne pourra accéder qu’à son répertoire profil.

Le comportement d’USMT dans un état Offline est différent d’un état Online.

Nous nous situons dans un cas ou l’exécutable Scanstate est lancé sous Windows PE (donc offline).

Lors d’une capture en offline, le mappage des utilisateurs ne peut se baser sur la base SAM des utilisateurs. Le mappage s’effectue à l’aide des SID.

Exemple du log du ScanState sous Windows PE (Offline)

Exemple du log de ScanState sous Windows XP (Online)

Ce qui veut dire que pendant l’utilisation du ScanState sous Windows PE, nous ne devons travailler qu’avec des SID.

Si par exemple on ne veut inclure qu’un seul utilisateur dans notre DataStore du ScanState, il faudra utiliser l’argument /ue:* permettant d’exclure tous les utilisateurs et utiliser l’argument /ui  permettant d’inclure l’utilisateur spécifique avec son SID.

Exemple:

scanstate E:\Migshare\U11281 /i:x:\ftmas7\tools\usmt\F2_MigFiles.xml /i:x:\ftmas7\tools\usmt\MigOutlook.xml /o /c /localonly /v:13 /offlinewindir:c:windows /ue:* /ui:S-1-5-21-1221297486-3643808661-2871141796-1074 /l:E:\Migshare\U11281\log.txt

Pour inclure plusieurs utilisateurs, l’argument /ui peut être utilisé autant de fois que désiré.

Utilisation du ScanState en Offline pour capturer uniquement des utilisateurs du domaine.

Si vous souhaitez ne capturer que des utilisateurs d’un domaine et non les utilisateurs locaux, vous pouvez exclure tout le monde via l’argument /ue :* et inclure uniquement le SID du domaine avec l’astérique « * » pour le pool RID.

Exemple :

scanstate.exe S: /i:MigFiles.xml /i:MigOutlook.xml /l:S:\log.log /progress:S:\Prog.log /localonly /o /c /v:13 /offlinewindir:c:\windows /ue:* /ui: S-1-5-21-759407729-413330662-2607319723-"*"

Utilisation du LoadState sur un DataStore obtenu par un ScanState Offline

Contrairement au ScanState, le LoadState ne peut être exécuté qu’en mode Online.

Ayant utilisé ScanState en mode Offline, nous avons donc du traiter les utilisateurs via leurs SID. Il en sera donc de même pour le LoadState car aucun mappage samaccountname n’a pu être effectué précédemment.

Donc l’utilisation des commutateurs /ue et /ui se passent de la même manière que pour le Scanstate en Offline c’est-à-dire basé sur des SID.

Dans le cas d’une migration de domaine, il n’est pas nécessaire de spécifier le SID du domaine source vers le domaine cible. (La migration de domaine s’opère à l’aide du commutateur /md. (/md:Old_domain :New_domain)

Exemple :

loadstate F:\Migshare\U11281 /i:C:\APPLI_FTV\apps\usmt\F2_MigFiles.xml /i:C:\APPLI_FTV\apps\usmt\MigOutlook.xml /c /v:13 /l:F:\Migshare\U11281\Load-log.txt /md:SourceSI :CibleSi /progress:F:\Migshare\U11281\simpleprog.log

Cela signifie que tous les utilisateurs situés dans le DataStore avec pour domaine source « SourceSI » vont être migré sur « CibleSi » si ceux-ci existent.

Attention, si USMT tente de migrer un utilisateur sur un domaine cible mais que celui-ci n’existe pas dans ce domaine, une erreur fatale en ressortira et le déroulement du LoadState sera alors interrompu.

Cependant, si vous souhaitez utiliser /mu au lieu de /md, la, il faudra utiliser le SID utilisateur depuis la source et spécifier le domaine cible ainsi que son Sam Account Name.

Exemple :

loadstate F:\Migshare\U11281 /i:C:\APPLI_FTV\apps\usmt\F2_MigFiles.xml /i:C:\APPLI_FTV\apps\usmt\MigOutlook.xml /c /v:13 /l:F:\Migshare\U11281\Load-log.txt /mu:S-1-5-21-1221297486-3643808661-2871141796-1074:CibleSi\trsb2 /ui:S-1-5-21-1221297486-3643808661-2871141796-1074 /progress:F:\Migshare\U11281\simpleprog.log /ue:*

Le profil utilisateur sera alors créé sur l’os cible dans le nouveau domaine.

Vous disposez d’une liste exhaustive de comptes utilisateurs dans un fichier et vous désirez savoir ceux d’entre eux qui sont bien existant dans le domaine courant.

Pour cela, nous allons parcourir ce fichier et établir une connexion sur ces utilisateurs. Si la connexion sur l’utilisateur se passe bien, nous l’ajouterons dans un second fichier. Si cet utilisateur n’existe pas, nous l’ignorerons.

Exemple de fichiers contenant sur une colonne des utilisateurs existant ou non dans le domaine courant.

Résultat obtenu dans un fichier result.txt :

Le script nous a bien permit de récupérer uniquement les utilisateurs existant dans le domaine courant.