Archives For Active Directory

Un dominio contenente più unità organizzative, può avere necessità di creare gruppi di sicurezza con all’interno tutti gli utenti di una specifica OU. Per farlo, esiste il classico metodo manuale della ricerca * all’interno della OU → Seleziona tutti → Aggiungi a un gruppo, in alternativa torna utile la PowerShell e qualche riga di codice che ho recuperato da una vecchia discussione su ServerFault.

Creare un gruppo di Active Directory partendo da una OU

Si tratta infatti di un codice molto banale da comprendere e modificare per le proprie esigenze, utile anche per eliminare persone (avviandolo altre volte nel corso del tempo, non necessariamente in maniera manuale) che in quella OU non esistono più, ma che essendoci state in passato erano state precedentemente inserite all’interno del gruppo di sicurezza.

Spiego rapidamente cosa c’è da ritoccare:

  • $groupname (riga 2): dovrai dichiarare il nome del gruppo al quale aggiungere gli utenti della OU mantenendo gli apici e inserendo al loro interno il percorso completo del gruppo (CN/OU/DC).
  • $users (riga 3): modifica anche stavolta ciò che c’è tra gli apici posti dopo il -SearchBase, dichiarando il nome della OU dalla quale prelevare tutti gli utenti presenti nel momento in cui lanci lo script di PowerShell (OU/DC).
  • riga 11: copia dalla riga 3 ciò che hai appena modificato e incollalo tra gli apici che trovi subito dopo il -notlike. Questa condizione servirà a confrontare gli utenti presenti nel gruppo con quelli nella OU. Nel caso in cui un utente non faccia più parte della OU, verrà rimosso anche dal gruppo.

Lo script, che dovrà essere eseguito con diritti amministrativi sul Domain Controller di interesse, non fornisce alcun output di conferma a video. Una volta lanciato svolge il suo mestiere e tu potrai verificare l’effettiva buona riuscita andando ad aprire il gruppo che dovrà essere popolato partendo dalla OU.

Escludere gli utenti disabilitati

Se vuoi, puoi modificare il primo filtro di ricerca (quello relativo a $users) affinché vengano lasciati fuori gli utenti disabilitati. Si va quindi ad agire sulla riga 3:

$users = Get-ADUser -Filter * -SearchBase "OU=Contoso,OU=Utenti,DC=contoso,DC=local"

mettendo al posto dell’asterisco la specifica che permette di catturare solo gli utenti abilitati in dominio, ottenendo così:

$users = Get-ADUser -Filter {Enabled -eq $true} -SearchBase "OU=Contoso,OU=Utenti,DC=contoso,DC=local"

Schedulazione della modifica del gruppo

Rimane sempre valida la possibilità di richiamare uno script di PowerShell passando per le Operazioni Schedulate di Windows, così da mantenere il gruppo di sicurezza sempre aggiornato, in base a chi si trova all’interno della OU interessata. Per farlo, ti basterà creare una nuova attività di base e specificare il minimo indispensabile (riporto le voci in inglese qui di seguito, utilizzo la medesima lingua che generalmente si usa per i Windows Server installati in azienda):

  • Action: Start a program
  • Program/script: C:\Windows\system32\windowspowershell\v1.0\powershell.exe
  • Add arguments (optional): -command C:\scripts\Gruppo_dipendenti.ps1

(dove C:\scripts\Gruppo_dipendenti.ps1 dovrà essere modificato con la reale posizione e nome file assegnato allo script di PowerShell).

Il tutto è stato testato con successo su Windows Server 2012 R2. Per dubbi o suggerimenti, l’area commenti è a tua totale disposizione :-)

Buon lavoro!

Condividi l'articolo con i tuoi contatti:

Non so se si può parlare di una vera e propria nuova versione. Cambia poco rispetto alla precedente, ma stavolta si può scegliere di controllare lo stato di lock out di un utente direttamente proponendolo da riga di comando, così da poter utilizzare lo stesso identico script e clonare facilmente l’operazione pianificata, così da monitorare contemporaneamente più utenti.

Powershell: LockoutAD.ps1, utente a riga di comando

Cosa cambia quindi rispetto al precedente articolo? Presto detto:

#-----------------------------------------------#
#   ACCOUNT DA MONITORARE:                      #
    Param( 
        [Parameter(Position=0, Mandatory=$false, ValueFromPipeline=$true)] 
        [string] $AccountMonitor
    )
