Utilizzare Certutil.exe per la verifica delle Revocation List

Certutil è uno strumento di gestione e manipolazione di certificati digitali

È utilizzato per la gestione dello store di certificati, ma può anche fornire indicazioni relativamente ad un certificato salvato in un file.

Ad esempio se vogliamo avere indicazioni complete sul certificato attualmente utilizzato da Google dobbiamo dapprima recuperarlo, aprendo la pagina del motore di ricerca, e poi  salvarlo in un file localmente al PC.

Selezioniamo il Lucchetto nella barra (1) e successivamente facendo click su “Visualizza Certificati” (2)

iexplorer1

In questo modo compaiono le informazioni relative al certificato utilizzato dal browser, è sufficiente salvarlo su un file in formato “Binario Codificato DER X509  (.CER) ”.

iexplorer2

Posizionandosi prima sul TAB Dettagli

Ora possiamo verificare con Certutil.exe il certificato salvato

  • certutil -f –urlfetch -verify C:\Temp\google.cer >GoogleCertResult.txt

 

Anche tramite la videata grafica qui sopra, è possibile visualizzarne le informazioni, ma in questo modo è possibile salvarle in un file di testo, semplificandone la consultazione delle varie proprietà.

All’interno del file, possiamo individuare le modalità di verifica dell’eventuale revoca del certificato.

In questo caso evidenziamo le due modalità

  • CRL ( Certificate Revocation List)
  • OCSP (Online Certificate Status Protocol)

Rispetto alle CRL, OCSP è più performante trasmettendo ad ogni richiesta di verifica meno dati della CRL.

Si rimanda ai link riportati sotto per approfondimenti ulteriori.

revocation1

Utilizzando ancora certutil.exe è possibile effettuare una verifica sulla revoca (eventuale) del certificato salvato.

certutil1

Prima di effettuare la verifica è necessario tramite “Seleziona” recuperare il file di certificato salvato prima ed individuare il metodo di verifica coerente con l’URL scelto.

Questa procedura è utile anche in caso di diagnostica di CA Aziendali “private” ad esempio per individuare problemi dovuti alla non corretta dichiarazione dell’URL della revocation list a seguito di migrazioni che prevedono la modifica del nome host.

Riferimenti:

https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

https://en.wikipedia.org/wiki/Certificate_revocation_list

https://en.wikipedia.org/wiki/X.509

Gestione degli utenti sincronizzati con Azure Active Directory Connect

Può succedere che a seguito di sincronizzazioni incomplete o di indisponibilità del dominio on-premise, piuttosto che per comportamenti anomali di un qualche componente coinvolto, rimangano all’interno della directory in Azure oggetti senza riferimento sull’AD principale.

Normalmente la gestione della Azure Active Directory avviene completamente dal dominio on-premise, gestendo gli utenti come si fa normalmente.

Le varie operazioni di Cancellazione ridenominazioni assegnazioni a gruppi etc. vengono fatte on-prem e replicate poi nel cloud, tuttavia se, come può accadere, rimangono oggetti in Azure AD senza una corrispondenza sul dominio locale è necessario operare con Powershell per la loro rimozione.

Anche perché sul portale non è possibile agire in rimozione per questa tipologia di utenti

azure-ad-sync-userportal

Per prima cosa è necessario impostare l’ambiente PS in modo che abbia i moduli e le cmd-let necessarie alla connessione e gestione di Azure AD.

Questa pagina https://technet.microsoft.com/library/jj151815.aspx riporta le indicazioni necessarie alla configurazione dell’ambiente PowerShell per la connessione verso Azure.

Una volta correttamente importati e configurati i moduli PowerShell con il comando:

$msolcred = get-credential

connect-msolservice -credential $msolcred

ci si connette con le credenziali di un utente “Amministratore Globale” alla Directory di cui si vuole effettuare la gestione, a questo punto per identificare gli utenti presenti sulla Directory è utilizzabile il  cmd-let

  • Get-MsolUser

azure-ad-sync-get-msoluser

Mentre per la cancellazione dell’utente rimasto “orfano” è possibile usare il cmd-let

azure-ad-sync-remove-msoluser

Relativamente agli oggetti cancellati è bene sapere che è possibile “recuperarli” in quanto vengono, posti in un “cestino” per un periodo di 30 giorni.

In questo caso il cmd-let da usare è

 

Altra possibilità è quella di verificare l’elenco degli utenti “eliminati” ed ancora in cestino per ottenere l’elenco degli utenti cancellati si utilizza il comando

  • Get-MsolUser -ReturnDeletedUser

 

È anche possibile ottenere informazioni dettagliate sull’utente rimosso come ad esempio la data di cancellazione ed altro

  • Get-MsolUser -ReturnDeletedUser -UserPrincipalName utente02@<dom>.onmicrosoft.com | fl

 

azure-ad-sync-get-msoluser-returndeleteduser

 

Riferimenti:

Azure Active Directory

https://docs.microsoft.com/it-it/azure/active-directory/active-directory-whatis

Azure Active Directory Connect

https://docs.microsoft.com/it-it/azure/active-directory/active-directory-aadconnect

 

 

Connessione ad Azure Active Directory tramite proxy

Azure Active Directory è un servizio disponibile in Cloud che consente, tra i le altre opzioni,  anche la possibilità di sincronizzare oggetti di un dominio OnPremise verso il cloud stesso in modo da avere, se necessario, una corrispondenza con gli utenti on prem anche in Azure.

Al di là di quelle che sono le funzionalità disponibili , quando gli utenti sono replicati in cloud, ad esempio è possibile attivare le funzionalità di cambio password in modalità Self-Service per i vari uenti.

E’ possibile configurare Azure AD Connect per utilizzare  un proxy per le funzioni di “replica”.

Questa caratteristica è molto utile in quanto permette di sincronizzare la propria infrastruttura AD locale verso il cloud senza dover mettere mano ad impostazioni particolari sui firewall eventualmente attivi, sfruttando semplicemente la presenza di un proxy già presente in Azienda.

La configurazione è molto semplice, è sufficiente individuare ed aprire il file machine.config presente in

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config

ed aggiungere al fondo, prima del tag di chiusura della configurazione, alcune  righe come riportato sotto

 

               

                                <proxy

                                usesystemdefault=”true”

                                proxyaddress=”http://10.102.162.6:80&#8243;

                                bypassonlocal=”true”

                                />

               

 

il file in formato XML dovrà terminare con il tag di chiusura della configurazione

    

A questo punto se le impostazioni sono corrette per verificare se la configurazione funziona correttamente è sufficiente da PS richiamare

Invoke-WebRequest -Uri https://adminwebservice.microsoftonline.com/ProvisioningService.svc

 azure-ad-sync-ps-verification

Se il cmd-let restituisce Satus Code 200 allora la comunicazione avviene ed servizio di sincronizzazione può operare.

Nel caso in cui il test tramite il commandlet visto sopra non dovesse funzionare è possibile a questo link ottenere informazioni sui più comuni messaggi di errore dell’ambiente AD Connector

Problemi Riscontrati

E’ necessario fare attenzione alla versione di client AADConnect che si sta installando, in quanto se si utilizza la 1.1.370.0, soprattutto con connessioni via proxy, e non è aperta la porta TCP/9090 l’installazione fallisce con questo errore.

azure-ad-sync-error-proxy-connection

Il problema è stato risolto con la versione 1.1.371.0 come riportato in questo post: Azure AD Connect: Version Release History

Link alla pagina di download del client AADConnect

Ricostruzione delle zone DNS relative ad Active Directory

Per le cause più disparate può accadere che all’interno del DNS vi siano una o più zone non funzionanti o con errori.

Dal punto di vista della struttura DNS di un Domain Controller possiamo notare che di default vengono create due zone, ad esempio per il dominio test.local, dove questo è anche il Root Domain della foresta troveremo:

  • _msdcs.test.local
  • test.local

entrambe zone primarie ed integrate in AD

La prima zona è quella “di foresta” ossia la zona che viene creata con la promozione del primo DC che è anche il Root Domain Controller, mentre la seconda zona è quella relativa al dominio vero e proprio, che in questo caso essendo il primo dominio installato nella foresta prende anche il nome di Root Forest Domain.

 

dnsadreconstruction1

Come si può vedere nell’immagine il DNS contiene anche una seria di informazioni relative ad altri host connessi in rete, il DNS è quindi, come di solito avviene, utilizzato per il normale funzionamento dell’infrastuttura.

Nell’ambiente di test realizzato, per simulare un malfunzionamento, sono state rimosse le varie impostazioni relative alla zona di dominio test.local ed è stata anche rimossa la zona _msdcs.test.local relativa alla Foresta.

