Ormai è chiaro che i miei articoli sono mossi fondamentalmente da un uno spirito di “solidarietà” verso gli amici amministratori che spesso come me, hanno avuto a che fare con chi gli ha contestato alcune anomalie e/o “errate configurazioni” negli ambienti operativi. Il sistemista classico, è un individuo molto orgoglioso del suo operato. Questo orgoglio risulta poi particolarmente marcato se l’esperienza nel mondo dell’ICT nasce dai primi passi su home computer e sistemi 8086. Insomma per dirla in parole povere, attenzione a discutere con un SysOP (per dirla alla Speghetti Hacker) perchè il tutto si potrebbe risolvere in una serie di botte e riposte al vetriolo. Comunque sia, l’informatica non è più una cosa condivisa tra vecchi dinosauri e ratti da tastiera. L’autismo da nerd non è più un qualcosa di innato, ma al contrario è diventato una costrizione al fine di “efficientare” i processi produttivi nel millennio digitale in cui viviamo. Figure di controllo, normative, compliance e via dicendo, sono ormai diventate vere e proprie minacce per le menti creative dei sistemisti, che alla fine sono costretti a rendere conto del loro operato e a denti stretti “correggerlo” li dove viene evidenziata una non conformità. Facendo appunto un esempio, se per anni si è utilizzata un immagine standard per il rapid deployment di un sistema e se poi questa immagine ha al suo interno degli account con una password preconfigurata (che sarà ovviamente sempre la stessa) perché ora esiste qualcuno che contesta questa cosa? Semplice! Perchè questa prassi risulta avere una vulnerabilità (stessa password di default per tutti i sistemi magari per l’utente administrator). Effettivamente sarebbe necessario fare un esame di coscienza ed è qui che il sistemista, pur non ammettendo la cosa, decide di trovare una soluzione ovviamente custom. Io mi metto quindi una mano sul cuore e proverò a condividere questo lavoro umile che sicuramente potrà essere migliorato…
Function SetPassLocalUsr([string]$ComputerName,[string]$LocalUser,[int]$Lengh) {
Import-module activedirectory
$User = [ADSI] "WinNT://$ComputerName/$LocalUser"
$NewPass =''
$Count=0
do{
$AsciiVal = Get-Random -InputObject(48..93)
$NewPass = $NewPass+[char]$AsciiVal
$Count++
}
until($Count -eq $Lengh)
$User.setpassword($Newpass)
Set-ADComputer -Identity $ComputerName -Description $NewPass
}
Questa funzione è molto semplice ma è stata utile fondamentalmente per due motivi. Per prima cosa ho evitato di chiedere budget per acquistare prodotti “enterprise” di terze parti e secondo mi ha evitato di fare incontri con noiosi commerciali che ti cercano di vendere architetture multi layer improponibili, mentre tu pensi al fatto che devi uscire prima, per passare a comprare i pannolini e un etto di prosciutto cotto naturale e senza conservanti.
Provo ad entrare nel concreto 🙂 La funzione prende tre parametri di input, il primo è ovviamente il sistema target su cui operare, il secondo è l’utente in cui operare e il terzo parametro è la lunghezza della password (Non entrato nel merito della complessità, perché ho voluto già darla per scontata).
Per prima cosa ho instanziato un oggetto ADSI su l’utente $Localuser. Viene poi creata una password random tramite un ciclo do until:
1) Viene estratto un valore Ascii in maniera random dal codice 48 al codice 93.
2) La variabile $NewPass viene popolata con il valore generato dal punto precedente (da notare il cambio di tipo Char).
3) Il counter viene incrementato di un unità.
4) Il ciclo infine viene ripetuto fintanto che il valore $Count sarà uguale al valore definito nella variabile della lunghezza $Lengh
All’uscita del ciclo la nuova password sarà stata definita nella variabile $NewPass e verrà configurata tramite il metodo setpassword dell’oggetto $User.
A mio avviso l’ultima riga di codice farà la differenza. Con il cmdlet la funzione andrà infatti a salvare la password all’interno del campo Description dello specifico oggetto computer. Per sicurezza ho caricato il modulo di Active Directory inizialmente, per poter utilizzare il cmdlet.
A questo punto per poter accedere localmente al sistema, basterà recuperare la password direttamente dalla console di AD (il quale accesso immagino sarà consentito solo al personale autorizzato).
Suggeriso infine di utilizzare il codice all’interno di un ciclo “foreach” dove viene eseguita una query per recuperare i sistemi su qui configurare la password.
Lanciate poi lo script magari una volta al giorno, cosi da avere sempre password fresche e cosi facendo probabilmente avrete risolto un problema e sarete più sereni quando andrete come me a prendere i pannolini 🙂
interactivebug.com 