Tutti gli articoli di Roberto Massa

Credssp vulnerabilità descritta in CVE-2018-0886

Facebooktwittergoogle_plusredditlinkedin

 

A partire da marzo 2018 secondo questo bollettino di sicurezza viene risolta la vulnerabilità relativa al Credential Security Support Provider protocol (CredSSP)

Con l’aggiornamento di sicurezza di maggio, installato sui vari sistemi che accedono in RDP ad un server non aggiornato, può essere visualizzato il seguente messaggio di errore

20180510-Credssp-Error

in quanto le seguenti KB

  • KB4103718 (Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1)
  • KB4103725 (Windows 8.1/Windows Server 2012R2)
  • KB4103726 (Windows Server 2012)
  • KB4103727 (Windows 10 version 1709)
  • KB4103723 (Windows 10 Version 1607, Windows Server 2016)

“forzano” client ad effettuare un collegamento in RDP esclusivamente verso server su cui sono state installate le patch di sicurezza rilasciate a marzo 2018 che risolvono la vulnerabilità.

l’evento è anche rilevabile sul client dove si è ottenuto l’errore, consultando il registro eventi di Sistema e rilevando l’error ID 6041 LSA

20180510-Credssp-Error-EventvWr

Con l’aggiornamento di sistema viene introdotta una chiave registry che è possibile modificare al fine di accedere ai server non ancora aggiornati, e per i quali risulta difficoltosa l’installazione della patch.

Essendo necessario un riavvio, la sua esecuzione può non essere immediata

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
“AllowEncryptionOracle”=dword:00000002

E’ fortemente consigliato di utilizzare il workaround riportato sopra esclusivamente per il tempo necessario alla completa applicazione delle patch lato server.

 

 

Riferimenti:

https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

https://blogs.technet.microsoft.com/askpfeplat/2018/05/07/credssp-rdp-and-raven/

https://blogs.technet.microsoft.com/yongrhee/2018/05/09/after-may-2018-security-update-rdp-an-authentication-error-occurred-this-could-be-due-to-credssp-encryption-oracle-remediation/

 

 

 

 

 

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

Utilizzo di Azure DNS per la validazione automatica di Let’s Encrypt

Facebooktwittergoogle_plusredditlinkedin

In ICTPower ci siamo occupati a più riprese della Certification Authority Let’s Encrypt, ed abbiamo visto come è possibile utilizzarla in diversi scenari.

In Ambienti OpenSource, con la validazione basata su Apache, In un altro articolo abbiamo proposto lo scenario che si può utilizzare con IIS come base per la validazione.

In questo articolo vediamo quali sono le modalità di validazione per il rilascio ed il rinnovo dei certificati sulla base di ambienti DNS, in questo modo è possibile utilizzare un servizio DNS, anche in hosting, per la gestione del ciclo di vita dei certificati gestiti da Let’s Encrypt. Le procedure proposte si basano sul client Win-Acme (WACS) e quindi in ambiente Windows.

Let’s Encrypt utilizza, analogamente a quanto visto per la validazione tramite servizi WEB, un’automazione che provvede a gestire determinati record all’interno del DNS.

Figura 1 Validazione tramite servizio DNS generico

Nella figura 1 è riportato un esempio di come Win-Acme, tramite le opzioni avanzate, permette di utilizzare il DNS per la validazione.

Nell’esempio sopra Win-Acme ricerca uno script a cui passare “hostname, record name e token“, e se opportunamente eseguito interagisce con il servizio DNS in modo da “scrivere” all’interno queste informazioni che lette dalla CA prima del rilascio del certificato, attestano che il richiedente è il reale proprietario del dominio.

E’ quindi chiaro che la disponibilità da parte del fornitore del servizio DNS ad una gestione automatizzata è fondamentale.

Nel panorama Italiano, Aruba non permette questo tipo di automazione (almeno da richiesta fatta al supporto tecnico nel mese di febbraio 2018), ma come vedremo in seguito questo non è necessariamente un limite.

Esistono diversi gestori di servizi DNS che rilasciano nelle gallery relative alle automazioni, script nati per far interagire i client CertBot con il loro DNS in modo da automatizzare le richieste verso Let’s Encrypt.

La maggioranza delle automazioni finora sono relative ad ambienti Linux.

Nel nostro caso utilizziamo invece Azure-DNS per la validazione da parte della CA, non ci occuperemo di come effettuare la delega al servizio Azure della risoluzione per il dominio, questa attività è trattata in dettaglio in questo articolo e si presuppone sia già stata effettuata.