#-----------------------------------------------#

Questo, al posto del precedente $AccountMonitor = 'ACCOUNT_AD', permetterà di richiamare lo script in maniera tale da passargli l’account direttamente dal prompt della PowerShell: .\LockoutAD.ps1 ACCOUNT_AD

Chiaramente, per evitare che ci si dimentichi di specificare l’utente, basterà specificare un valore di default che lo script adotterà nel caso in cui non ci siano parametri, qualcosa del tipo:

 if ([string]::IsNullOrEmpty($AccountMonitor)) { $AccountMonitor = 'ACCOUNT_AD' }

così da tutelare una corretta esecuzione del codice. Questa istruzione andrebbe messa chiaramente dopo il catch del parametro da riga di comando, ma prima di lasciar fare la ricerca dell’evento 4771 (o 4740, in base a ciò che si desidera monitorare).

Tutto il resto può rimanere invariato. Se si intende fare un test di funzionamento senza allertare troppi indirizzi di posta elettronica, si potrà clonare la riga del Send-MailMessage assicurandosi di essere unici destinatari (commentando quella che include quindi eventuali CC o BCC), per poi tornare alla normalità quando si è sicuri che tutto fili liscio.

Magari, in una prossima pillola, ti mostrerò come arricchire ulteriormente lo script, prevedendo uno sblocco automatico dell’utenza di dominio bloccata, così che tu possa analizzare con un attimo più di calma cosa è accaduto e nel frattempo l’utente non si accorga di nulla (o quasi).

A proposito di EventLog e PowerShell

Ho modificato il comportamento dello script perché ho avuto la necessità di clonare l’operazione schedulata sul server di dominio così da tenere d’occhio un differente utente. Per poter approfondire il motivo dei lock di quest’ultimo, ho utilizzato PowerShell per filtrare più rapidamente il log degli eventi di sicurezza, generalmente molto nutrito e che mette un attimo in difficoltà la GUI accessibile tramite Visualizzatore degli Eventi. Per questo motivo ho cercato informazioni in merito e trovato alcuni interessanti spunti su serverfault.com/questions/584309/powershell-and-using-get-eventlog.

Nello specifico, ho filtrato direttamente gli eventi 4740 e 4771 protagonisti dello script, includendo inoltre lo specifico nome utente problematico, tramite una semplice query di questo tipo:

Get-EventLog Security 4771,4740

Che, per filtrare esclusivamente un utente, diventerà:

Get-EventLog Security 4740,4771 -after ((get-date).addDays(-1)) | Where-Object {$_.message -match "NOMEUTENTE"}

Permettendoti così di ottenere a video uno storico completo dell’attività dell’utente specifico, anche quando si tratta di tentativi di accesso molto vecchi (dipende poi dalla quantità di log che tiene il server secondo impostazioni del suo amministratore), ignorando quindi il mio -Newest 1 che nello script permette di prendere in esame solo l’ultimo dei tentativi errati (quello in realtà relativo al blocco dell’account in LDAP).

Buon lavoro!

immagine featured: PowerShell Magazine

×

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

Powershell_512px-GWallFaccio riferimento a un vecchio articolo datato 2014, nel quale vi parlavo di uno script PS1 che avevo lasciato su un Domain Controller della rete per verificare l’utilizzo di una password errata per un determinato account di dominio. Quello script mi è tornato utile ancora una volta e oggi vi propongo il suo ultimo aggiornamento, in grado di monitorare il blocco dell’account di Active Directory, con conseguente mail di allerta a 3 diversi indirizzi di posta (mio e di due colleghi, in CC).

L’originale è ancora disponibile:

Powershell: Account di dominio bloccato o utilizzo di password errata? Mandami una mail con l’evento!

Cosa è cambiato?

L’ID dell’evento sotto monitor, come prima cosa: si tratta del 4740 e l’operazione pianificata si crea ancora alla stessa identica maniera, con l’eccezione del richiamo al prompt di PowerShell che ora utilizzo in maniera classica, passandogli poi parametri da riga di comando che vanno a richiamare il nuovo script:

