Identificare la tipologia di Sistema Operativo tramite WMI

 

Nell’applicazione delle Group Policy, piuttosto che in ambiti differenti, può essere necessario applicare determinate impostazioni, o rilevare in modo puntuale la tipologia di Sistema Operativo.

Tramite un apposito filtro applicato all’ambiente WMI è possibile rilevare se il sistema è un Client, un server e se si tratta di un server, se questo è un Domain Controller oppure un sistema Server comune

Il valore da identificare è la Proprietà Product_Type relativa alla classe Win32_OperatingSystem il cui contenuto è un valore di tipo uint32

La proprietà può contenere i seguenti valori

  • 1 Work Station
  • 2 Domain Controller
  • 3 Server

Una semplice query può essere strutturata in questo modo

select ProductType from Win32_OperatingSystem

e può essere eseguita con il tool WbemTest

Figura 1 risultato della query su un DC

Ed è inoltre possibile rilevare lo stesso valore tramite il comando VMIC

wmic os get ProductType /value

 

Figura 2 valore rilevato con WMIC

 

 

Definizione di un Filtro WMI da applicare ad una GPO

Avendo presente la struttura WMI interrogabile con i due tool riportati sopra è possibile costruire una query che verrà applicata ad una GPO, in modo che questa venga applicata esclusivamente in caso di un confronto positivo con la query effettuata

select * from Win32_OperatingSystem where ProductType=”1″

la query sopra su un filtro WMI applicato ad una GPO permette l’applicazione della stessa solo in caso di un sistema operativo di tipo “Client”

 

Figura 3

Figura 4 creazione del filtro e relativa query

 

 

Riferimenti

https://docs.microsoft.com/en-us/windows/desktop/CIMWin32Prov/win32-operatingsystem

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc947846(v=ws.10)

https://blogs.technet.microsoft.com/askperf/2012/02/17/useful-wmic-queries/

 

 

Annunci

GESTIONE DELLE REGOLE DI CONSERVAZIONE DEI DATI SU AZURE LOG ANALITYCS

 

Azure Log Analitycs è la soluzione di gestione dei vari log collezionati localmente o sulle infrastrutture in cloud, che matte a disposizione dell’utilizzatore un motore di analisi e di ispezione dei log stessi molto potente.

All’atto della sua attivazione viene configurata con un piano di tariffazione per GB di dati inviati dai collector, all’atto dell’attivazione di soluzioni di analisi avanzate, quali ad esempio la Soluzione di Security and Audit, la tariffazione avviene per nodo.

Da notare che i primi 60 giorni sono gratuiti.

Al di la della soluzione adottata è possibile comunque variare il periodo di conservazione dei dati archiviati che di default è di 31 giorni, anche la conservazione dei dati di log ha una sua tariffazione che è basata sulla quantità di dati inviati, secondo lo schema qui sotto.

 

Figura 1 tariffazione mensile Azure Log Analitycs

I primi 5 Gb mensili sono gratuiti così come la conservazione base di 31 giorni, solamente gli sforamenti in termine di periodo di conservazione e spazio occupato avranno un costo che varia, in misura minima, a seconda delle region di allocazione del servizio.

 

Per poter modficare il periodo di conservazione dei dati, così come la quantità giornaliera archiviata, è sufficiente collegarsi al portale di Azure https://portal.azure.com, accedere alla soluzione di monitoring selezionare la funzione relativa a “Utilizzo e Costi Stimati”

Figura 2 visualizzazione dei consumi e costi attuali

 

e da questa pagina accedere alle impostazioni di “Gestione del Volume dei Dati” e selezionare le impostazioni volute.

Si possono mantenere i dati in linea per un periodo massimo di due anni, ed è possibile anche impostare un limite di upload giornaliero

 

Figura 3 impostazione dei limiti di archiviazione

È possibile anche impostare un’ora del giorno a cui vengono applicati i limiti di archiviazione in termini utilizzo di dati

Riferimenti

https://docs.microsoft.com/it-it/azure/log-analytics/

 

IMPLEMENTAZIONE del PROTOCOLLO LDAPs in Active Directory

All’interno di realtà aziendali complesse, con sistemi eterogenei, può essere abbastanza comune riferirsi ad Active Directory come provider di autenticazione “esterno” per le applicazioni aziendali.

In alcuni casi, questi ambienti possono utilizzare in modo nativo le credenziali con cui un utente ha effettuato il login sulla postazione, ma più frequentemente è richiesto che l’applicazione, a prescindere dalla credenziale fornita per l’accesso al pc, esegua l’autenticazione dell’operatore richiedendo username e password.

Questa modalità operativa è utilizzata principalmente nelle realtà dove una singola postazione è utilizzata da operatori diversi in tempi brevi e con brevi attività di lavoro.