Prima di procedere con la richiesta del certificato vero e proprio è necessario configurare il servizio Azure-DNS in modo che permetta l’accesso ad un “utente” con le credenziali minime per poter creare e cancellare record all’interno del Database DNS.

Questa tipologia di accesso è possibile con la creazione di un Service Principal Account
che possiamo definire come una identità di livello applicativo.

     Assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.

Per poter creare una identità di questo tipo possiamo utilizzare Azure Powershell e con l’utilizzo di alcune command let procedere alla sua creazione, l’accesso all’ambiente PS avviene direttamente dal portale Azure

Figura 2 accesso alla Cloud Shell

La preparazione dell’ambiente non è immediata e può richiedere anche più di un minuto, terminato l’accesso, disponiamo di un ambiente comandi direttamente sulla sottoscrizione.

Per procedere alla creazione del Principal account che verrà utilizzato per l’automazione è sufficiente utilizzare questi comandi

$Password = ConvertTo-SecureString -String “InserireQuiLaPassword” -AsPlainText -Force

New-AzureRmADServicePrincipal -DisplayName LetsEncrypt -Password $Password

Figura 3 creazione del service principal

In questo modo è stato creato l’account “Letsencrypt” con la relativa password ed è necessario assegnare i permessi di accesso alla zona DNS relativa al dominio per il quale stiamo richiedendo il certificato

Figura 4 attribuzione dei permessi

Accedendo alla gestione della zona robimassa.cloud tramite Access Control (IAM) si attribuisce il ruolo di DNS Zone Contributor al Service Principal Letsencrypt creato in precedenza.

La preparazione dell’ambiente relativo al servizio DNS è completata e prima di procedere alla generazione del certificato è utile recuperare alcune informazioni che saranno poi richieste dal client Win-Acme.

  • Tenant ID (directory ID) ossia l’identificativo della Directory a cui ci stiamo riferendo
  • Client ID l’identificativo del Service Principal creato prima
  • Secret la password definita per il Principal
  • DNS Subscription ID l’identificativo del Servizio DNS in questo caso (robimassa.cloud)
  • DNS Resource Group Name il resource group definito per la risorsa DNS pubblica

In questa guida si fa riferimento al dominio robimassa.cloud, forse è superfluo specificarlo, ma il dominio DEVE essere un dominio pubblico regolarmente raggiungibile e quindi acquistato tramite i normali canali commerciali, nello specifico questo dominio è stato acquistato da Aruba.

Generazione del certificato

Il client Win-Acme dovrà essere eseguito con l’opzione –centralsslstore in modo da permettere l’archiviazione dei certificati (SAN o singolo Host) all’interno di una cartella, questo è necessario nel nostro caso in quanto i certificati rilasciati non vengono associati in automatico ad un Host Web, ma sono archiviati per un utilizzo successivo.

letsencrypt.exe –centralsslstore C:\letsencrypt-san\

vengono richieste a questo punto le impostazioni di base che sono quelle viste in figura 1 ad eccezione della validazione, per la quale dovremo selezionare l’opzione 1 ossia [dns-01] Azure DNS

Figura 5 richiesta validazione su Azure DNS

Proseguendo dovremo fornire le indicazioni relative all’accesso automatico del client come riportato sopra, ed al termine completata l’esecuzione, verranno salvati i certificati nella directory.

Figura 6 richiesta certificato

A questo punto il certificato è correttamente salvato in formato pfx e disponibile ad essere utilizzato, può ancora essere definito un utente con cui verrà eseguita periodicamente la task di rinnovo.

Se fosse necessario verificare i certificati emessi è possibile, sempre client Win-Acme la procedure di verifica.

Figura 7 verifica dei certificati emessi

Riferimenti

Configurare e gestire Azure DNS

Facebooktwittergoogle_plusredditlinkedin

Nella varietà di scelta tra i servizi disponibili all’interno di Azure troviamo il servizio DNS, in realtà non è un vero e proprio servizio offerto come registrar, in quanto non permette la registrazione di un dominio, ma permette di operare come server delegato.

Per poter registrare un qualunque dominio, dovremo, come fatto finora, riferirci ad un operatore di mercato, presso il Nic è disponibile un elenco di Aziende che operano come Registrar a livello italiano.

Le varie Aziende che operano in questo settore mettono a disposizione i vari servizi di registrazione.

Normalmente viene anche messo a disposizione un pannello tramite il quale è possibile gestire i vari record riferiti al dominio.

Abbiamo già detto che Azure in questo contesto opera come “delegato” ossia vengono reindirizzate le varie query sui DNS server a fronte di una esplicita delega sul Name Server principale per mezzo della definizione di un NS record secondo la RFC 1035.

Apparentemente questa configurazione può apparire inutile ed effettivamente non sempre è necessario o utile attivare i Name server di Azure in delega. Tuttavia alcune necessità, come ad esempio l’automazione richiesta da Let’s Encrypt per la validazione sulla base DNS, possono richiedere che l’aggiunta, la cancellazione o la modifica di record possano avvenire in modo automatico.

Quindi se il registrar presso il quale abbiamo registrato il nostro dominio non avesse queste funzionalità, possiamo utilizzare Azure-DNS in quanto servizio completamente automatizzabile.

Nell’esempio utilizzato per questo articolo deleghiamo i Name Server di Azure per la risoluzione del dominio robimassa.cloud ospitato presso Aruba

Creazione della zona delegata su Azure

Dalla creazione risorse è necessario scegliere DNS zone

Figura 1 creazione zona delegata su Azure DNS

Nel campo nome è necessario specificare il nome completo del dominio, specificare la sottoscrizione di riferimento ed eventualmente il nome del resource group da creare per la risorsa DNS. Nel caso di una zona su cui sarà necessario definire script di automazione è possibile creare un resource group dedicato in modo da “confinare” la risorsa.

Figura 2 creazione zona delegata su Azure DNS

Terminata la configurazione della zona DNS è possibile procedere alla creazione dei vari record già presenti nel servizio “principale” in modo da non creare interruzioni nella risoluzione dei nomi quando verrà attivata la delega.

Figura 3 creazione dei record relativi al dominio

Sono anche disponibili le informazioni relative ai name server da impostare per la delega sul DNS principale che dovranno poi essere usate successivamente.

A questo punto la nuova zona delegata è pronta ed è sufficiente procedere con la configurazione dei record NS su name server del Registrar.

Configurazione del Record NS sul portale del Registrar

Il dominio robimassa.cloud è stato registrato tramite Aruba che ne è quindi il registrar e tramite il quale è possibile gestire i vari record. La prima impostazione è relativa a quale è il name server principale per la zona e quindi per attivare la delega è necessario impostare l’uso di name server esterni.

Figura 4 pannello di gestione del DNS per robimassa.cloud

E successivamente dovranno essere creati i vari record NS secondo le informazioni ricavabili dal servizio Azure-DNS per la zona robimassa.cloud

Figura 5 impostazione record NS

A questo punto, atteso il tempo di replica tra i vari DNS globali le nuove informazioni ed impostazioni diventano operative

Figura 6 verifica delega con Nslookup

Nel caso in cui sia necessario delegare la gestione del dominio DNS sarà sufficiente creare un utente e successivamente attribuire i permessi minimi sul servizio

Figura 7 definizione accesso al servizio

Controllo delle attività sulla zona DNS

Accedendo ad “Activity Log” è possibile consultare tutte le attività eseguite sulla zona

Figura 8 consultazione Log

Riferimenti

Azure Dns Prezzi

Informazioni generali su Azure DNS

Generazione di certificati SAN con Let’s Encrypt ed utilizzo in Microsoft Exchange

Facebooktwittergoogle_plusredditlinkedin

Come abbiamo già avuto modo di analizzare in articoli precedenti, Let’s Encrypt, in quanto CA, permette anche il rilascio di certificati di tipo SAN (Subjet Alternative Names), ossia certificati che sono emessi e quindi sono validi per più nomi host di uno stesso dominio oppure per nomi host differenti di domini differenti.

La possibilità di ottenere certificati come indicato, non è da confondere con l’emissione di certificati di tipo Wildcard (*) ossia di un certificato valido per tutti gli host di un singolo dominio

Sono esempi di certificati di tipo SAN rilasciati da Let’s Encrypt i seguenti

  • mail.robimassa.cloud
  • autodiscover.robimassa.cloud

esempi di certificati per uno stesso dominio ma per host differenti

  • web.robimassa.it
  • portale.robimassa.cloud

esempi di certificati per host in domini differenti.

Per quanto riguarda i certificati Wildcard, Let’s Encrypt ha annunciato che nel gennaio del 2018 avrebbe emesso questo tipo di certificati, ma recentemente stato pubblicato un annuncio che informa dello slittamento del rilascio di questa funzione.

Exchange può utilizzare certificati di questo tipo emessi da Let’s Encrypt

Nel caso di questo sevizio, per l’accesso alle risorse mail dobbiamo dichiarare in DNS un record di tipo “A” riferito al portale webmail, ed un record, sempre di tipo “A” con nome autodiscover

