Archivi categoria: Senza categoria

Watchguard Autenticazione Accesso su Active Directory

Facebooktwittergoogle_plusredditlinkedin

La gestione delle autenticazioni in un ambiente aziendale è utile in quanto consente in modo centralizzato di consentire ai vari utenti di accedere alle varie risorse anche per un limitato periodo di tempo.

In questo scenario Active Directory, in quanto repository centralizzato di utenti può essere utilizzato anche come sorgente di autenticazione per dispositivi quali Firewall, apparati di rete ed altro.

In questo articolo analizziamo come è possibile configurare Watchguard in modo che utilizzi l’Active Directory centralizzata al fine di definire utenti che possono effettuare l’amministrazione del Firewall stesso, oppure, sempre tramite AD consentire l’accesso tramite VPN SSL definite sul Watchguard.

Definizione delle sorgenti di autenticazione

Tramite l’accesso di gestione per mezzo del portale Web ( https://”ip-delFirewall”:8080) dal menù Authentication/Servers è possibile la scelta tra una serie di sorgenti di autenticazione, nel nostro caso utilizzeremo Active Directory.

Figura 1 Selezione Sorgente di Autenticazione su AD

A questo punto selezionando Active Directory procederemo con ADD e successivamente dovremo fornire le varie informazioni relative al dominio, o meglio ad un Domain Controller Primario e ad un DC secondario che verrà usato come alternativa in caso di indisponibilità del primario, dovremo poi specificare la “Search Base” relativa all’LDAP, è possibile specificare una particolare OU di ricerca per gli utenti.

I campi Group String e Login Attribute specificano le informazioni relative all’account di accesso sull’AD ( nel nostro esempio sono utilizzati i valori di dafault), è poi possibile specificare anche se la connessione avverrà tramite il protocollo LADP(s) ossia in modalità cifrata.

Figura 2 definizione del riferimento al Dominio di autenticazione

Se per ragioni di configurazione il FireBox non raggiungesse un DNS a conoscenza del dominio locale, è possibile specificare l’indirizzo IP dell’Domain Controller anziché il suo FQDN.

Proseguendo si procede al salvataggio della sorgente di autenticazione per il dominio, è comunque possibile definire più di un riferimento di autenticazione in modo da permettere ad utenti differenti di accedere tramite lo stesso dispositivo.

Verifica della configurazione

Terminato il salvataggio è possibile effettuare un test delle impostazioni, dove verranno richiesti utente/password di un account presente in AD

Figura 3 test dell’autenticazione su AD

Figura 4 risultato autenticazione corretta

Definizione dei permessi di accesso in VPN ad utenti AD

A questo punto si può procedere con l’attribuzione dei permessi di accesso in VPN SSL ad utenti residenti su Active Directory , con le impostazioni definite prima l’accesso avviene secondo l’appartenenza di un utente ad un gruppo definito in modo puntuale su AD, nel nostro esempio il gruppo i chiama SSLVpnAdmins

Figura 5 attivazione servizio VPN SSSL

Figura 6 impostazione del Gruppo e del server di autenticazione

Nelle impostazioni relative all’autenticazione, dovremo definire il gruppo AD sulla base del quale è consentito l’accesso agli utenti e dovremo anche configurare il server di autenticazione impostato in precedenza.

Figura 7 impostazione del nome gruppo

Nella figura 7 è riportata la modalità con cui è possibile definire il nome del gruppo che, in relazione al server di autenticazione verrà poi ricercato in Active Directory

Terminate le configurazioni viste sopra è possibile autenticarsi al Firebox direttamente al Portale Vpn Ssl con le credenziale definite su Active Directory è necessario in fase di accesso selezionare il dominio AD di riferimento nella forma.

Figura 8 accesso portale VPN

Definizione dei permessi di amministrazione del Firebox

Sempre sulla base delle autenticazioni analizzate in questo articolo è possibile fare si che determinati utenti di AD possano anche essere, o avere ruoli di amministrazione sul Firewall, i vari ruoli sono accessibili dal menù System/Users and Roles da cui è possibile attribuire i vari ruoli sulla base di un determinato utente dichiarato in Active Directory

Figura 9 definizione dei ruoli di gestione

Figura 10 impostazione del nome utente

Automazione dell’Avvio/Arresto di VM in Azure

Facebooktwittergoogle_plusredditlinkedin

 

Nella gestione dell’infrastruttura aziendale può essere normale dover configurare servizi che per i motivi più disparati necessitano di essere attivi per poche ore al giorno o per poche ore al giorno in pochi giorni la settimana.

A questo punto è utile poter gestire l’avvio e l’arresto automatico di determinate VM.

Dal punto di vista della sicurezza il mantenere attiva un VM espone i servizi ad attacchi, questo a prescindere che il Workload sia attivo internamente oppure in Cloud, quindi il mantenere spento un servizio che non deve essere utilizzato è sicuramente una considerazione che si può fare anche in termini di sicurezza.

Se la VM è attiva in Cloud l’aspetto del tempo di esecuzione è ancora più importante in quanto permette notevoli risparmi sui costi della gestione della sottoscrizione.

In Azure è possibile gestire senza particolari complessità un evento si spegnimento di ogni VM al giorno definendo anche l’invio di notifiche dell’evento.

Figura 1 Vm AutoShutdown

Tuttavia non è possibile con la medesima impostazione definirne ad esempio il riavvio, così come operazioni multiple, per questo tipo di attività è necessario agire tramite un Account di Automazione e la gestione al suo interno dei vari RunBook ai quali vengono poi applicate una o più pianificazioni la relazione tra le varie entità è la seguente

Account di Automazione – RunBook- Schedulazione

Il RunBook può essere generico ossia prevedere in fase di “chiamata” il passaggio parametri, ad esempio il nome del Wokload, e l’attività da eseguire ( Avvio/Arresto) oppure può contenere al suo interno già i parametri preconfezionati per un particolare VM ed una particolare azione.

Creazione di una attività pianificata

Per prima cosa è necessario creare un Automation Account dalla pagina principale di gestione della sottoscrizione

Figura 2 Selezione del Servizio

Figura 3 Creazione dell’Automation Account

A questo punto è possibile creare l’Account di Automazione definendo un nome ed eventualmente un Resource Group di riferimento completando poi la procedura con CREATE

Figura 4 Accesso alle Schedulazioni

Completata la creazione dell’automazione è possibile creare prima le schedulazioni, in realtà, come vedremo sarà possibile anche crearle successivamente, in questo caso creeremo una schedulazione impostata alle 7 dei giorni lunedì mercoledì e venerdì per procedere è sufficiente selezionare Schedules e poi confermare la scelta successiva

Figura 5 Creazione di uno Schedule

La schedulazione è impostata e con create la definiamo, una volta creata questa non è associata ad alcuna operazione, attività che faremo successivamente.

Il passo successivo prevede la creazione di un RunBook ossia del flusso di operazioni da eseguire, al quale andrà agganciata la schedulazione creata sopra nella pagina di creazione esistono già preconfezionati dei RB Tutorial

Figura 6 Creazione del RunBook

Figura 7 Creazione del RunBook (dettaglio)

 

Figura 8 Esempio di codice per Avvio/Arresto VM

Terminata la creazione, la Dashboard di Azure si posiziona in modo da consentire l’immissione dei vari comandi, il codice per l’esecuzione del comando di Avvio/Arresto di una VM può essere simile al seguente:

 

Ed è sufficiente copiarlo ed incollarlo direttamente nella pagina di creazione del RunBook

Figura 9 Definizione del Codice

È necessario salvare e pubblicare il RunBook, importante ricordare che questo deve sempre essere pubblicato per diventare operativo

A questo punto è necessario associare la Schedulazione creata in precedenza

Figura 10 definizione della schedulazione associata al RB

Figura 11

E successivamente definire i “parametri” di esecuzione che sono individuati direttamente dallo script tramite il pannello di gestione di Azure

Figura 12 Definizione dei Parametri passati allo script

A questo punto dalla dashboard di azure possiamo monitorare lo stato di esecuzione del RunBook e dei parametri passati in esecuzione.

Come abbiamo visto in questa modalità, tramite il passaggio di parametri allo script  possiamo utilizzare il RunBook per differenti VM e per azioni di spegnimento, tuttavia se volessimo potremmo ” Cablare ” direttamente nello script il parametri voluti in modo da rendere l’esecuzione strettamente legata alla VM, la scelta di una o altra modalità è personale e dipende anche numero di azioni e di VM che esistono.

Controllo delle attività del RunBook

Tutte le attività eseguite dal RunBook sono consultabili, dalla pagina Jobs del portale

Riferimenti:

https://docs.microsoft.com/it-it/azure/automation/automation-starting-a-runbook

https://docs.microsoft.com/en-us/azure/automation/automation-create-standalone-account

MeetUp TTG a Torino il 15 febbraio 2018

Facebooktwittergoogle_plusredditlinkedin

Io ed Ermanno Goletto giovedì saremo ospiti del meetup del 15 febbraio organizzato da Torino Technologies Group in cui analizzeranno in modo dettagliato i componenti di Active Directory e il loro impatto sul sistema in caso di malfunzionamento. Inoltre verranno approfondite le Best Practices e gli strumenti a disposizione nelle varie versioni di Windows Server per eseguire il troubleshooting e il disaster recovery di Active Directory.

LastLogon, LastLogonTimeStamp, LastLogonDate. Utilizzo degli attributi per la rilevazione di oggetti “Stale” in AD PS CMD-LET Search-ADAccount

Facebooktwittergoogle_plusredditlinkedin

Ognuno degli attributi presenti è utile per la rilevazione di quelli che sono gli oggetti scaduti o Stale all’interno di un’infrastruttura AD.

Sono utili quindi per determinare se un utente o un computer hanno effettuato un logon al dominio e nel caso basarsi su questo valore temporale per eventualmente eliminare i vari oggetti utente o computer non più utilizzati e che possono essere fonte di brecce nella sicurezza di un’infrastruttura AD.

Gli oggetti utente e computer hanno diversi attributi che riportano informazioni relative ad eventi di logon/logoff

LastLogon

Prima della versione 2003 di Windows Server era disponibile l’attributo LastLogon per determinare il reale evento di logon di un utente o macchina.

Il valore era aggiornato solo nel Domain Controller che effettivamente validava la richiesta di accesso.

L’attributo, che è ancora presente nelle versioni successive, non è replicato, quindi per effettuare una verifica basandosi su questo è necessario effettuare una query su ogni DC del dominio e considerando il più recente come valido.

Con le successive versioni di Sistema Operativo il significato ed il meccanismo di replica di questo attributo non è stato modificato.

In buona sostanza il valore contenuto in LastLogon si può considerare come assoluto soltanto se si dispone di un dominio con un solo Domain Controller.

1 attributo LastLogon su ambiente con più di un DC ed autenticazione non avvenuta sul DC interessato dalla query

LastLognTimeStamp

Nelle versioni di Windows Server dalla 2003 in poi è disponibile un nuovo attributo che è replicato tra tutti i DC, questo riporta in modo univoco il valore temporale espresso in FILETime, ossia il numero di intervalli di 100 nanosecondi che intercorrono tra il “momento” attuale ed il 1° gennaio 1601 riferito ad UTC.

2 attributo LastLogonTimeStamp sul medesimo DC e per lo stesso evento di Logon

Troveremo quindi un valore numerico all’interno di una variabile di tipo INT64, tale valore dovrà poi essere elaborato per poter essere letto nel formato data/ora classico.

È possibile con il comando w32tm /ntte eseguire una rapida conversione del valore contenuto nell’attributo

Fatte le considerazioni precedenti, in relazione alla differenza tra i due attributi, è possibile verificare tramite l’utility Repadmin, l’effettiva replica su tutti i DC degli attributi visti prima.

repadmin /showattr * “CN=Utente Test,OU=Test,DC=dominio,DC=loc /attrs:lastLogontimeStamp”

3 replica dell’attributo lastLogonTimeStamp

Questo attributo è replicato sui vari DC e popolato con lo stesso valore

mentre il valore dell’attributo LastLogon rilevato sempre con Repadmin riporterà esclusivamente il DC che ha effettuato l’autenticazione dell’oggetto.

Questo attributo può riportare informazioni non attuali, infatti è replicato secondo il valore impostato in un ulteriore attributo

ms-DS-Logon-Time-Sync-Interval attributo espresso in giorni da 1 a
100.000

This attribute controls the granularity, in days, with which the last logon time for a user or computer, recorded in the lastLogonTimestamp attribute, is replicated to all DCs in a domain.

Di default questo non è impostato e per valore predefinito è considerato pari a 14 giorni, l’aggiornamento del dato avviene in caso di logon e se questo valore è precedente alla data/ora attuale diminuita del valore in msDS-LogonTimeSyncInterval,

La sincronizzazione iniziale dopo l’elevazione del livello funzionale del dominio è calcolata come 14 giorni diminuita di un valore percentuale casuale di 5 giorni

4 stato dell’attributo LastLogon su tutti i DC

(è da notare che l’utente scelto per questa dimostrazione è stato creato ex novo ed ha eseguito un solo accesso)

Tramite ADUC è possibile visualizzare il valore convertito di questo attributo

Per attivare la visualizzazione degli attributi è necessario attivare la funzionalità di visualizzazione avanzata all’interno di ADUC

 

 

 

 

 

 

ADUC riporta la conversione del valore numerico in formato data/ora mentre la visualizzazione diretta del contenuto evidenzia il valore numerico

LastLogonDate

Un ulteriore attributo messo a disposizione per rilevare le attività di accesso di un oggetto macchina oppure utente è LastLogonDate, che è un valore calcolato localmente in relazione alla replica dell’attributo LastLogonTimeStamp.

Viene cioè convertito in data/ora il valore numerico dell’attributo LastLogonTimeStamp localmente ad ogni server e salvato nell’attributo LastLogonDate, risulta quindi utile in quanto permette di calcolare direttamente le differenze data senza la conversione necessaria con LastLogonTimeStamp.

Ad esempio risulta più semplice rilevare con un calcolo dinamico rispetto alla data odierna gli utenti che non eseguono accesso da più di n giorni

get-aduser -filter -properties Name,LastLogonDate |
Where-Object {$_.LastLogonDate -ge (get-date).adddays(-400)}

Search-ADAccount Powershell Cmd-Let

Finora abbiamo visto come una serie di attributi ed i valori in essi contenuti ci possono aiutare per la rilevazione in AD di alcune anomalie, come ad esempio oggetti non utilizzati.

In questo contesto powershell ci ha permesso di interrogare gli attributi interessati e di rilevarne il valore per poi determinare le nostre azioni.

In modo più strutturato, in PS è disponibile un cmd-let che è in grado di rilevare agevolmente quelli che sono gli Stale-Object.

Il command-let Search-ADAccount è utile per rilevare le informazioni di scadenza, blocco etc. relative ad un oggetto che effettua attività di logon al dominio Utenti, Computer o Service Account

Esempi:

Rilevazione di oggetti computer non attivi da più di 90 giorni

Search-ADAccount -ComputersOnly -AccountInactive | ? { $_.LastLogonDate -lt (get-date).AddDays(-90) } | Select-Object Name,LastLogonDate,DistinguishedName

Rilevazione di oggetti utente non attivi per più di 90 giorni

Search-ADAccount -AccountInactive -UsersOnly | ? { $_.LastLogonDate -lt (get-date).AddDays(-90) } | Select-Object Name,SAMAccountName,LastLogonDate,Enabled,LockedOut,PasswordExpired

Riferimenti

Microsoft Virtual Academy considerazioni sugli oggetti scaduti

Attributo LasLogonTimeStamp

Attributo LastLogon

Articolo Technet