Archives For LDAP

Scenario: avevo bisogno di modificare un attributo LDAP secondario, uno di quelli che trovi solo quando abiliti l’opzione “Advanced Features” nella console di Active Directory sul domain controller del tuo ufficio. Il problema è che –almeno su Windows 2008 (R2)– la scheda degli attributi (Attribute Editor) compare solo se apri la scheda utente muovendoti manualmente tra le OU, non la vedi comparire invece se quella scheda la apri in seguito alla ricerca rapida.

VBScript: modificare un attributo di LDAP (esempio d'uso)

Per questo motivo ho accorpato qualche riga di codice VBScript che mi ha permesso di velocizzare l’operazione, sotto un tetto .vbs unico che ti richiederà il nome utente, visualizzerà il valore attuale dell’attributo e ti permetterà di modificarlo con quello che preferisci. Questo esempio d’uso (che è modellato per il mio caso specifico) agisce sul campo “personalTitle“, ma è chiaramente sostituibile con qualsiasi altro campo disponibile (principale o secondario), e in linea di massima lo script è ulteriormente modificabile per fare più operazioni, per effettuare cicli di sostituzioni e molto altro ancora, prendilo quindi solo come base (mancano una serie di controlli di sicurezza, tanto per dire).

Il codice

Pubblicato su Gist per comodità (così lo vedrai sempre aggiornato nel caso in cui ci dovessero essere modifiche future), te lo propongo qui di seguito:

Puoi scaricare il file VBS direttamente facendo clic qui, anche se è più opportuno andare su Gist e fare clic su Download ZIP per ottenere sempre la versione più aggiornata (pulsante in alto a destra, nda).

Per qualsiasi dubbio, consiglio o ulteriore informazione, l’area commenti è sempre a tua disposizione.

Buon lavoro!


Immagine di copertina: unsplash.com / author: Markus Spiske

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:

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:

Powershell_512px-GWallMagari non ve ne frega nulla ma io intanto prendo “appunti pubblici” (quelli che tra qualche tempo mi toccherà venire a rileggere per ripetere il trucco su una diversa macchina) :-) Vi è mai capitato di avere a che fare con account di dominio creati per puro servizio? Quegli account che stanno in piedi per tenere viva una macchina, un processo, qualcosa di assolutamente limitato per il quale non sprecare certo il vostro account o un amministratore di dominio. A me si: una banale copia (robocopy) da eseguire con un’utenza specifica autorizzata a leggere / scrivere su due domini differenti.

Fino ad oggi ho utilizzato (e vi ho spiegato un po’) la PowerShell per utilizzare al meglio il servizio Office 365 e l’amministrazione di Exchange Online ma questa in realtà può essere utilizzata (ovviamente) per fare molto altro, compreso il monitoraggio di un account utente che nel caso in cui si blocchi per troppi tentativi di password (o altro motivo non meglio specificato) può tempestivamente avvisarmi tramite mail al mio account di posta aziendale.

È un trucco relativamente semplice che si ottiene con due mosse: un’apposita operazione schedulata che parte quando viene rilevato un codice evento preciso di sistema e uno script PowerShell che ne raccoglie le informazioni e le invia (come già detto) tramite posta elettronica appoggiandosi ad un SMTP interno che non richiede autenticazione. Questo lo script che ho pubblicato su Gist:

L’operazione schedulata viene eseguita ogni volta che nel sistema si genera un errore 4771 (autenticazione non andata a buon fine) e viene chiaramente demandata ad uno dei domain controller (uno qualsiasi) del dominio dove ho creato l’utenza da tenere sotto monitor:

Operazione schedulata su evento 4771

Se quell’evento viene tracciato dall’event viewer (Visualizzatore Eventi, nei Windows in italiano) partirà allora il mio script in PowerShell (richiamando il programma PowerShell.exe e passandogli come parametro la posizione del file LockoutAD.ps1 che sarà stato precedentemente salvato sul sistema):

Operazione schedulata - Powershell

Il parametro passato completo (non visibile in immagine) è un semplice -nologo -File “C:\Scripts\LockoutAD.ps1” (completo di virgolette, occhio) dove chiaramente quel C:\Scripts andrà sostituito con la reale posizione all’interno della vostra macchina / server. L’operazione andrà eseguita con privilegi elevati (si modifica il tutto dalla scheda General dell’operazione schedulata, ndr) anche nel caso in cui non ci sia nessuno collegato sulla macchina.

Il lavoro è terminato. Potete verificarne la validità e la corretta messa in produzione sbagliando volutamente la password dell’utente tenuto sotto monitor, lanciando un prompt dei comandi di test o semplicemente provando a fare login su qualsiasi macchina in dominio. Ringrazio entrambe le fonti dalle quali è partito tutto: blogs.technet.com/b/heyscriptingguy/archive/2009/04/07/how-can-i-query-event-logs-to-discover-active-directory-information.aspx e community.spiceworks.com/how_to/show/11824-email-account-lock-out-notification.

Condividi l'articolo con i tuoi contatti: