Archives For Event Viewer

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

× Le pillole del Dr.Mario

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:

È uno di quei batch tornati utili in svariati momenti, anche solo per un riferimento singolo, per un’istruzione. L’ho trovato qualche tempo fa su Symantec Connect e ve lo propongo nel caso in cui qualcuno di voi lì fuori ne abbia necessità: symantec.com/connect/downloads/batch-script-check-and-install-application-package

REM ===================DEFINE MSI,MST,UPN,log file & folder here =============
SET MSINAME=SETUP.MSI
SET MSTNAME=SETUP.MSI
SET UPN=AppID-Vendor-AppName-Version-ReleseVersion
SET LOGSFOLDER="C:\ApplicationLogs\%UPN%_Install.log"
IF NOT EXIST "C:\ApplicationLogs" MD "C:\ApplicationLogs"
REM ===========================================================================
REM ===================Check if the Product exists already=====================
SET PRODUCTKEY=HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
REG QUERY %PRODUCTKEY%\{4ECF4BDC-8387-329A-ABE9-CF5798F84BB2}
IF NOT %ERRORLEVEL% EQU 0 (GOTO :INSTALL) ELSE GOTO :ENDHERE
REM ===========================================================================
:INSTALL
REM =======================Install  the application============================
MSIEXEC.EXE /I "%~dp0SETUP.MSI" /TRANSFORMS="%~dp0SETUP.MST" /QB! /L*V "%LOGSFOLDER%"
set MSIERROR=%errorlevel%
if %MSIERROR%==0 GOTO :ENDHERE
if %MSIERROR%==1641 GOTO :ENDHERE
if %MSIERROR%==3010 GOTO :ENDHERE
GOTO :ERROR
REM ===========================================================================
REM ================ Installation successful. Write to Event Log===============
:ENDHERE
EVENTCREATE /l Application /so %UPN%-Install-SUCCESS /t SUCCESS /id 1000 /d "Application installed successfully."
Exit 0
REM ===========================================================================
REM ================ Installation failed. Write to Event Log===================
:ERROR
EVENTCREATE /l Application /so %UPN%-Install-FAILED--(ERROR=%MSIERROR%) /t ERROR /id 999 /d "Application installation failed."
Exit %MSIERROR%
REM ===========================================================================

Il batch si occupa di verificare la presenza di una chiave di registro, permettendovi così di capire se l’installazione di un determinato software è già stata eseguita sulla macchina. In caso contrario, manco a dirlo, la avvierà. Al termine riporterà (in base all’esito dell’operazione stessa) un nuovo evento all’interno del registro (Visualizzatore Eventi) di Windows, così da permettere a chiunque di controllare l’operato dello script.

Comodo, pratico, assolutamente personalizzabile in base alle proprie esigenze.

Buon fine settimana! :-)

× Le pillole del Dr.Mario

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: