Powershell | enguerrand.ps1

Powershell : création automatique d’un jeu d’objets de tests ActiveDirectory

de Enguerrand 26 septembre 2018 11 juin 2019 Non classé

J’ai monté et détruit plusieurs plateformes AD de test récemment en faisant des maquettes de développement sous Windows Server 2016. J’ai donc développé un petit script permettant d’automatiser la création d’un jeu de test ayant pour but de remplir l’AD avec des utilisateurs, des ordinateurs et des groupes afin d’avoir matière à travailler.

Le mot de passe affecté aux comptes est modifiable directement dans le script. A l’exécution, ce dernier va vous demander le nom de l’OU dans laquelle placer tous les éléments qui vont être créés.

Télécharger

Pas de commentaire

Powershell : journalisation des ouvertures de session en local et à distance

de Enguerrand 18 septembre 2018 6 février 2020 Non classé

Deux scripts pour le prix d’un ! Ça pourrait être une véritable aubaine si ce n’était pas un script adapté à deux situations. 👍

Ce script, couplé à une tâche planifiée l’exécutant à chaque ouverture de session, enregistre dans un fichier CSV journalier ces dernières avec le timestamp associé, ce qui permet de tracer de manière générale et durable les connexions à une station de travail ou à un serveur par les utilisateurs.

Pourquoi deux scripts ? Lorsqu’on exécute une tâche planifiée, il faut spécifier un compte d’utilisateur, qu’il soit LOCAL SERVICE ou service-tacheplan par exemple. Le problème, c’est qu’une fois que la tâche sera créée et qu’elle sera déclenchée à l’ouverture de session, ce ne sera pas l’utilisateur martin qui ouvrira Powershell et exécutera le script. Ce sera le compte renseigné dans la tâche, et par conséquent, on ne peut utiliser $env:username dans le script pour récupérer le nom de l’utilisateur qui vient d’ouvrir la session. Il est possible de passer par la classe WMI Win32_ComputerSystem pour trouver le nom de l’utilisateur qui est connecté physiquement sur la station, ce qui permet de court-circuiter l’impersonnification réalisée par Windows. Mais ce ne serait pas amusant si c’était aussi facile, dans le cadre d’une session ouverte en RDP (un serveur, typiquement), cela ne fonctionne pas car WMI retourne uniquement les sessions ouvertes physiquement, et pas à distance. Il faut donc passer par quser et jouer avec la chaîne de caractère renvoyée pour déterminer l’utilisateur qui a sa session déclenchant la tâche. Bien qu’il soit possible de procéder avec la deuxième méthode pour la première, j’ai préféré réaliser deux scripts 😉

Workstations (local)

$time = Get-Date -f "HH:mm:ss"
$logfile = "c:\log-connexion\$date.csv"
$date = Get-Date -f "dd/MM/yyyy"
$compname = $env:COMPUTERNAME
$user = (Get-WmiObject -class win32_ComputerSystem | select username).username
$os = (Get-WmiObject Win32_OperatingSystem).Caption
$ip = (Get-NetIPConfiguration | Where-Object { $_.IPv4DefaultGateway -ne $null -and $_.NetAdapter.Status  -ne "Disconnected" }).IPV4address.IPAddress
$infologin = "$date,$time,$user,$compname,$ip,$os"
add-content $logfile $infologin

Serveurs (RDP)

function getrdpuser{
$quout = quser
$found = $false
$point = ">"
$sid = (($quout | Where-Object { $_ -match $point }) -split ' +')[2]
while ($found -eq $false)
{
$username = (($quout | Where-Object { $_ -match $point }) -split ' +')[0]
$sid = (($quout | Where-Object { $_ -match $point }) -split ' +')[2]
$found = $true
}
return $username.Substring(1,$username.Length-1)
}

$time = Get-Date -f "HH:mm:ss"
$logfile = "c:\log-connexion\$date.csv"
$date = Get-Date -f "dd/MM/yyyy"
$compname = $env:COMPUTERNAME
$user = getrdpuser
$os = (Get-WmiObject Win32_OperatingSystem).Caption
$ip = (Get-NetIPConfiguration | Where-Object { $_.IPv4DefaultGateway -ne $null -and $_.NetAdapter.Status  -ne "Disconnected" }).IPV4address.IPAddress
$infologin = "$date,$time,$user,$compname,$ip,$os"
add-content $logfile $infologin

Ensuite, il suffit d’appeler ce script via une tâche planifiée.

Après plusieurs connexions, on obtient donc un joli fichier CSV que l’on ouvre avec Excel, comme celui-ci :

Il est naturellement possible en modifiant la variable du nom de fichier dans le script de tout enregistrer dans un seul et même fichier unique si l’on souhaite tenir un registre global.

Télécharger (local)

Télécharger (RDP)

Pas de commentaire