Un esempio è sicuramente una realtà ospedaliera dove un PC è utilizzato quasi continuamente da più operatori e per ognuno di questi deve essere garantita la “tracciabilità” delle operazioni compiute. Questa modalità operativa prevede (per ovvie ragioni di velocità di accesso) che le applicazioni permettano una funzione di “Cambio Operatore” senza essere chiuse.

Inoltre essendo demandata all’ambiente applicativo la gestione delle autenticazioni è utile che possa essere eseguito anche il cambio password all’interno dell’applicazione stessa, così come i vari controlli sulle password policies implementate a livello Aziendale

In uno scenario di questo tipo non è raro trovare applicazioni che utilizzano il protocollo LDAP per le funzioni di autenticazione e gestione delle credenziali utente.

Limitazioni nell’uso del protocollo LDAP

l’articolo How to change a Windows Active Directory and LDS user password through LDAP riporta:

  • The password is stored in the AD and LDS database on a user object in the unicodePwd attribute. This attribute can be written under restricted conditions, but it cannot be read. The attribute can only be modified; it cannot be added on object creation or queried by a search.
  • In order to modify this attribute, the client must have a 128-bit Transport Layer Security (TLS)/Secure Socket Layer (SSL) connection to the server.

È evidente che tramite LADP, che non dispone di una connessione cifrata, non è possibile gestire in modo completo le funzioni di cambio password, risulta quindi necessario ricorrere al protocollo LDAPs

Attivazione del Protocollo LDAPs

Durante la “promozione” di un sistema alle funzioni di Domain Controller viene attivato anche il protocollo LDAP, mentre per poter attivare la connessione cifrata con LDAPs è necessario che venga fornito un certificato che deve contenere l’OID 1.3.6.1.5.5.7.3.1 8 (Server Authentication) come è ampiamente spiegato nel seguente articolo Technet LDAP over SSL (LDAPS) Certificate

  • Certificate must be valid for the purpose of Server Authentication. This means that it must also contains the Server Authentication object identifier (OID): 1.3.6.1.5.5.7.3.1
  • The Subject name or the first name in the Subject Alternative Name (SAN) must match the Fully Qualified Domain Name (FQDN) of the host machine, such as Subject:CN=server1.contoso.com. For more information, see How to add a Subject Alternative Name to a secure LDAP certificate (http://support.microsoft.com/kb/931351).

Ed è anche richiesto che l’account macchina del DC possa accedere alla chiave privata del certificato

  • The host machine account must have access to the private key.

 

 

Installazione di un PKI aziendale

Sul sito ICTPOWER, abbiamo proposto una serie di articoli in cui viene spiegato il modo corretto per installare e configurare una PKI all’interno di un dominio Active Directory.

Di default se un Domain Controller rileva la presenza di una Certification Authority ( Enterprise ) richiede in modo automatico un certificato alla CA ed attiva le comunicazioni cifrate in LDAPs di fatto attivando questo protocollo.

 

Figura 1 Certificato presente nello Store Computer di un DC

Il libro Windows Server 2008 PKI and Certificate Security” di Brian Komar affronta in modo completo le problematiche e gli scenari di attivazione di una CA, in particolare a pagina 671 viene sipegato il comportamento citato in precedenza.

 

 

 

Scelta del posizionamento della CA nel dominio

 

La scelta del dove installare il ruolo e le funzioni della PKI non è di secondo piano, numerosi articoli consultabili nel web ne propongono l’installazione direttamente su un Domain Controller, gli articoli proposti su ICTPower.it delineano uno scenario in cui le funzioni della CA sono installate su server dedicati.

Si riporta di seguito la nota di Brian Komar che propone il medesimo scenario di installazione

Mentre sul Technet l’articolo Public Key Infrastructure Design Guidance argomenta ulteriormente la scelta di server dedicati.

 

Se la scelta di implementazione della CA è basata su due livelli con la CA Root off-line è necessario considerare il fatto che i Domain Controller presenti NON inizieranno a richiedere i certificati in autonomia finché non verrà distribuito il certificato della Root-CA, questo comportamento è spiegato dal fatto che i sistemi conoscono sì la issuing-CA ma non è disponibile il certificato che attesta l’autenticità di quest’ultima.

Per fare si che i DC possano quindi “Dialogare” con questo servizio è necessario creare una GPO che distribuisca il certificato Root, che deve essere scaricato dalla Root-CA.

Figura 2 Export del certificato della Root-CA

A questo punto è sufficiente creare la GPO con cui viene distribuito il certificato della Root-CA, per comodità di configurazione è possibile creare una GPO applicata a livello di Dominio.

Figura 3 Definizione della GPO

Non appena i vari DC ricevono la Group-Policy eseguono la richiesta del proprio certificato alla Issuing-CA

Figura 4 Issuing CA e relativi rilasci per i DC

 

A questo punto per determinare se il Domain Controller ha effettivamente attivato le comunicazioni in LDAPs è sufficiente verificare la connessione tramite il tool LDP.exe

 

Figura 5 connessione LDAPs

La connessione avvenuta riporta le informazioni relative al DC ed ai servizi disponibili

Figura 6 connessione LDAPs

 

 

Il funzionamento a questo punto è anche verificabile attivando e disattivando la GPO creata, se questa viene disattivata, in modo del tutto automatico i DC ritornano ad utilizzare il protocollo LDAP ( che in ogni caso non viene disattivato)

 

Riferimenti

Di seguito il link agli articoli pubblicati su IctPower.it insieme ad Ermanno Goletto relativi ad una architettura PKI a due livelli

 

RDS Gestione del Numero di Sessioni Utente Concorrenti

Normalmente in RDS ogni singolo utente che accede al servizio dispone di una singola sessione, quindi, rieseguendo un secondo accesso, la prima sessione verrà disconnessa.

In alcuni scenari di utilizzo, questo comportamento può essere un limite, si pensi ad ambienti dove l’autenticazione avviene a livello applicativo e l’accesso al Sistema è necessario esclusivamente per avviare l’applicazione.

In un contesto di questo genere è possibile modificare il comportamento di Default tramite una GPO di Macchina da applicare sui sistemi dell’infrastruttura RDS che ospitano il ruolo Session Host

La GPO che determina questo comportamento è in

  • Computer > Modelli Amministrativi > Componenti di Windows > Servizi Desktop Remoto > Host Sessione Desktop Remoto > Connessioni
  • Impostare “Limita gli Utenti di Servizi Desktop remoto a una sola sessione di Servizi Desktop remoto” a Disabilitato.


Conversione Fisico/Virtuale per mezzo di Disk2Vhd di un sistema con bios UEFI

 

Il tool Disk2Vhd permette agevolmente la conversione di sistemi fisici in VM pur non essendo un vero e proprio strumento di conversione.

Nei vari scenari affrontati, la conversione di sistemi legacy XP,2003 etc. può essere necessaria ( anche se ormai questi sistemi sono fuori supporto ).

Anche con sistemi operativi più recenti W7,10,2012 può essere necessario effettuare la conversione di installazioni fisiche.

Nel caso in cui queste siano in installate su HW con Bios UEFI, la conversione con Disk2Vhd, e la successiva creazione della VM non consentono al sistema un avvio corretto e la VM rimane inaccessibile con lo schermo completamente nero.

Figura 1 avvio fallito dopo la conversione del disco di sistema

 

Se ci si trova in questa situazione è sufficiente seguire alcuni passaggi per consentire il corretto avvio del sistema operativo.

Per prima cosa è necessario montare il disco convertito e verificare le partizioni esistenti, quasi certamente si vedrà un’organizzazione del disco simile a quella della figura sotto, ossia con un disco di tipo GPT ed una serie di partizioni che precedono la partizione di sistema vera e propria.

Nota. Per effettuare le operazioni descritte qui sotto possibile utilizzare numerosi tool, Free, OpenSource ed a pagamento, personalmente ho utilizzato Aomei Partition Assistant nella versione Free scaricabile dal sito

 

Figura 2 conversione VHDx

 

A questo punto è sufficiente effettuare la conversione del disco da GPT a MBR

 

Figura 3 Conversione ad MBR del disco

Successivamente, dopo aver applicato le modifiche, è necessario rimuovere tutte le partizioni che precedono quella di sistema ( chiaramente questa operazione dovrà essere valutata caso per caso se fossero presenti altre partizioni contenenti dati )

Figura 4 rimozione partizione

Ed al termine applicare, anche in questo caso le modifiche

 

 

A questo punto è possibile smontare il disco e creare una VM ( Gen1 ) con questo disco come disco principale.

 

La VM non sarà ancora avviabile, pertanto dovremo inserire un disco della versione di Sistema che è contenuta nel VHD ed avviare le procedure di ripristino, è da notare che possono esserci leggere differenza tra le varie versioni. ( in questo esempio un ripristino di un sistema W7)

Successivamente accedere al prompt comandi e con l’utility DISKPART eseguire i comandi di attivazione della partizione

 

  • diskpart
  • list disk
  • select disk 0
  • list partition
  • select partition 1
  • active
  • exit

Figura 5 impostazione della partizione attiva

 

e, dopo un ulteriore riavvio è necessario eseguire la ricostruzione delle componenti di boot con i comandi

 

  • bootrec /fixmbr
  • bootrec /fixboot

 

ed infine eseguire

  • bootrec /RebuildBcd

in modo da eseguire la scansione delle installazioni presenti sul disco e ricostruire l’archivio di configurazione di avvio…

 

Rilevazione degli errori di Assegnazione Siti ad Aree in IE impostati tramite Group Policy (Event ID 1805)

 

In Internet Explorer è la Sicurezza del browser è strutturata in 4 aree Internet / Intranet Locale / Siti Attendibili / Siti Con Restrizioni, per ognuna di queste aree è possibile la gestione delle impostazioni di sicurezza in modo indipendente.

 

Figura 1 Aree di Sicurezza di IE

L’appartenenza di un determinato sito ad un’area avviene inserendo direttamente l’url del sito all’interno di un elenco impostato nel browser (elenco che è disponibile per ogni area)

Figura 2 Assegnazione di un Sito ad un’Aera

Nella dichiarazione di un sito è possibile utilizzare caratteri jolly ed i vari nomi ma con una serie di vincoli. E’ anche possibile dichiarare un singolo indirizzo ip ( 10.0.0.1) oppure un range di indirizzi ( 10.0.0.1-100).

È inoltre possibile indicare un protocollo specifico per discriminare l’assegnazione ad un’area specifica includendo anche il protocollo stesso.

Nel momento in cui viene introdotto un valore questo viene automaticamente verificato in modo da evitare che il comportamento del browser non sia corretto. Ad esempio se viene impostato https://blogs.technet.microsoft.*com, che non è sintatticamente corretto, viene presentato il seguente messaggio

Figura 3 Warning Relativo ad un Errore Formale di Dichiarazione ( LOCALE )

 

Questo controllo è disponibile quando vengono inseriti i valori all’interno delle impostazioni del browser, in quanto viene effettuata la conversione in chiavi di registro delle impostazioni di IE dal browser stesso.

 

Gestione delle Assegnazioni tramite GPO

Nel momento in cui si effettua la gestione dell’ambiente di sicurezza direttamente dalle GPO, viene perso il controllo sulla correttezza del valore digitato, questo verrà passato al client all’atto dell’elaborazione della GPO, e solo in questo frangente verrà eseguita la conversione del valore impostato nella Group Policy verificandone la correttezza.

Nel caso venga impostato un valore in modo non corretto, e quindi non gestibile dal browser, viene riportato un evento ID 1085 all’interno del registro eventi della postazione.

 

Figura 4 Dichiarazione Errata nella GPO

Figura 5 Event ID 1805 Riportato sulla Postazione

 

Il registro tuttavia non riporta in modo puntuale dove è stato rilevato l’errore, nemmeno leggendo i dettagli dell’evento stesso.

Figura 6 Dettaglio Evento

 

Il livello di dettaglio che possiamo rilevare è nella descrizione dell’errore relativamente alla dicitura “Parametro non corretto”

Anche effettuando una “forzatura” tramite il comando GPUPDATE /FORCE sulla postazione otteniamo un avviso di errore

Figura 7 Comando Gpupdate

Tramite il tool di diagnostica GPRESULT /H <NomeFileDiOutput.html> possiamo ottenere informazioni più circostanziate e precise contenute all’interno del file di output.

A questo punto il report generato dal comando è disponibile nel file html e da qui è possibile verificare quali impostazioni sono state “passate” dalla GPO al client ed approfondire l’indagine.

Figura 8 Report in Formato HTML

Non viene tuttavia indicato quale sia il valore che genera l’errore.

 

IE Zone Analyzer TOOL

Uno strumento ulteriore per la diagnostica dei problemi legati a questo tipo di impostazioni è Zone Map Viewer
che è stato rilasciato ormai da alcuni anni ma ( sebbene non sia disponibile una informazione ufficiale di compatibilità con i sistemi recenti ) è ancora utilizzabile per la rilevazione delle impostazioni del browser.

Questo tool riporta la configurazione attiva sul browser tramite la funzione “Zone Map Viewer”

Figura 9 IE Zone Analyzer TOOL

 

E in dettaglio le impostazioni valide, che per differenza rispetto a quelle impostate tramite la GPO, individuano il settaggio non valido, in questo esempio https://www.bing.*com è il valore che non essendo coerente con i vincoli imposti dal browser, genera l’errore in applicazione della GPO, tramite Zone Analyzer infatti è applicato esclusivamente http://www.google.com

 

 

Figura 10 Report delle Impostazioni Effettivamente Attive

 

 

Riferimenti

https://blogs.msdn.microsoft.com/askie/2016/04/05/description-of-event-id-1085-from-internet-explorer-zonemapping/

https://blogs.technet.microsoft.com/fdcc/2011/09/22/iezoneanalyzer-v3-5-with-zone-map-viewer/

https://blogs.technet.microsoft.com/fdcc/2011/09/22/internet-explorers-explicit-security-zone-mappings/

 

 

 

 

 

 

Credssp vulnerabilità descritta in CVE-2018-0886

 

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/