A questo punto il comando dcdiag /test:dns riportava diversi errori

                     Error:                     Missing SRV record at DNS server 192.168.1.30:      _kerberos._tcp.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:       _ldap._tcp.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:       _ldap._tcp.Default-First-Site-Name._sites.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:       _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:         _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:         _kerberos._tcp.Default-First-Site-Name._sites.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:            _ldap._tcp.gc._msdcs.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:               _gc._tcp.Default-First-Site-Name._sites.test.local
                     Error:                     Missing SRV record at DNS server 192.168.1.30:        _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.test.local
                     Error:     Missing SRV record at DNS server 192.168.1.30:  _ldap._tcp.pdc._msdcs.test.local
               Error: Record registrations cannot be found for all the network
                                                  Auth Basc Forw Del  Dyn  RReg Ext
           _________________________________________________________________
            Domain: test.local
               srvdc03                      PASS FAIL PASS PASS PASS FAIL n/a
         ……………………. test.local failed test DNS

Per ricreare automaticamente le zone non funzionanti è sufficiente riavviare il servizio Netlogon

Tuttavia se questo non avviene, o se le zone sono state rimosse completamente è necessario, prima ricrearle manualmente e solo successivamente effettuare un restart del servizio ( ricrearle nel senso di definire le due zone con il nome come visto sopra ed integrate in AD) la “popolazione” vera e propria delle zone verrà fatta da Netlogon 

dnsadreconstruction4

dnsadreconstruction5

 

A questo punto dopo che  Netlogon è riavviato vedremo le Zone completamente popolate.

Recupero dei dati contenuti all’interno di una zona DNS

Come visto in precedenza il DNS è utilizzato anche per le normali funzioni di rete e quindi la cancellazione della zona test.loc prima della sua rigenerazione potrebbe essere causa di malfunzionamenti, in questo caso è possibile PRIMA di eliminare la zona dal DNS effettuare un salvataggio del suo contenuto.

Per “esportare” i dati contenuti è sufficiente definire  la zona stessa come standard rimuovendo il flag che la imposta come integrata in AD

dnsadreconstruction2

Una volta rimosso il flag e salvate le impostazioni in %SystemRoot%\System32\DNS\ copiare il file relativo alla zona, al suo interno, in formato testo è presente l’intera struttura che prima era integrata in AD.

All’inizio del file troveremo alcune informazioni relative alle impostazioni TTL, SOA Seriale etc. questa parte del file potremo tranquillamente eliminarla, manterremo soltanto il contenuto vero e proprio relativo ai vari record A che definiscono le vere informazioni ancora mancanti nel DNS

Automazione dell’import dei Record tramite PoweShell

Una procedura automatizzata è possibile tramite PowerShell, per mezzo di questo ambiente con poche righe di istruzioni è possibile importare il contenuto del file testo.

Il commandlet Add-DnsServerResourceRecordA può essere utilizzato per questa operazione mentre con il commadlet Get-Content viene letto il contenuto del file di testo

 

$DnsRecord = Get-Content C:\temp\test.local.dns

foreach ($line in $DnsRecord)

{

 

$DnsHost = $line.Split()|where {$_}

Add-DnsServerResourceRecordA -Name $DnsHost[0] -IPv4Address $DnsHost[2] -ZoneName test.local

}

 

Se dovessero essere presenti record differenti rispetto al tipo “A” occorre modificare di conseguenza lo script in PS

 

 

 

 

Windows 2003 e 2003 R2 Retired Documentation

Link alla documentazione Ufficiale Microsoft relativa al sistema Operativo 2003 e 2003 R2 Server

“Descrizione dalla pagina di download”

    • Set completo dei contenuti precedentemente pubblicati in Windows TechNet per Windows Server 2003, Server 2003 Service Pack 1 e 2 e Windows Server 2003 R2. Include tutti i contenuti forniti con il prodotto Windows Server 2003, insieme ai contenuti relativi a operazioni, sicurezza e protezione, informazioni tecniche, glossario, requisiti di sistema, introduzione, pianificazione e architettura e distribuzione. Include anche i contenuti della raccolta di documentazione tecnica per Windows Server 2003 Service Pack 1 e 2. Per Windows Server 2003 R2, i contenuti includono installazione, valutazione del prodotto, introduzione, pianificazione e architettura, distribuzione e i contenuti inclusi nel prodotto.