Powershell : liste des utilisateurs de tous les partages SMB d’un serveur

de Enguerrand 14 septembre 2018 11 juin 2019 Non classé

J’ai réalisé un script permettant de générer une liste d’utilisateurs des partages SMB d’un serveur, ce qui peut être pratique à des fins d’audit ou si l’on souhaite simplement contacter les utilisateurs d’un serveur de fichiers pour une maintenance par exemple.

Il existe bien l’instruction Get-SmbShare mais elle n’est disponible qu’à partir de 2012 R2 ! Afin de permettre une compatibilité avec les OS 2008 (qui seront par ailleurs bientôt plus maintenus 😱), j’ai utilisé la classe WMI Win32_share.

Le script fonctionne en plusieurs phases : tout d’abord, il liste les partages existants (tels qu’on peut les voir dans la console de Computer Management), puis liste leurs ACL et récupère les membres des groupes AD éventuellement positionnés pour n’obtenir au final que des identifiants utilisateur. Naturellement, il est nécessaire de lancer le script avec des droits d’administration sur la machine afin d’être sûr de pouvoir lire toutes les ACL et d’avoir les modules AD pour Powershell ; sans quoi il vous faudra vous résoudre à utiliser un Invoke-Command qui a de grandes chances d’être bloqué par le pare-feu.

function parse{
param($objectName)
$doneparsing = $false
for($i=0; $doneparsing -eq $false; $i++){
if ($i+1 -gt $parsedArray.Count) { Write-Host "Added user $objectName." ; $parsedArray.Add($objectName) > $null; $doneparsing = $true }
if ($parsedArray[$i] -eq $objectName){ $doneparsing = $true }
}
}

Write-Host "Share user ACL listing script"
Write-Host "============================="
Write-Host "This script will retrieve all the SMB shares and their ACLs with a 'MYDOMAIN' domain object filter to a file located in the temp folder."
$parsedArray = New-Object System.Collections.ArrayList
$sharelist = Get-WmiObject -Class Win32_Share
foreach($share in $shareList){
if ($share.Path -ne ""){
$aclList = (Get-Acl $share.Path).Access | Where-Object {$_.IdentityReference.ToString().Contains('MYDOMAIN') }
foreach ($acl in $aclList){
$objectName = $acl.IdentityReference.Value
$canoName = $objectName.ToString().SubString(9,$objectName.Length-9)
$objectType = Get-ADObject -Filter {CN -eq $canoName}
if ($objectType.ObjectClass -eq "user"){ parse($objectName) }
if ($objectType.ObjectClass -eq "group") {
Write-Host "Processing group $canoName..."
$PplInGrp = Get-ADGroupMember $canoName
foreach($ppl in $PplInGrp){ parse($ppl.SamAccountName) }
}
}
}
}
cd $env:temp
foreach ($line in $parsedArray){
Add-Content share-acl.txt $line }
Write-host "Done processing."

Télécharger

Pas de commentaire

Quelques billes pour automatiser la préparation d’un serveur en Powershell

de Enguerrand 23 août 2018 11 juin 2019 Non classé

Je déploie régulièrement des VM à partir d’un template, seulement il reste pas mal d’opérations à faire à la main, comme le changement de nom, la configuration du réseau, l’installation de certaines applications et paramètres qui redescendent pas forcément par GPO.

Je vais donc présenter plusieurs instructions et snippets Powershell qui pourront fournir une bonne base pour la création d’un script complet pouvant être intégré dans un template et exécuté directement après le déploiement.

Tout d’abord, le changement du nom du serveur. On peut faire quelque chose de sympa comme ceci :

$hostname = $env:computername
Write-Host « Current Server name: $hostname »
$newhostname = Read-Host « New hostname »
Rename-Computer -NewName $newhostname
Write-Host « A reboot is required and will be performed in approx. 10 seconds. The script will automatically start after reboot to continue post-deployment operations. »
shutdown -r -t 10

On affiche le nom actuel du serveur, puis un prompt permettant de saisir le nouveau nom de machine. Un reboot permettra de prendre en compte le changement.

Après le redémarrage, on peut passer à la configuration de la carte réseau. En fonction de la configuration de la machine, cela peut être délicat puisqu’il faut être sûr d’affecter l’IP à la bonne carte réseau ; pour cela, on va donc récupérer toutes les cartes réseaux branchées sur le système, puis faire un filtre par nom et qui fonctionnent en IPv4. Par exemple, si la carte réseau s’appelle Ethernet0 :

