Troubleshooting, Disaster Protection & Recovery Active Directory
Troubleshooting
Da Leone Randazzo e Marco Bonatto; con la collaborazione di Davide Mauri e Massimiliano Luciani.
Lo scopo di questo capitolo è di fornire alcune informazioni utili in fase di identificazione e analisi dei problemi (i.e.: troubleshooting) quotidiani che si possono presentare in una infrastruttura Active Directory (AD) nonché di quelle azioni che bisogna intraprendere per prevenire e risolvere situazioni più complesse (i.e.: Disaster Protection & Recovery).
L’articolo è un estratto del libro: Active Directory, guida completa. - Editore: Mondadori Informatica.
Troubleshooting
Con il termine troubleshooting s’intende il processo di identificazione, analisi e risoluzione di problemi e malfunzionamenti (o guasti) in qualsiasi contesto operativo. Per affrontare con sicurezza, determinazione e profitto il troubleshooting dei problemi in ambiente AD, è necessario avere acquisito e maturato tutti gli argomenti trattati in questo libro, oltre ad avere una profonda conoscenza della “strumentazione” ovvero degli attrezzi del mestiere o “tools”.
Nel capitolo 6 “La soluzione Microsoft Active Directory Services” sono state fornite le informazioni sui tre kit standard a disposizione di un amministratore (i.e.: AdminPak.msi, Support Tools, Resource Kit) e le istruzioni su come installarli.
Oltre a questi, esistono spesso altre utility rilasciate successivamente da Microsoft e disponibili sul sito (e.g.: portqry.exe, dcgpofix.exe, Group Policy Managemente Console, ecc.).
Naturalmente, oltre ad avere una ottima conoscenza degli strumenti, è fondamentale acquisire nel tempo, e con l’esperienza maturata sul campo, delle vere e proprie strategie di troubleshooting che consentano di ottimizzare i tempi necessari a identificare e isolare le fonti di informazione primarie per la identificazione e la risoluzione dei problemi (e.g.: se esistono dei problemi di autenticazione in un contesto AD uno degli indiziati principali è quasi sempre il DNS (lato client o lato server oppure da entrambe le parti). Pertanto è necessario iniziare ad effettuare dei test (e.g.: utilizzando nslookup) per verificare il buon funzionamento della risoluzione dei nomi DNS da parte dei client coinvolti).
.gif) |
Alcuni assiomi del Troubleshooting
|
Troubleshooting di problemi correlati al servizio DNS
Una errata configurazione del DNS (sia lato client che lato server) o un malfunzionamento di un server DNS può avere ripercussioni sulle seguenti attività:
Risoluzione nomi.
Autenticazione utenti.
Registrazione dinamica sia dei resource record A e PTR (workstation/server/DC) che dei resource record DNS SRV relativamente ai soli DC.
Promozione di server a DC (DCPROMO).
Integrazione DNS/DHCP per la registrazione di computer client pre-Win2K.
Applicazione di GPO.
| |
Prevedere una configurazione DNS sicura e ridondata (i.e.: fault-tolerant) Come si è visto nel capitolo 7 “DNS e Active Directory” il servizio DNS è assolutamente fondamentale per il buon funzionamento di tutta l’infrastruttura AD. Pertanto è importante garantire la sua disponibilità e integrità. Per questo è consigliato utilizzare, laddove possibile, come server DNS dei DC Win2K3 con le zone integrate in AD e configurate con la modalità di aggiornamento dinamica sicura (Secure Only). In questo modo oltre a garantire la sicurezza nei riguardi della registrazione delle zone DNS si realizza una struttura multi-master e ad elevata disponibilità. Ciò in quanto:
|
Troubleshooting di problemi correlati alla replica AD e del servizio File Replication Service (FRS)
Un malfunzionamento della replica AD e del servizio File Replication Service (FRS) può avere conseguenze sulle seguenti attività:
Disallineamento dei dati all’interno di AD (e.g.: utenti creati su un DC nella sede centrale non vengono replicati sul DC di una filiale remota).
Autenticazione utenti.
Disallinenamento GPO ed eventuale non applicazione delle GPO coinvolte. In alcuni casi è possibile che i problemi di replicazione siano localizzati solamente a livello di servizio FRS e non di AD (i.e.: la replicazione degli oggetti consultabili nel DIT (e.g.: tramite Active Directory Users and Computers) di AD avviene perfettamente). Pertanto può accadere che la componente AD di una GPO (i.e.: la GPC) viene replicata correttamente da un DC ai suoi partner di replica, ma non la componente SysVol (i.e.:GPT).
Questi problemi possono verificarsi o a causa di un errore nel servizio FRS (cf. articoli Microsoft Knowledge Base 290762 “FRS: Using the BurFlags Registry Key to Reinitialize File Replication Service Replica Sets”e 292438 “Troubleshooting journal_wrap errors on Sysvol and DFS replica sets”) oppure per difetti legati alla scelta dei protocolli di replica associati ai site link (e.g.: utilizzo del protocollo SMTP per interconnettere due site all’interno dei quali esiste almeno un DC appartenente a un dominio che è “rappresentato” in entrambi i site da uno o più DC). In quest’ultimo caso la replicazione della componente Sysvol delle GPO non può avvenire in quanto il servizio FRS utilizza il protocollo RPC/IP e non SMTP.
Alcuni problemi riscontrati con il service FRS di Win2K3 sono stati risolti con una hotfix pre-SP1 di Win2K3 (cf. Articolo Microsoft Knowledge Base: https://support.microsoft.com/?scid=kb;en-us;823230, “Issues that are resolved in the pre-Service Pack 1 release of Ntfrs.exe”). Come specificato all’interno del sopra citato articolo è consigliato installare la hotfix solamente se sono presenti i problemi ad essa connessi. Altrimenti si consiglia di attendere l’uscita del Service Pack 1 di Win2K3.
| |
Implementare una infrastruttura AD ridondata Per avere una garanzia di fault-tolerant sulla sopravvivenza dei dati AD (database, SysVol e Global Catalog) è necessario predisporre almeno due DC per ciascun dominio opportunamente configurati. In presenza di una infrastruttura distribuita geograficamente, è necessario tenere conto anche della struttura fisica AD e della tipologia di connessioni WAN utilizzate per interconnettere le sedi, per dislocare opportunamente i DC, Global Catalog e DNS all’interno dei vari site. In generale assumendo un numero di utenti superiori a 100 per ogni sede remota ed in presenza di connessioni di rete abbastanza performanti è consigliato disporre in ogni site almeno di un server DNS, DC e GC. Laddove vengano utilizzate delle GPO collegate ad alcuni site, è consigliato dislocare anche un DC del dominio root della foresta nel relativo site, in quanto gli oggetti GPC e GPT in tal caso appartengono sempre alla partizione corrispondente al dominio root. |
| |
Effettuare dei test su un DC per verificare se la replicazione AD e FRS avviene correttamente Creare delle GPO di prova e verificare se sia la parte AD (GPC) che la parte Sysvol (GPT) si replicano correttamenet tra i DC di uno stesso dominio localizzati su uno stesso site (per semplicità e per non sovrapporre eventuali problemi dovuti alla topologia di replica inter-site). Per testare il buon funzionamento della replica FRS è possibile anche (molto più semplicemente) creare un file di testo nella condivisone NETLOGON di un DC e verificare se viene replicato sugli altri DC del dominio. |
Troubleshooting di problemi correlati ai domain controller
Alcuni problemi tipici legati alla gestione dei DC sono indicati nella tabella 1:
Problema |
Probabile messaggio di errore |
Possibile Causa |
|---|---|---|
Impossibile promuovere un server a DC |
|
Verifica: eseguire da una sessione Command Prompt il comando nslookup.
|
Impossibile declassare un DC a server |
|
Verifica: eseguire da una sessione Command Prompt il comando nslookup. |
| |
Forzare il declassamento di un DC a server anche in “condizioni off-line” In alcuni casi è necessario forzare il declassamento di un DC a server anche in condizioni nelle quali il dominio di appartenenza non è raggiungibile. In questi casi, non volendo reinstallare il sistema operativo e desiderando trasformare il DC in server stand-alone è possibile utilizzare il seguente comando: dcpromo /ForceRemoval. Prima di effettuare la suddetta procedura (tranne che il DC non sia l’ultimo della foresta) è necessario verificare se il DC è detentore di ruoli FSMO o svolge funzioni di Global Catalog. In tal caso ricordarsi di assegnare i suddetti ruoli ad altri DC. Da notare che questa procedura non aggiorna i meta-data Active Directory relativi al DC declassato. Ciò rende necessario (tranne che il DC sia l’ultimo della foresta) effettuare la pulizia manuale secondo quanto indicato nella sezione “Rimuovere dal database AD i meta-data degli oggetti domain controller e domini”. A tal proposito si consiglia la consultazione dei seguenti articoli Microsoft Knowledge Base:
|
| |
Install From Media (IFM): effettuare la promozione di un server a DC tramite la nuova opzione /ADV del wizard DCPROMO Grazie all’opzione /ADV dell’utility DCPROMO di Win2K3 è possibile effettuare la promozione di un “additional domain controller” senza necessità di far replicare tutto il database AD e la SysVol via rete da un altro DC dello stesso dominio. In tal caso l’installazione viene eseguita “prelevando” le informazioni da un restore locale effettuato in “alternate location” di un System State (i.e.: da un supporto magnetico o media: da cui il termine IFM) valido effettuato su un altro DC dello stesso dominio e dotato di sistema operativo Win2K3 (la procedura non funziona se il backup del System State è originato da un DC Win2K). A tal proposito è consigliato che il System State utilizzato come sorgente (dal quale eseguire la restore locale in modalità “alternate location”) sia prelevato da un DC abilitato come Global Catalog (GC). In questo modo, esiste la possibilità di far diventare il nuovo DC immediatamente GC con tempi di rigenerazione estremamente rapidi (che possono variare da circa 10’ a poco più di un ora, a seconda delle dimensioni della foresta AD). Con l’installazione del Service Pack 1 di Win2K3 esiste la possibile di installare e configurare contestualmente anche il servizio DNS se il DC originario del backup del System State è un DNS server con la zona integrata in AD (DomainDNSZones e ForestDnsZones). Da notare che la suddetta strategia richiede la presenza di una connessione di rete con un altro DC dello stesso dominio. Inoltre essa è utilizzabile solamente in caso di installazione di un “additional domain controller” e si dimostra assolutamente inutile per la reinstallazione di un eventuale primo e unico domain controller di un dominio AD Win2K3. Per ulteriori informazioni sulla modalità di installazione IFM consultare l’articolo Microsoft Knowledge Base 311078: https://support.microsoft.com/default.aspx?scid=kb;EN-US;311078. |
Troubleshooting di problemi correlati al servizio DHCP
Alcuni problemi che si possono presentare nella gestione dei server DHCP in un contesto AD possono essere i seguenti:
Problemi di autorizzazione a rilasciare indirizzi IP: ogni server DHCP Win2K/2K3 che si trova ad operare in un contesto AD deve essere autorizzato da un membro del gruppo Enterprise Admins (o utente/gruppo opportunamente appositamente delegato) per poter rilasciare indirizzi ai client DHCP. Eventuali server DHCP Win2K/2K3 configurati in modalità workgroup (pertanto non autorizzati e non autorizzabili in AD) che si trovano ad operare sulla stessa rete dove sono presenti dei server DHCP Win2K/2K3 autorizzati, verranno da questi ultimi automaticamente “disattivati” e sarà impedito loro di rilasciare indirizzi.
Problemi di autorizzazione a registrare e/o aggiornare resource record in una zona DNS per conto dei client DHCP (DHCP Proxy) oppure presi in carico da un altro server DHCP: in caso di più server DHCP in configurazione fault-tolerant (regola 70/30, ecc.) è necessario inserire i relativi computer account dei server DHCP (ed in casi particolari anche dei client; soprattutto nel caso di aggiornamento di client Win9x a Win2K/XP con il server DHCP configurato per registrare solo i resource record PTR (default)) nel gruppo speciale DnsUpdateProxy in modo da autorizzare la presa in carico del record registrato (i.e.: in effetti permette di eseguire una take ownership sull’oggetto computer account) o da un client oppure da un diverso DHCP server che nel frattempo si è guastato o è stato dismesso.
| |
Prevedere una procedura di backup/restore della configurazione di un server DHCP Per facilitare la reinstallazione e relativa configurazione di un server DHCP Win2K3 è possibile sfruttare le nuove funzionalità di backup/restore dello snap-in DHCP di Win2K3 oppure utilizzare l’utility netsh nel modo seguente:
Altrimenti, non avendo effettuato un precedente salvataggio della configurazione è possible automatizzare la creazione degli scope (e relative configurazione) con il comando netsh come di seguito indicato:
Ad esempio: add scope 10.1.1.0 255.255.255.0 "Scope Milano, Piano 1, Subnet 1" "Sede Centrale Milano" Scope 10.1.1.0 Add iprange 10.1.1.150 10.1.1.254 Scope 10.1.1.0 set state 1 Scope 10.1.1.0 set optionvalue 44 IPADDRESS "10.1.1.10" "10.1.1.11" Scope 10.1.1.0 set optionvalue 51 DWORD "86400" Scope 10.1.1.0 set optionvalue 3 IPADDRESS "10.1.1.1" Scope 10.1.1.0 set optionvalue 15 STRING "learning-solutions.local" Scope 10.1.1.0 set optionvalue 6 IPADDRESS "10.1.1.10" "10.1.1.11" Scope 10.1.1.0 set optionvalue 46 BYTE "8"
netsh -c "dhcp server" -r <NomeServerDhcp> -f <PathFileDefScope> Esempio: netsh –c “dhcp server” –r 10.1.1.10 –f c:\temp\scope.txt |
Troubleshooting di problemi correlati al database AD
Alcuni problemi correlati alle funzionalità del database AD possono essere i seguenti:
Problemi legati allo spazio a disposizione sui volumi che ospitano il database e/o i file di log. Ciò può compromettere la generazione dei file di log per la gestione delle transazioni AD.
Corruzione del database AD.
Necessità di forzare una deframmentazione off-line (e.g.: per ridurre le dimensioni del DB dopo avere cancellato centinaia o migliaia di oggetti).
Rimozione di meta-data di oggetti domain contoller e domini rimasti “orfani” in AD.
Per le operazioni di manutenzione del database AD e dei file di log consultare la sezione “La gestione del database AD” seguente.
Troubleshooting di problemi correlati ai ruoli FSMO
Un malfunzionamento ad un DC detentore di uno dei ruoli FSMO (Flexible Single Master Operation) può causare diversi problemi in una infrastruttura AD:
Creazione di GPO e istanziazione di oggetti Security Principal (SP) (i.e.: utenti, computer e gruppi security): tipicamente determinata dal non disponibilità del DC che svolge il ruolo di PDC Emulator nel dominio. Da notare che problemi in fase di creazione di SP possono essere riscontrati anche a causa della indisponibiltà del DC RID Master, in caso di esaurimento del “blocco” di RID a disposizione di ciascun DC.
Estensione allo Schema AD: dovuta alla indisponibilità del DC che detiene il ruolo di Schema Master oppure al fatto che sullo Schema Master la modifica allo Schema è stata disabilitata.
Creazione e/o cancellazione di domini da una foresta: dovuta alla indisponibilità del DC Domain Naming Master.
Riferimenti errati ad oggetti Security Principal di altri domini della stessa foresta (e.g.: in un gruppo Universale di un dominio A viene elencato un utente appartenente ad un dominio B, anche se l’utente è stato trasferito in un dominio C): ciò in genere è dovuto a problemi con il DC Infrastructure Master locale il quale non è in grado di aggiornare i riferimenti ad oggetti esterni al dominio (chiamati phantom record) tramite l’utilizzo del Global Catalog (GC) oppure in quanto il DC Infrastructure Master è esso stesso GC. In tal caso esso non sarà in grado di aggiornare i puntamenti ai “phantom record” in conseguenza di una cancellazione, spostamento o rinomina dell’oggetto remoto.
Per le operazioni di trasferimento e seizing dei ruoli FSMO si rimanda il lettore al cap. 11 “I ruoli Flexible Single Master Operation ed il Global Catalog in una infrastruttura Active Directory”.
Troubleshooting di problemi correlati al Global Catalog
Il Global Catalog (GC) è uno degli oggetti più importanti in una infrastruttura AD sia mono-dominio che multi-dominio. Dalla sua disponibilità possono dipendere le seguenti attività:
Creazione utenti.
Autenticazione di utenti (escluso l’utente administrator) che per la prima volta eseguono un logon al dominio.
Buon funzionamento di applicazioni integrate in AD (e.g.: Exchange 2K/2K3 o altre appplicazioni terze parti).
| |
Effettuare dei test su un DC per verificare se è stato eletto come Global Catalog Un modo molto semplice per verificare se un DC è stato configurato come Global Catalog, e soprattutto se, una volta inserito il relativo flag “Global Catalog”, sia già in grado di accettare le richieste sulla porta TCP/3268 (in genere a seconda della struttura di rete l’operazione può anche non essere immediata) è il seguente: portqry –n <IP o Nome DC> -e 3268 –p tcp Esempio: portqry -n 10.1.1.10 -e 3268 -p tcp. |
| |
Alcuni malfunzionamenti in ambiente AD Win2K pre-SP3: “Lingering Objects” In un contesto AD Win2K (Domain Controller, Server e workstation) esiste un problema noto (cf. articolo KB 293421” Domain Controllers Continue to Use Global Catalog Server After It Has Been Demoted”) per il quale anche dopo il declassamento di un DC/GC Win2K a server, altri DC continuano ad inviare query LDAP/GC sulla porta 3268 provocando delle risposte errate e inutile traffico sulla rete. Per risolvere il problema è necessario applicare almeno il SP3. Naturalmente è consigliato installare sempre l’ultimo. Un altro malfunzionamento noto (cf. articoli 314282 “Lingering objects may remain after you bring an out-of-date global catalog server back online” e 317097 “Lingering objects prevent Active Directory replication from occurring”) è quello causato dal ritorno on-line di un DC/GC rimasto off-line (i.e.: spento, fuori rete o che non ha potuto replicare a causa di problemi di configurazione) per un numero di giorni superiore al valore del tombstoneLifetime (di default 60 gg), causando la rimessa in circolazione di oggetti cosiddetti “lingering objects” (i.e.: oggetti esistenti in partizioni read-only (i.e.: nel GC) che contengono alcuni attributi (e.g.: sAMAccountName) appartenenti ad altri oggetti “ancora in vita”). Essi possono presentare dei seri problemi di inconsistenza delle informazioni, di corretta replicazione AD e, non ultimo, di sicurezza. In Win2K pre-SP3 la cancellazione di tali oggetti si presentava difficoltosa se non impossibile. In Win2K SP3 e Win2K3 questo problema è stato risolto inserendo la nuova voce “Strict Replication Consistency” nella chiave seguente dei registry HKLM\System\CurrentControlSet\Services\NTDS\Parameters. Il suo valore di default è 1 (1 = Strict Replication Consistency) in modo da rinforzare la consistenza delle informazioni: nessun oggetto viene accettato da un DC Win2K-SP3 o Win2K3, in conseguenza di un aggiornamento se esso non esiste nella sua replica locale. Viceversa forzando a 0 questa variabile su tutti i DC, si disattiva questo controllo permettendo la riesumazione dei “lingering objects” per tutto il dominio. Questo effetto viene identificato come “Loose Replication Consistency”. Per eliminare i “lingering objects” è necessario utilizzare il seguente comando: repadmin /RemoveLingeringObjects < Nome-DC> <GUID-DC-Sorgente> <NC> dove <GUID-DC-Sorgente> è il GUID del DC che detiene una copia “scrivibile” della partizione o naming context (NC). Per ottenere il GUID eseguire il comando repadmin /shorepl <Nome-DC>. Esempio: repadmin /RemoveLingeringObjects ls-mi-dc-01 04c43d01-44ff-4d90-973e-0a68500c1a9b learning-solutions,dc=local /ADVISORY_MODE Prima di eliminare fisicamente gli oggetti è consigliato utilizzare l’opzione /ADVISORY_MODE. Eessa equivale ad una modalità di tipo “trial” o di prova nella quale vengono solamente visualizzate le azioni che verrebbero portate a termine in caso di esecuzione normale. Infine un altro problema noto era quello causato dalla “pubblicazione” di un Global Catalog non ancora completamente replicato che poteva causare malfunzionamenti in ambiente Exchange 2000/2003 (cf. Articolo KB 304403 “Exchange Considerations for Promoting a DomainController to A Global Catalog Server”). In Win2K SP3 e Win2K3 questo problema è stato risolto inserendo la nuova value “Global Catalog Promotion Complete” nella chiave seguente dei registry HKLM\System\CurrentControlSet\Services\NTDS\Parameters. Essa per default vale 1 ed impone al nuovo GC di “pubblicarsi” in AD solamente quando tutte le partizioni read-only del GC sono state completamente replicate. |
Per ulteriori informazioni sul Global Catalog e sulla sua gestione si rimanda il lettore al cap. 11 “I ruoli Flexible Single Master Operation ed il Global Catalog in una infrastruttura Active Directory”.