Tags: active-directory, ldap, kerberos, domain-controller, windows-server, group-policy, identity
Level: intermediate
TL;DR: Directory service centralizzato di Microsoft basato su LDAP, Kerberos e DNS per autenticazione, autorizzazione e gestione di risorse Windows enterprise.
Struttura logica gerarchica basata su Domain, Tree e Forest con schema condiviso.
Organizational Unit (OU) contenitore logico per raggruppare utenti, gruppi e computer.
Domain Controller (DC) server che ospita il database NTDS.dit e gestisce le richieste.
Global Catalog (GC) replica parziale distribuita per ricerche rapide cross-domain.
Autenticazione primaria tramite Kerberos v5 con fallback su NTLM.
Protocollo LDAP e LDAPS per query e modifiche agli oggetti della directory.
FSMO Roles assegnati a specifici DC per operazioni a master singolo.
Group Policy Objects (GPO) per applicare configurazioni centralizzate su OU.
DNS integrato essenziale per la localizzazione dei servizi tramite record SRV.
Trust relationships per federare e consentire accessi sicuri tra domini o foreste differenti.
Q: Qual e' la differenza tra Active Directory Domain Services (AD DS) e LDAP?R: LDAP e' il protocollo standard aperto per interrogare e modificare directory service; AD DS e' l'implementazione completa enterprise di Microsoft che include database, Kerberos, DNS, replica e GPO oltre a supportare LDAP.
Q: Quali sono i cinque ruoli FSMO e perche' sono importanti?R: Schema Master e Domain Naming Master sono a livello di foresta; PDC Emulator, RID Master e Infrastructure Master sono a livello di singolo dominio. Garantiscono che operazioni critiche a scrittura singola non creino conflitti di replica.
Q: Come gestisci l'autenticazione di un'applicazione web o di un backend verso Active Directory?R: Integro l'applicazione tramite LDAP/LDAPS con un service account dedicato con privilegi minimi, oppure sfrutto Kerberos / SAML / OIDC tramite Active Directory Federation Services o Azure AD / Entra ID.
Disallineamento dell'orologio NTP superiore a 5 minuti tra client e DC, che blocca l'autenticazione Kerberos.
Utilizzo di LDAP in chiaro (porta 389) anziche' LDAPS (porta 636) o STARTTLS, esponendo credenziali in rete.
Assegnazione eccessiva di permessi a livello di Domain Admin anziche' ricorrere alla delega granulare su OU.
Fallimenti di risoluzione dei record SRV su DNS che causano mancata individuazione dei DC.
Confusione tra Security Groups (usati per ACL e permessi) e Distribution Groups (solo email).
Esecuzione non sicura di query LDAP senza escaping dei filtri, con rischio di LDAP injection.
# Verifica dei ruoli FSMO nel dominio
Get-ADDomainController -Filter * | Select-Object Name, Forest, OperatingSystem
netdom query fsmo
# Ricerca utenti disabilitati o bloccati
Search-ADAccount -AccountDisabled -UsersOnly
Search-ADAccount -LockedOut
# Recupero dettagli e appartenenza a gruppi di un utente specifico
Get-ADUser -Identity "jdoe" -Properties MemberOf, AccountExpirationDate, LastLogonDate
# Controllo dello stato di replica tra tutti i Domain Controller
repadmin /replsummary
repadmin /showrepl
Bash
# Test di query LDAP su porta sicura con ldapsearch
ldapsearch -H ldaps://dc01.corp.local:636 \
-x -D "bind_user@corp.local" -W \
-b "dc=corp,dc=local" "(sAMAccountName=jdoe)" \
cn mail memberOf
[ ] Sequenza di fallback e handshake del protocollo Kerberos (AS-REQ, TGT, TGS-REQ, Service Ticket)
[ ] Procedure di seize e transfer dei ruoli FSMO in caso di guasto del Domain Controller
[ ] Meccanismi di prevenzione e sanitizzazione di attacchi LDAP injection nel codice backend
[x] Differenza tra Security Group e Distribution Group
[x] Configurazione e porta standard LDAPS su TLS