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

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

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

• Remove-MsolUser -UserPrincipalName utente02@<NomeDir>.onmicrosoft.com

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 è

• restore-MsolUser -UserPrincipalName utente02@<NomeDir>.onmicrosoft.com

 

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

 

 

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

 

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.

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.

 

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 

 

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

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