download all’intero file pdf relativo alla documentazione

oppure anche disponibile qui

Auditing ed archiviazione di messaggi ORACLE in OMS Operations Management Suite

In questo post  ho indicato come è possibile configurare il demone Syslog e l’agente OMS Linux al fine di reindirizzare i vari eventi che vengono rilevati dal Syslog, verso OMS in modo da poi essere analizzati con le funzioni di Log Analyzer.

Vedremo ora come è possibile configurare il logging del DB Oracle e combinarlo con le configurazioni descritte sopra in modo da inviare gli eventi di security del Database verso OMS.

Premessa

  • Oracle permette di reindirizzare i propri eventi verso Syslog soltanto dalla versione 10.2.0 nelle precedenti versioni questa funzione non era disponibile.
  • Il parametro NON è modificabile “a caldo “ ma richiede un riavvio dell’istanza.
  • di default questa funzione non è attivata

Configurazione del DB

Per prima cosa è necessario attivare il logging del DB (se già non lo fosse) tramite il parametro

AUDIT_TRAIL

Questo parametro abilita il database ad effettuare logging e le opzioni disponibili sono:

none

log disabilitato

os

abilita il log verso il Sistema operativo

db

abilita il log verso il DB stesso nella tabella di Sistema SYS.AUD$

db,extended

abilita il log come il precedente ma vengono anche populate le colonne                SQLBIND e SQLTEXT CLOB nella tabella SYS.AUD$

xml

abilita l’auditing verso un file XML di sistema

xml,extended

come il precedente ma vengono archiviati anche I valori  SqlText and SqlBind

nel nostro caso abiliteremo il log verso il sistema operativo con il comando

  • alter system set audit_trail=’OS’ scope=spfile

è necessario specificare come scope SPFILE in quanto l’impostazione deve essere mantenuta a seguito di un riavvio dell’istanza

Successivamente si dovrà definire come Oracle invia i messaggi al Syslog in modo conforme alle specifiche RFC analizzate nel post citato prima.

È possibile utilizzare le varie Facilities a seconda dell’impostazione del Syslog, è possibile, ad esempio utilizzare la Facility LOCAL per differenziare I messaggi provenienti da Oracle rispetto a quelli del sistema, anche in questo caso è necessario specificare lo scope come fatto sopra.

  • alter system set audit_syslog_level=’local0.info’ scope=spfile

Dopo il riavvio dell’istanza le impostazioni di logging diventeranno operative

Configurazione del demone Syslog

A questo punto è necessario modificare il file rsyslog.conf in modo da reindirizzare i messaggi della facility Local0 verso l’agent OMS che è configurato come gateway verso il servizio in Cloud

  • local0.*                             @@10.0.0.38:2554

Interrogazione degli eventi dal Portale di Operations Management

Dal portale OMS effettuando una ricerca con ProcessName=Oracle è possibile evidenziare tutti gli eventi relativi ad Oracle in archivio.

oms-oracle-1

Come si vede sopra è indicata anche la Facility utilizzata per la comunicazione Oracle–>Syslog

oms-oracle-2

Analizzando più in dettaglio un messaggio archiviato possiamo rilevare le seguenti informazioni

  1. nome dell’host DB
  2. utente DB che ha effettuato l’accesso
  3. nome del terminale/pc da cui è stato effettuato l’accesso
  4. sorgente di autenticazione per il DB (interno esterno etc.) e ip da cui è stata originata la richiesta
  5. nome utente sulla postazione ( di Sistema Operativo)
  6. processo che ha generato il messaggio Syslog

Riferimenti:

https://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams016.htm#REFRN10006

http://docs.oracle.com/cd/B28359_01/server.111/b28320/initparams016.htm#REFRN10263

https://docs.oracle.com/cd/B28359_01/network.111/b28531/auditing.htm#DBSEG006

un grazie particolare a Roberto Marinello @matrix975 per la preziosa collaborazione sull’ambiente Oracle

Tool di Benchmarking per GPU (Utile con Remote FX)

Per chi volesse apprezzare e  rilevare le effettive performance delle schede GPU, anche in ambiente Hyper-V/RDS, un valido aiuto sono i software di test messi a disposizione da UNiGiNE

http://unigine.com/en/products/benchmarks

già le versioni disponibili in licenza grautita consentono di valutare le effettive differenze nell’impiego delle GPU anche in ambienti come RDS con RemoteFX.