$ipv4 = Read-Host « IPV4 address »
$gateway = Read-Host « Gateway »
$dnsprim = Read-Host « Primary DNS »
$dnssec = Read-Host « Secondary DNS »
$networkcards = Get-NetIPInterface | Where-Object {$_.InterfaceAlias -eq « Ethernet0 » -and $_.AddressFamily -eq « IPv4 »}
$interfaceindex = $networkcards[0].ifIndex
New-NetIPAddress -InterfaceIndex $interfaceindex -IPAddress $ipv4 -PrefixLength 24 -DefaultGateway $gateway
Set-DnsClientServerAddress -InterfaceIndex $interfaceindex -ServerAddresses ($dnsprim,$dnssec)

Get-NetIPInterface avec son pipe nous permet de rechercher les interfaces ayant pour nom Ethernet0 et configurées en IPv4. On récupère donc la carte qui est retournée par l’instruction et son index (qui n’est naturellement pas 1, ce serait trop facile !), qui nous permet ensuite de pouvoir le passer en paramètre de l’instruction New-NetIPAddress qui va se charger de coller la configuration IP à la carte. Le masque de sous réseau ne s’exprime pas en 255.255.255.0 mais notation CIDR, soit 24. Des tables de conversion sont facilement accessibles grâce à n’importe quel moteur de recherche, vous pouvez utiliser celle-ci. Si l’instruction est bien passée, elle retournera alors plusieurs informations quant à l’interface.

Ensuite, maintenant que le réseau est configuré, on peut joindre la machine au domaine.

Add-Computer -DomainName « super-domaine.local »
if ($?){ Write-Host « A reboot is required and will be performed in approx. 10 seconds. The script will automatically start after reboot to continue post-deployment operations. »
shutdown -r -t 10 }

Un prompt devrait apparaître pour demander un identifiant et un mot de passe d’un compte autorisé à ajouter des machines au domaine. Si la jonction se fait bien, alors le code dans la boucle if est exécuté et la machine redémarre après environ 10 secondes.

La machine mise sur le domaine, les divers paramètres poussés par GPO devraient redescendre (il faut bien évidemment pas oublier de déplacer l’objet Ordinateur qui s’est créé dans l’AD dans la bonne OU, sinon ça risque de ne pas bien marcher 😱). Cependant, d’autres opérations ou paramètres peuvent être modifiés par Powershell ; en voici quelques-uns.

Autorisation de l’exécution de scripts Powershell sans restriction :

Write-Host « Setting Powershell execution policy to Unrestricted… »
Set-ExecutionPolicy Unrestricted

Désactivation du pare-feu pour le domaine :

Set-NetFirewallProfile -Profile Domain -Enabled False

Si on souhaite tout automatiser et placer dans un même script, il faut prévoir la phase de reboot suite au changement de nom de la machine et la jonction au domaine (bien que la commande Add-Computer tolère un renommage de la station dans l’instruction). Pour n’utiliser qu’un seul script, et faire en sorte qu’il reprenne exactement là où il s’était arrêté, on peut placer chaque étape dans une fonction, et placer en paramètre facultatif le numéro de l’étape sur laquelle le script démarre ; ensuite une tâche planifiée démarre le script à l’ouverture de session de l’administrateur local.

Déclaration du paramètre :

Param
([string]$step)

Ensuite, une fonction pour créer la tâche, qui elle-même va prendre un paramètre :

function createtask{
param($rebootstep)
$TaskDetails = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType ServiceAccount -RunLevel Highest
$TaskAction = New-ScheduledTaskAction -Execute « powershell.exe » -Argument « C:\post-deployment.ps1 -s $rebootstep »
$TaskSched = New-ScheduledTaskTrigger -AtLogOn
$TaskName = « PostDeployReboot »
Register-ScheduledTask -Action $TaskAction -Principal $TaskDetails -Trigger $TaskSched -TaskName $TaskName
}

Et on appelle cette fonction après le renommage de la machine par exemple :

Rename-Computer -NewName $newhostname
createtask(2)

Ainsi, au début du script, on peut placer cette instruction qui appellera la fonction setnetwork dans laquelle le code pour paramétrer la carte réseau sera placé :

if ($step -eq « 2 ») { setnetwork }

La tâche planifiée exécutant le script avec le paramètre -s 2, le script démarrera directement sur cette étape.

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Politique relative aux cookies

Étiquette : Powershell

Powershell : création automatique d’un jeu d’objets de tests ActiveDirectory

J’aime ça :

Powershell : liste des utilisateurs de tous les partages SMB d’un serveur

J’aime ça :

Quelques billes pour automatiser la préparation d’un serveur en Powershell

J’aime ça :

Get-Blog | Select Archives

Get-Blog | Select Stats

Get-Blog | % { Get-Translation }

Partager :

J’aime ça :

Workstations (local)

Serveurs (RDP)

Partager :

J’aime ça :

Partager :

J’aime ça :

Partager :

J’aime ça :

Get-Blog | Select Archives

Get-Blog | Select Tags

Get-Blog | Select Stats

Get-Blog | % { Get-Translation }