Nel nuovo script è poi cambiato il testo della segnalazione che arriverà a mezzo mail, la parte commentata (per darle un aspetto migliore, nulla più) e il modo di inviare la mail ai destinatari, che mi permette così di utilizzare anche il -CC e la priorità (-Priority). Già messo alla prova, non fallisce un colpo, permettendo di diventare assolutamente reattivi nei confronti del monitorato “ACCOUNT_AD” (da modificare con l’utente che volete realmente tenere sotto controllo).

Come già detto, l’operazione pianificata sul server riguarderà l’evento 4740, il quale lancerà PowerShell passandogli come parametro lo script che nel frattempo avrete salvato in una cartella sul server (nel mio caso, C:\Script):

Ricordate che, in tutto questo, sarà necessario che la macchina sulla quale farete girare il file PS1 abbia la policy di esecuzione script non firmati, basterà lanciare (da PowerShell):

Set-ExecutionPolicy Unrestricted

e confermare la scelta quando vi verrà chiesto a video.

Con una ulteriore modifica, si potrebbe chiedere allo script di sbloccarlo automaticamente dopo un certo intervallo di tempo. Non l’ho volutamente ancora sviluppato perché non è la richiesta ricevuta, ma nessuno impedisce a voi di completare il quadro (e poi magari toccherà anche a me, probabilmente vi basterà attendere) :-)

Condividi l'articolo con i tuoi contatti:

PowershellProblema posto: recuperare le ACL di tutte le cartelle contenute all’interno di una directory padre, esplodendo e fornendo in chiaro i membri dei gruppi eventualmente presenti e autorizzati in Read Only o Read and Write. Dato che l’utility DumpSec (ex-DumpACL, di Somarsoft) non è poi così infallibile e fatta per filtrare la singola cartella con poco sforzo, ho pensato di passare da Powershell e da un’ottima base fornita in questo articolo: my-powershell.com/export-backup-ntfs-permissions.

Ho quindi costruito un più articolato script intorno a quell’istruzione principale, che possa accettare parametri da riga di comando e permettervi di stabilire se fare un’analisi ricorsiva e su quale file CSV esportare il risultato:

Si ottiene in output un file CSV (già detto) che potrà essere aperto in Excel, così da riuscire poi a organizzare i dati in colonna (sono separati da virgola, nda) e vedere così i gruppi ai quali è stata data un’autorizzazione (sia essa in sola lettura o anche scrittura, o magari solo in Traverse folder). A questo punto basta e avanza una query lanciata da un prompt dei comandi, come questa:

dsquery group DC=contoso,DC=com -name $NOMEGRUPPO | dsget group -members

Dove occorrerà sostituire “contoso” e “com” con il proprio dominio, $NOMEGRUPPO con il vero nome del gruppo del quale si vogliono conoscere i membri, come spiegato in questo post: gohgarry.wordpress.com/2011/06/09/dsquery-export-ad-group-members-to-text.

Per chi se lo stesse chiedendo: si può sostituire l’utilizzo di Powershell con ICACLS. Ci ho provato ma i risultati ottenuti non erano presentabili a un utente che non è solito lavorare con questo tipo di tool. Ho quindi preferito Powershell per la possibilità di esportare in un CSV facilmente editabile e inviabile a mezzo posta elettronica.

Buon lavoro!

Condividi l'articolo con i tuoi contatti:

windows.commandlineUna unità organizzativa in Active Directory dove avevamo raccolto tutti i PC dismessi, lasciati lì non disabilitati in attesa di terminare la pulizia. Quel termine è finalmente arrivato, nel frattempo è passato circa un mese e con un semplice comando nel prompt di DOS si può ottenere facilmente quanto richiesto:

dsquery computer OU=Computers-DACANCELLARE,DC=contoso,DC=com -scope onelevel -inactive 4 | dsmod computer -disabled yes

La query individua tutti i PC che si trovano nella unità organizzativa “DACANCELLARE” (e solo in quella, grazie al “-scope onelevel”, ndr) inattivi da 4 settimane (-inactive 4), disabilitandoli poi in automatico (dsmod computer -disabled yes). Si tratta di un trucco sempre utilizzabile anche variando o omettendo il numero di settimane di inattività con il dominio. Occhio allo scope “onelevel” perché così eviterete brutti scherzi (magari potrebbe capitarvi di andare a disabilitare l’associazione al dominio di qualche server, non si sa mai).

Per conoscere la sintassi di DSQuery potete fare riferimento a SS64, si parla invece di “scope” nel DSQuery sul Social Technet di Microsoft.

Cheers.

×

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti: