Diritti AD sul nome DNS convalidato: esaminare l’ACE

Cosa significano i diritti AD sul nome DNS convalidato

I diritti AD sul nome DNS convalidato regolano un aggiornamento vincolato di dNSHostName su un oggetto della directory. Un’ACE contenente il GUID associato è un motivo per esaminare una delega. Prima di modificarla, stabilite chi riceve l’autorizzazione, se la sua maschera concede effettivamente la scrittura convalidata, se si applica al computer e quale operazione di provisioning ne ha bisogno.

Microsoft identifica Validated-DNS-Host-Name tramite il GUID 72e39547-7b18-11d1-adef-00c04fd8d5cd. L’autorizzazione consente un nome host DNS coerente con i vincoli di denominazione del computer e del dominio. Non stabilisce un’autorizzazione a modificare una zona DNS e non dimostra che qualcuno abbia reindirizzato il traffico.

Il risultato utile di questa revisione è una decisione registrata: una delega approvata, una concessione superflua confermata da rimuovere oppure una questione irrisolta di raccolta o autorizzazione. Un elenco di GUID corrispondenti non basta a prendere tale decisione. Mantenete insieme l’identità dell’oggetto computer, l’ACE e il flusso di lavoro legittimo durante tutta l’indagine.

Come funziona: scrittura convalidata e WriteProperty

La semantica delle scritture convalidate di MS-ADTS distingue il normale accesso RIGHT_DS_WRITE_PROPERTY dalle scritture convalidate. Il normale accesso in scrittura alle proprietà consente i valori ammessi dallo schema dell’attributo senza i controlli aggiuntivi sui valori previsti dalla scrittura convalidata. Un’ACE di scrittura convalidata combina il bit della maschera di accesso RIGHT_DS_WRITE_PROPERTY_EXTENDED con un GUID identificativo in ObjectType; un’ACE senza GUID ObjectType può comprendere tutte le scritture convalidate sull’oggetto.

Il GUID è anche l’identificatore di schema dell’attributo dNSHostName. Di conseguenza, il solo GUID non permette di distinguere un’ACE relativa alla scrittura di quella proprietà da una relativa alla sua operazione di scrittura convalidata. Interpretate insieme la maschera e l’ambito.

Per il percorso convalidato, MS-ADTS specifica i vincoli di dNSHostName: l’oggetto deve essere un computer o un server, oppure una sottoclasse; in AD DS, il nome host combina il sAMAccountName corrente senza il simbolo del dollaro finale con il nome DNS del contesto di denominazione del dominio o un valore consentito di msDS-AllowedDNSSuffixes. Il richiedente deve possedere il diritto di scrittura convalidata. Esaminate questi dati di denominazione quando valutate l’operazione prevista.

Per l’indagine più ampia su proprietario e DACL, utilizzate la revisione della DACL e della proprietà degli oggetti computer. Questa revisione si concentra sulla specifica autorizzazione di scrittura convalidata. I trasferimenti di zona DNS e la configurazione degli aggiornamenti dinamici riguardano un’altra superficie; modificare un’ACE di un oggetto computer non verifica tali impostazioni di zona.

Rilevamento: raccogliere l’oggetto ed esaminare l’ACE completa

Passaggio 1: stabilire il perimetro di raccolta

Partite dal DN interessato e dalla popolazione di computer prevista. Registrate il controller di dominio, l’ora di raccolta, le credenziali usate per la lettura, la base di ricerca e le eventuali OU escluse. Confrontate la popolazione con l’ambito previsto dall’amministratore. La lettura riuscita di un oggetto non stabilisce nulla sui computer omessi dall’inventario.

Utilizzate una workstation amministrativa Windows con il modulo PowerShell ActiveDirectory per leggere gli oggetti. L’esempio seguente, basato sulla documentazione, usa i parametri supportati Identity, Server e Properties di Get-ADObject, con valori illustrativi da sostituire per il vostro ambiente:

Get-ADObject -Identity "CN=APP01,OU=Servers,DC=example,DC=com" -Server "dc01.example.com" -Properties objectClass,sAMAccountName,dNSHostName,nTSecurityDescriptor

Confermate il DN e la classe restituiti prima di interpretare le autorizzazioni. Conservate il descrittore per un’ispezione dettagliata, insieme ai valori dell’account e del nome host. Non definite un descrittore non disponibile come una DACL vuota. Registrate separatamente le letture fallite e ripetetele con un’identità di raccolta autorizzata prima di trarre conclusioni sulla copertura.

Passaggio 2: inventariare l’ACL

La documentazione di riferimento di Dsacls di Microsoft descrive come visualizzare le ACE di un oggetto fornendo il suo DN tra virgolette senza opzioni di modifica. Eseguite il comando da un prompt dei comandi Windows con privilegi elevati e autorizzazioni di lettura della directory:

dsacls "\\dc01.example.com\CN=APP01,OU=Servers,DC=example,DC=com"

Questo è un esempio di sintassi adattato a un DN di computer illustrativo, non una verifica eseguita in un ambiente. Esaminate le voci di autorizzazione complete, usando la scheda Sicurezza dell’oggetto per una revisione dettagliata dell’ambito quando necessario. Registrate il SID e l’identità risolta di ogni destinatario, il tipo di ACE, la maschera di accesso, ObjectType, l’origine dell’ereditarietà e l’applicabilità. Conservate il descrittore originale anziché soltanto una visualizzazione filtrata del GUID.

Passaggio 3: risolvere maschera, destinatario ed ereditarietà

Le indicazioni Microsoft sulle autorizzazioni di aggiunta al dominio illustrano l’ACE di scrittura convalidata DNS con la maschera 0x00000008, denominata ACTRL_DS_SELF, e il GUID del nome host DNS. Questo nome della maschera è distinto dal destinatario denominato SELF: anche un account usato per l’aggiunta al dominio può ricevere il bit di scrittura convalidata. Verificate se il bit pertinente è presente nella maschera raccolta; una maschera diversa o combinata richiede una propria interpretazione.

MS-ADTS Checking Access spiega Principal Self, SID S-1-5-10: su un oggetto principal di sicurezza, rappresenta il principal di quell’oggetto e viene sostituito con il SID dell’oggetto durante il controllo di accesso. Il DC valuta il contesto di sicurezza del richiedente, l’accesso richiesto e il descrittore appropriato. Risolvere un nome visualizzato o vedere un’ACE di autorizzazione non costituisce questa valutazione completa.

Esaminate i destinatari basati su gruppi rispetto all’identità effettiva di aggiunta al dominio o provisioning. Chiedete al responsabile del flusso di lavoro quale identità esegue ogni passaggio e quali macchine può gestire. Non considerate un gruppo con un nome riferito alla distribuzione come prova che ogni membro necessiti dell’accesso a tutti i computer.

Le regole di ereditarietà di Microsoft distinguono le ACE ereditate dalle ACE destinate solo all’ereditarietà. Una voce destinata solo all’ereditarietà non si applica all’oggetto che la contiene. Risalite al contenitore di origine e all’ambito della classe di oggetto; valutate la voce come appare sul computer di destinazione anziché supporre che una voce del contenitore padre abbia la stessa applicabilità ovunque.

Passaggio 4: separare le prove attese, osservate e sconosciute

Utilizzate questa scheda per ogni computer interessato. È un modello di revisione, non un rapporto di risultati misurati:

Correzione: esaminare il flusso di lavoro, poi modificare la delega (Remediation)

Passaggio 1: preservare lo stato iniziale e stabilire la necessità

Salvate il descrittore originale e la scheda di revisione. Concordate l’operazione richiesta con i responsabili delle macchine e del provisioning prima di modificare. Separate la creazione di un nuovo account computer dal riutilizzo di uno esistente. Le indicazioni Microsoft sull’aggiunta al dominio includono l’autorizzazione di scrittura convalidata DNS tra i diritti necessari all’identità di aggiunta quando si riutilizza un account; la presenza di questo diritto può quindi essere intenzionale.

Per un’eccezione mantenuta, registrate il SID del destinatario, il diritto esatto, la popolazione di oggetti, l’origine dell’ereditarietà, la finalità, il responsabile e la data di revisione. Includete le prove a sostegno della decisione e le questioni ancora aperte. Un’eccezione deve spiegare perché la delega è necessaria su questi computer, anziché limitarsi a dire che lo scanner l’aveva già segnalata.

Passaggio 2: rimuovere o restringere la voce superflua confermata

Usate la scheda Sicurezza dell’oggetto per modificare la specifica autorizzazione superflua. Se è ereditata, esaminate e correggete la delega di origine con il responsabile dell’OU, controllando gli altri destinatari prima di applicare la modifica. Preservate le autorizzazioni necessarie al flusso di lavoro rimanente e verificate l’ambito dell’ACE risultante.

La documentazione indica che dsacls /R rimuove tutte le ACE del destinatario specificato. Non è adatto a rimuovere soltanto l’accesso di scrittura convalidata DNS da un destinatario che deve conservare altre autorizzazioni. Non sostituite una modifica di ACE esaminata con la rimozione di tutte le voci di un destinatario, né ripristinate l’intero descrittore di sicurezza dell’oggetto per far scomparire un rilievo.

Passaggio 3: verificare le autorizzazioni e l’operazione prevista

Leggete nuovamente il computer e la sua ACL dal DC scelto. Confrontate il descrittore risultante con lo stato iniziale e documentate precisamente quale voce è cambiata. Confermate che il destinatario esaminato non disponga più dell’autorizzazione effettiva indesiderata tramite un’altra voce applicabile. Per le modifiche ereditate, campionate la popolazione pertinente di destinatari e verificate il limite previsto della classe di oggetto.

Testate il flusso approvato di aggiunta al dominio o provisioning su un computer di test rappresentativo, con l’identità delegata effettiva. Registrate l’operazione eseguita, se è riuscita e gli eventuali errori della directory. Su un membro del dominio, il test del canale sicuro di Microsoft offre un controllo funzionale aggiuntivo, da eseguire localmente in Windows PowerShell con privilegi elevati:

Test-ComputerSecureChannel -Verbose

Questo verifica la relazione del membro con il dominio; non stabilisce che il provisioning del nome host funzioni o che la revisione dell’ACL sia completa. Microsoft avverte che la cmdlet restituisce errori falsi positivi sui controller di dominio. Questi comandi sono stati citati dalla documentazione, non eseguiti in un ambiente cliente.

Come EtcSec rileva questo caso

Il controllo di etc-collector ACL_COMPUTER_WRITE_VALIDATED_DNS, esaminato al commit 15fc6399c215eabc415c370b762303cfcd7a353a, crea un insieme dei DN di computer raccolti senza distinguere maiuscole e minuscole. Conserva i record ACLEntry il cui ObjectType è uguale a 72e39547-7b18-11d1-adef-00c04fd8d5cd e il cui ObjectDN appartiene a tale insieme. Count rappresenta i computer distinti interessati; quando è diverso, TotalInstances registra il numero di voci corrispondenti.

Detect() non filtra SELF o altri destinatari, non verifica la maschera di scrittura convalidata, non valuta l’applicabilità delle voci di sola ereditarietà e non calcola i diritti effettivi. Il suo output è un punto di partenza di inventario per la revisione sopra descritta. La descrizione del rilevatore menziona spoofing DNS e MITM, ma il predicato implementato non dimostra nessuno dei due risultati.

Anche la raccolta limita l’interpretazione. Il provider LDAP richiede OWNER, GROUP e DACL con i flag del descrittore di sicurezza 0x07, senza la SACL. Ignora gli errori per oggetto e i descrittori mancanti; gli errori di rete interrompono invece la chiamata principale e possono attivare una riconnessione e un nuovo tentativo. Il parser conserva le ACE di autorizzazione standard e di oggetto, preservando maschera, stato ereditato e InheritOnly, mentre esclude le ACE di negazione. Il rilevatore non usa queste distinzioni per completare un controllo di autorizzazione.

GetComputers e il suo parser forniscono i DN usati per la corrispondenza tra i dati. Un inventario incompleto dei computer lascia incompleto l’ambito del rilevatore. Un risultato pari a zero significa che non vi sono voci corrispondenti nei dati forniti, non che tutti i computer siano stati letti o che nessun principal possa modificare l’attributo. Anche le voci generali di scrittura convalidata senza questo GUID specifico restano fuori dal predicato di corrispondenza. Confrontate gli errori di raccolta e l’ambito prima di accettare uno zero, e registrate la decisione di autorizzazione separatamente dal conteggio dello scanner.