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

Annunci

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.

 

 

 

Operations Management Suite configurazione dell’agente Linux come Syslog Collector gateway verso Log Analitycs

 Syslog è un protocollo che consente il trasporto di messaggi di log, e di informazione più in generale, è nato all’inizio degli anni ’80 tuttavia è stato definito come RFC dall’IETF soltanto vent’anni dopo. In questo lasso di tempo diverse implementazioni hanno generato differenti “servizi”, la prima  RFC che ne documenta il funzionamento è la 3164  mentre una sua evoluzione è descritta dalla RFC 5424

I servizi più comuni che lo utilizzano in ambienti *NIX hanno nome SYSLOG, SYLOG-NG, RSYSLOG ma molti altri prodotti, sia commerciali, che rilasciati sotto licenza Open Source lo implementano al fine di permettere la raccolta di eventi generati da molteplici apparati e sistemi.

Ormai non è affatto raro trovare apparati di rete, firewall, telecamere ma anche prodotti legati al mondo industriale, come ad esempio PLC e controllori di processo più in generale, che implementano il protocollo Syslog al fine di inviare ad un unico collettore i propri eventi di funzionamento.

Struttura del Sylog

Inizialmente implementato sul protocollo UDP, in porta 514 (recenti implementazioni lo rendono disponibile anche in TCP) il pacchetto trasporta le informazioni suddivise in:

  • Facility
  • Severity
  • Hostname
  • Timestamp
  • Message

Possiamo considerare le Facility come le entità che generano il messaggio di Syslog e ognuna di queste definisce poi una Severity che gradua la “gravità” dell’evento stesso.

Le Facility sono codificate da un numero e si riferiscono a componenti diverse del sistema; kernel, demoni di sistema, autenticazione ecc.

Cod. Facility
0 Kernel messages
1 User-level messages
2 Mail system
3 System daemons
4 Security/authorization messages
5 Messages generated internally by Syslogd
6 Line printer subsystem
7 Network news subsystem
8 UUCP subsystem
9 Clock daemon
10 Security/authorization messages
11 FTP daemon
12 NTP subsystem
13 Log audit
14 Log alert
15 Clock daemon
16 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7

Le severity seguono la stessa struttura e sono:

Cod. Severity
0 Emergency: System is unusable.
1 Alert: Action must be taken immediately.
2 Critical: Critical conditions.
3 Error: Error conditions.
4 Warning: Warning conditions.
5 Notice: Normal but significant condition.
6 Informational: Informational messages.
7 Debug: Debug-level messages.

Un pacchetto Syslog potrà avere per ogni Facility un codice di Severity differente, l’informazione dell’hostname che lo ha generato,l’ora di generazione ed in aggiunta una descrizione ulteriore relativa all’evento.

Syslog è quindi un “mezzo di trasporto” che viene utilizzato da differenti mittenti che classificano i propri messaggi secondo la codifica delle Facility, dipende quindi da ognuno dei servizi che generano messaggi log classificare i propri secondo la struttura del protocollo stesso.

Ad esempio SSHD di default utilizza la facility AUTHPRIV per i suoi messaggi relativi al logon degli utenti e quindi all’interno della configurazione del syslog, relativamente a questa facility, è indicato il percorso del file dove vengono salvati gli eventi.

Configurazione del Servizio Rsyslog su Linux

Su sistemi Linux ( RH,Centos, Oracle Linux) normalmente il demone rsyslog ha il file di configurazione in /etc/rsyslog.conf e la struttura di default prevede il salvataggio in locale dei messaggi che vengono generati dal sistema

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* -/var/log/maillog
# Log cron stuff
cron.* /var/log/cron
# Everybody gets emergency messages
*.emerg *
# Save news errors of level crit and higher in a special file.

 

authpriv.* istruisce syslog a salvare tutte le severity di questa facility nel file /var/log/secure, se volessimo differenziare le varie severity in percorsi distinti dovremmo dichiararlo per ognuna

authpriv.info                     /var/log/file1

authpriv.notice                /var/log/file2

ecc.

 

Redirezione dei messaggi verso un collettore in rete

Come detto in precedenza il protocollo syslog è in grado di trasportare i vari messaggi verso un collettore, ossia un ulteriore syslog che riceve ed archivia.

Per configurare un sistema in modo che invii tutti o solamente alcuni messaggi verso un altro server è sufficiente nel file .conf dichiarare l’host anziché un file locale come visto sopra.

La facility AUTHPRIV archiviata verso l’host 192.168.0.1 diventerà così:

authpriv.*                                           @192.168.0.1

mentre se l’host di destinazione invece che in UDP fosse configurato per ricevere in TCP dovremmo impostare

authpriv.*                                           @@192.168.0.1

ed ancora, se la porta di destinazione dell’host ricevente non fosse la standard 514 ma supponiamo la 25224 TCP dovremmo dichiarare

authpriv.*                                           @@192.168.0.1:25224

Operations Management Suite Agent in Linux