Per una descrizione più dettagliata sull’uso e sulla funzione di questa informazione dichiarata in DNS è possibile leggere l’articolo Autodiscover service

In modo molto semplicistico possiamo dire che l’informazione ottenuta con “autodiscover” sia essa in un record di tipo A o in un record di tipo SRV permette una identificazione automatica di risorse di servizi di collaborazione come Exchange a partire da un indirizzo mail in formato utente@dominio.com.

Fatta questa premessa, passiamo ad analizzare in quale modalità è possibile ottenere certificati di tipo SAN con Let’s Encrypt

In ambiente Windows è utilizzabile il tool Let’s Encrypt-win-simple di Lone Coder, che proprio recentemente ha cambiato il nome del proprio programma

New name

This is the first release of this program under a new name. Going forward we will call it “Windows ACME Simple”, which can be shortened to “win-acme” or “WACS”. The reason is that we want to avoid any confusion people might have about this programs relationship with the ISRG sponsored Let’s Encrypt project.

To be clear, we are not an ISRG supported client, just an independent group of people who want to help people managing Microsoft Windows machines to secure the web.

Let’s Encrypt literally wrote the book on the ACME protocol and is obviously the most popular service implementing it, but in fact everyone is free to run their own ACME server and we might see a lot more of them in the future. Therefore it also makes sense to drop “Let’s Encrypt” from the name of this program.

Per effettuare la richiesta del certificato alla CA è necessario scaricare il tool da github e copiarlo localmente per poi estrarre il contenuto.

Il client ACME (Automatic Certificate Management Environment) quale è appunto win-acme, è gestibile a riga di comando, pertanto dovremo prima creare una cartella in cui saranno salvati i certificati in formato .pfx rilasciati dalla CA e successivamente eseguire il comando letsencrypt.exe –centralsslstore C:\letsencrypt-san\

L’opzione –centralsslstore è utilizzata per
definire il percorso per il salvataggio dei certificati che dovranno poi essere importati in Exchange tramite Powershell

Figura 1 richiesta certificato

Dovremo selezionare la modalità per il rilascio di nuovi certificati con opzioni avanzate “M” e successivamente specificare i vari nomi fqdn per cui stiamo richiedendo i certificati, ognuno separato da virgola nell’esempio che è indicato la richiesta è per l’host mail.robimassa.cloud ed autodiscover.robimassa.cloud

Figura 2 Impostazioni per la validazione

Successivamente verrà chiesta la modalità di validazione, ed il modo più rapido, se si esegue la richiesta dei certificati da un server IIS, è di consentire la verifica automatica direttamente tramite il server Web.

Procedendo con la richiesta vera e propria, e conclusa la procedura, nella cartella C:\letsencrypt-san\ troviamo i due certificati in formato PFX, uno per sito.

Sarà sufficiente procedere all’importazione del certificato in IIS che verrà utilizzato per OWA

Figura 3importazione certificato in IIS

Oppure in caso di sistemi distribuiti su più Web Server Bilanciati, utilizzare la funzione di centralized ssl certificate support a questo punto il https è attivo con il certificato SAN segnato per i due host

Importazione del certificato in Exchange

Per quanto riguarda invece l’importazione dei certificati in Exchange sarà necessario eseguire il cmd-let Powershell Import-ExchangeCertificate come descritto in questo articolo.

Metodi di validazione alternativi

Esistono altri metodi di validazione da parte di Lets’Encrypt per determinare che il richiedente del certificato sia effettivamente il proprietario del dominio, uno di questi è il metodo basato su DNS.

Il client Acme in questo caso si deve “appoggiare” ad un programma esterno che ricevendo in input I parametri corretti si occupa di creare sul DNS il TXT record opportunamente configurato. Questo record, sarà poi letto dalla CA prima dell’emissione dei certificati.

Siccome il processo di rinnovo è automatizzato e quindi eseguito periodicamente alla scadenza dei certificati, il servizio DNS deve poter consentire un interoperabilità di questo tipo.

E’ consigliabile quindi la verifica della disponibiltà di automazione da parte del DNS.

Figura 4 validazione tramite DNS

Figura 5 certificato SAN

Considerazioni

Anche in questo caso Let’s Encrypt si dimostra una Certification Authority che in modo gratuito permette di attivare i protocolli di sicurezza sui propri servizi. Come già detto in precedenza, è di prossimo rilascio l’emissione di certificati WildCard, che completerà l’offerta dei servizi della CA.

Riferimenti

https://letsencrypt.org/

https://www.ictpower.it/guide/utilizzo-e-configurazione-di-lets-encrypt-in-ambiente-linuxapache.htm

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

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