L’agente OMS per Linux quando installato sul sistema si comporta come un ricevitore di messaggi Syslog che poi redirige verso il servizio di log analizer in cloud. Il file di configurazione è in:

/etc/opt/microsoft/omsagent/conf/omsagent.conf

e per impostazione predefinita riceve i messaggi che sono generati localmente al sistema secondo questa configurazione:

<source>
type syslog
port 25224
bind 127.0.0.1
protocol_type udp
tag oms.syslog
</source>

Questo richiede (se si vogliono redirigere eventi Syslog verso il Log Analyzer) che il file di configurazione del Syslog venga modificato in modo da reindirizzare gli eventi sulla porta ed indirizzo su cui è configurato l’agente stesso.

Secondo quanto visto sopra, se volessimo inviare ad OMS i messaggi relativi a SSH configurato per utilizzare la Facility AUTHPRIV, dovremo impostare il file conf di Syslog in questo modo

authpriv.*                                           @127.0.0.1:25224

Modificando ulteriormente la configurazione dell’agente OMS, è possibile fare sì che questo diventi a sua volta un gateway di messaggi raccolti da vari Syslog verso il servizio di Log Analyzer di OMS, impostando omsagent.conf in questo modo:

<source>
type syslog
port 25224
bind 192.168.0.1   ( ip del sistema )
protocol_type udp
tag oms.syslog
</source>

e configurando i vari sitemi ad inviare i messaggi verso l’agente, otterremo il risultato di avere un gateway unico verso OMS senza dover installare ulteriori agenti.

Chiaramente così facendo si perde la possibilità, offerta dall’installazione diretta dell’agente sul sistema, di avere a disposizione ulteriori dati come ad esempio valori di occupazione dischi, ram, cpu etc.

 

20160916-oms-agnt-lnx-1

report ottenuto eseguendo il monitoraggio degli accessi in SSH su sistemi linux con le configurazioni descritte sopra

Problemi riscontrati

Durante la configurazione di alcuni sistemi (abbastanza datati) con demone Syslog, non era possibile cambiare la porta di destinazione sia TCP che UDP

 

Riferimenti

OMS agent su GitHub

Portale OMS esecuzione di query

OMS agent considerazioni generali

 

 

Microsoft Operations Management Suite ricercare eventi particolari

Lo stumento di Microsoft che prende il nome di Operations Management Suite è effettivamente un ambiente molto potente ed articolato che può essere di aiuto per gli amministratori di sistema.

Nella console del portale sono disponibili già preconfigurate una buona serie di query legate alla sicurezza, così come viene eseguito in automatico un “Assesment” del sistema, ad esempio nel mio caso, relativamente ad un Domain Controller, sono sato “avvisato” che questo non aveva le impostazioni di rete corrette per la parte DNS.

Uno strumento molto potente è la ricerca all’interno del mare di eventi che sono archiviati dai vari agent, in questo articolo sono forntite una serie di informazioni ed esempi che possono aiutare molto chi dovesse iniziare con questo strumento.

Personalmente ho voluto realizzare una query che evidenzi tutti gli eventi di logon relativamente ad un gruppo di utenti amministratori il cui nome contiene “_” e due lettere “as”, l’evento codificato per il login di un utente corrisponde all’id 4624 quindi impostando la quey

Type=SecurityEvent AccountType=user Account=*_*as EventID=4624| measure count() as Logons by Account

ho potuto in modo semplice avere in evidenza gli accessi effettuati da questo gruppo di utenti.

Nel caso in cui fosse, come è necessario, rilevare anche i tentativi di accesso falliti,  sempre di questo gruppo di utenti, sarà sufficiente modificare la query con l’id evento che viene generato all’atto di un tentativo fallito di login ossia il 4625

Type=SecurityEvent AccountType=user Account=*_*as EventID=4625| measure count() as Logons by Account

se volessimo poi restringere la ricerca agli eventi di questo tipo occorsi nelle utime 6 ore sarà sufficiente modificare le query aggiungendo il seguente “filtro” TimeGenerated>NOW-6HOURS

e la query diventerà così:

Type=SecurityEvent AccountType=user Account=*_*as EventID=4625 TimeGenerated>NOW-24HOURS | measure count() by Account

nel caso in cui si debbano utilizzare caratteri jolly per la ricerca di determinati valori è bene ricordare che questi non possono esssere immessi come parte di una stringa racchiusa tra “” altrimenti verranno interpretati come caratteri oggetto essi stessi di ricerca.

Recentemente nel portale OMS è stata introdotta la possibilità di creare query personalizzate ed organizzarle in un pannello che può essere visualizzato direttamente da console, questo strumento si chiama View Designer e deve essere abilitato dalla gestione delle impostazioni nelle preview

 

20160911-oms-query-1

qui sotto è riportato un pannello composto da query personalizzate che può essere utile attivare per il controllo della propria infrastruttura

20160911-oms-query-2

OMS è valutabile gratuitamente per un periodo illimitato, ma con la limitiazione di conservazione dei dati di 7 giorni e per un massimo di 5oo MB giornalieri di log archiviati