Utente AD non può cambiare password: audit delle ACE Deny

Utente AD non può cambiare password: che cosa significa questa impostazione?

Per diagnosticare il caso utente AD non può cambiare password, esaminate la lista di controllo degli accessi discrezionale (DACL) dell’utente prima di modificare i criteri delle password del dominio. All’account potrebbe essere negato il diritto esteso Change Password. Si tratta di una restrizione di controllo degli accessi al cambio autonomo della password, una questione distinta dalla possibilità per un amministratore di reimpostarla.

Partite dall’account esatto e dall’operazione non riuscita. Registrate se la persona ha tentato di cambiare la propria password oppure ha chiesto a un operatore dell’assistenza di impostarne una nuova. Una reimpostazione amministrativa riuscita non dimostra che il cambio autonomo sia consentito. Allo stesso modo, un cambio autonomo non riuscito non identifica da solo un’ACE Deny come causa: occorre ancora leggere la DACL.

Questa guida esamina una condizione specifica di autorizzazione, senza prescrivere una nuova durata o lunghezza delle password. Tenete separata la revisione più ampia dei criteri: la sicurezza delle password in Active Directory riguarda criteri di dominio, scadenza, impostazioni degli account e memorizzazione delle credenziali. Modificare tali controlli non sostituisce l’accertamento delle ACE applicabili all’account esaminato.

Funzionamento: autorizzazione al cambio autonomo e reimpostazione amministrativa

Microsoft identifica il diritto esteso User-Change-Password con il nome visualizzato Change Password e il GUID ab721a53-1e2f-11d0-9819-00aa0040529b. Le prove pertinenti si trovano nel descrittore di sicurezza dell’oggetto utente. Non deducete questo stato da un normale test di bit userAccountControl: la condizione del collector esaminata qui non utilizza tale attributo.

La procedura di modifica LDAP di Microsoft descrive una configurazione standard con ACE specifiche per oggetto per due soggetti: Everyone e SELF. La negazione dell’autorizzazione usa ADS_ACETYPE_ACCESS_DENIED_OBJECT; la concessione usa il corrispondente tipo Allow specifico per oggetto.

Elemento da registrare	Valore per questa revisione	Perché è rilevante
Tipo di oggetto	`ab721a53-1e2f-11d0-9819-00aa0040529b`	Identifica Change Password anziché un’altra autorizzazione sull’oggetto
Soggetto Everyone	`S-1-1-0`	Uno dei soggetti accettati dal predicato del collector
Soggetto SELF	`S-1-5-10`	L’altro soggetto accettato dal predicato
Direzione dell’ACE	Deny	Una voce Allow non soddisfa il rilevatore
Destinazione	Nome distinto esatto dell’utente	Consente di associare la prova all’account corretto

Preservate la distinzione tra la configurazione documentata e la condizione del rilevatore. L’esempio di lettura Microsoft riconosce lo stato standard di negazione quando le ACE di entrambi i soggetti sono Deny. Il collector usa una condizione OR: un’ACE Deny corrispondente per uno qualsiasi dei due soggetti è sufficiente per il suo predicato. Registrate una singola ACE corrispondente come una condizione relativa a un solo soggetto da esaminare; non descrivetela come la configurazione completa a due ACE dell’esempio Microsoft.

La reimpostazione amministrativa della password è una questione di autorizzazione separata. L’articolo su ResetNightmare tratta un exploit di un’operazione sulle password Kerberos e la distinzione rispetto ai diritti Reset Password delegati. Fornisce il contesto per separare le operazioni, non la prova che questa restrizione al cambio autonomo causi tale exploit. Valutate l’esposizione distinta usando i prerequisiti e le indicazioni di rimedio dell’articolo collegato.

Rilevamento: leggere la DACL in modo indipendente

Passaggio 1: scegliere un account e preservare il contesto

Usate il nome distinto dell’account anziché un nome visualizzato ipotizzato. Annotate il proprietario, lo stato abilitato o disabilitato, la finalità aziendale, il controller di dominio interrogato e l’ora dell’ispezione. Includete gli account disabilitati nell’inventario se lo confrontate con questo predicato del collector: Detect() non ha un filtro Disabled. Lo stato dell’account può influire sulla priorità del rimedio, ma non deve eliminare silenziosamente una voce dalla revisione delle autorizzazioni.

Per un’identità di servizio, identificate chi è responsabile dei cambi di password prima di classificare la restrizione come indesiderata. Occorre stabilire se sia intenzionale e supportata da un processo con un responsabile. La sola etichetta di account di servizio non è una prova sufficiente per un’eccezione.

Passaggio 2: recuperare e filtrare le regole di accesso

La procedura di lettura LDAP di Microsoft legge ntSecurityDescriptor, ne ottiene la DACL e poi esamina ObjectType, soggetto e AceType. Avverte anche che i nomi dei soggetti sono localizzati. Confrontate i SID noti anziché inserire nel codice nomi di account inglesi.

Il seguente adattamento PowerShell in sola lettura usa ADSI tramite .NET su una postazione di amministrazione Windows. Sostituite il controller di dominio e il DN di esempio con valori verificati. Legge direttamente il descrittore di sicurezza della directory, al di fuori del parser delle ACL del collector. Questi comandi non sono stati eseguiti su un dominio per questo articolo.

Add-Type -AssemblyName System.DirectoryServices
$dc = 'dc01.example.test'
$dn = 'CN=Example User,OU=Users,DC=example,DC=test'
$entry = New-Object -TypeName System.DirectoryServices.DirectoryEntry -ArgumentList "LDAP://$dc/$dn"
$entry.psbase.Options.SecurityMasks = [System.DirectoryServices.SecurityMasks]::Dacl
$descriptor = $entry.psbase.ObjectSecurity
$rules = @($descriptor.GetAccessRules(
    $true, $true, [System.Security.Principal.SecurityIdentifier]
))
$changePassword = [guid]'ab721a53-1e2f-11d0-9819-00aa0040529b'
$matchingDenies = @($rules | Where-Object {
    $_.ObjectType -eq $changePassword -and
    $_.AccessControlType -eq [System.Security.AccessControl.AccessControlType]::Deny -and
    $_.IdentityReference.Value -in @('S-1-1-0', 'S-1-5-10')
})
$matchingDenies | Select-Object IdentityReference, ObjectType,
    AccessControlType, ActiveDirectoryRights, IsInherited,
    InheritanceType, InheritanceFlags, PropagationFlags | Format-List
$entry.psbase.Dispose()

I riferimenti API documentano ObjectSecurity, SecurityMasks e GetAccessRules. Vengono richieste sia le regole esplicite sia quelle ereditate, e le identità dei soggetti vengono restituite come SID. Conservate le regole non filtrate per una revisione più ampia della DACL; il filtro seleziona deliberatamente solo la condizione di questo articolo.

Se il binding o il recupero del descrittore di sicurezza non riesce, conservate l’errore e contrassegnate l’account come non ispezionato. Una DACL illeggibile non è una DACL vuota. Non sostituite un’ispezione non riuscita con un risultato apparentemente riuscito e privo di problemi.

Passaggio 3: interpretare la forma senza sovrastimare il risultato

Risultato osservato	Che cosa registrare	Azione successiva
Everyone e SELF hanno entrambi voci Deny specifiche per oggetto corrispondenti	Possibile configurazione di negazione per due soggetti	Confermare il diritto di accesso di controllo e l’applicabilità delle regole, quindi esaminare l’intento prima di una modifica mirata
Un solo soggetto ha un’ACE Deny corrispondente	Condizione per un solo soggetto accettata dal predicato del rilevatore	Ispezionare l’intera DACL; non scartarla perché manca l’altra voce
Nessuna ACE Deny corrispondente viene restituita dopo una lettura riuscita	Questa condizione circoscritta non è stata trovata	Proseguire la diagnosi; non è un verdetto completo sull’accesso effettivo o sui criteri delle password
Non è stato possibile recuperare la DACL	Prove mancanti	Risolvere l’errore di lettura prima di trarre conclusioni

L’output include informazioni sui diritti e sull’ereditarietà per consentire al revisore di esaminare l’applicabilità. Il filtro non verifica la maschera di accesso né l’applicabilità dell’ereditarietà. Prima di classificare una coppia come la configurazione standard Microsoft, confrontatela con la maschera ADS_RIGHT_DS_CONTROL_ACCESS e i flag delle ACE della procedura di modifica. È un inventario mirato delle ACE, non un’implementazione completa del controllo di accesso Windows. Autorizzazioni ampie, altri soggetti e configurazioni delle ACL non standard richiedono ulteriori valutazioni. Non contate due ACE corrispondenti su un account come due account interessati, né letture diverse dello stesso DN come identità differenti.

Rimedio: ripristinare il cambio autonomo solo per gli account approvati (Remediation)

Passaggio 1: documentare l’intento e lo stato precedente

Assegnate un responsabile a ogni account esaminato e conservate le prove della DACL prima di modificarla. Registrate se il cambio autonomo deve essere disponibile, chi ha approvato la decisione e quale dipendenza operativa va verificata. Se mantenete una restrizione, documentate il motivo aziendale, il team responsabile, la procedura di gestione delle password e il momento di riesame. Evitate di concedere o rimuovere autorizzazioni su un’intera OU solo perché un utente ha segnalato un errore.

Esaminate le regole esplicite ed ereditate prima di scegliere la modifica. Se la restrizione deriva da una regola ereditata, identificate la sua origine e la popolazione interessata. Rimettete tale decisione sull’ambito al responsabile della directory anziché trattare una modifica a livello superiore come una correzione di un singolo account.

Passaggio 2: effettuare una modifica mirata

Microsoft documenta CannotChangePassword in Set-ADAccountControl. Il suo esempio descrive l’impostazione del descrittore di sicurezza dell’utente. L’adattamento seguente rimuove la restrizione per un solo account approvato; visualizzatene prima l’anteprima con -WhatIf.

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -WhatIf

Una volta approvati la destinazione e il cambiamento, eseguite l’operazione sul singolo account con conferma:

Set-ADAccountControl -Identity 'CN=Example User,OU=Users,DC=example,DC=test' -Server 'dc01.example.test' -CannotChangePassword $false -Confirm

Sono adattamenti di comandi documentati, non comandi eseguiti durante questa revisione. Un’anteprima non prova che la scrittura successiva sia riuscita. Acquisite il risultato dell’operazione effettiva e controllate eventuali errori prima di passare alla validazione.

Per un’implementazione LDAP personalizzata, seguite la procedura di modifica Microsoft: individuate le voci Change Password per entrambi i soggetti, cambiate il loro AceType specifico per oggetto in Allow, aggiungete le voci mancanti con la maschera di accesso di controllo e il flag del tipo di oggetto documentati, quindi scrivete e confermate il descrittore di sicurezza. Seguite il passaggio relativo all’ordinamento delle ACL quando create le voci. Non sostituite l’intera DACL con una coppia minima di regole e non eliminate autorizzazioni non pertinenti per far apparire l’account conforme.

Passaggio 3: rileggere e verificare l’operazione prevista

Dopo la scrittura, recuperate nuovamente il descrittore di sicurezza e ripetete la procedura di lettura Microsoft. Confrontate entrambi i soggetti, il GUID e l’AceType con lo stato precedente. Mantenete visibili le eventuali restrizioni ereditate residue. Una risposta riuscita del comando è un artefatto intermedio; la DACL dopo la modifica costituisce la prova delle autorizzazioni.

Organizzate quindi una verifica controllata del cambio autonomo da parte del proprietario dell’account mediante il normale flusso di cambio password. Tenete tale esito separato dal risultato della DACL. Se l’operazione continua a non riuscire, indagate l’errore effettivo e gli altri controlli applicabili anziché modificare ripetutamente l’ACL o indebolire i criteri di dominio. Una reimpostazione dell’assistenza non è la verifica del ripristino del cambio autonomo.

Come EtcSec rileva questa condizione

L’identificatore di catalogo per questa condizione è USER_CANNOT_CHANGE_PASSWORD. Nell’implementazione esaminata di cannot-change.go, Detect() analizza le voci ACL fornite e seleziona quelle con:

un ObjectType uguale al GUID Change Password, confrontato senza distinzione tra maiuscole e minuscole;
un AceType che contiene DENIED dopo la conversione in maiuscolo;
un soggetto uguale a Everyone S-1-1-0 oppure SELF S-1-5-10.

Converte in minuscolo i DN degli oggetti selezionati in una mappa, quindi li confronta con i DN degli utenti. In questo modo deduplica le ACE corrispondenti per DN dell’account prima di costruire l’elenco degli utenti interessati. Il Count del rilievo deriva da tale elenco e non esiste un filtro Disabled. Un’ACE Allow non soddisfa il predicato e l’implementazione non legge un flag userAccountControl per stabilire questa condizione. Non verifica neppure la maschera di accesso o l’applicabilità dell’ereditarietà: una corrispondenza del predicato, da sola, non è quindi un verdetto completo sull’accesso effettivo.

Il confine della raccolta è il limite attuale. In public/internal/providers/ldap/acl_parser.go, parseACE() accetta solo i tipi di ACE ACCESS_ALLOWED e ACCESS_ALLOWED_OBJECT. Gli altri tipi restituiscono nil, incluse le ACE Deny necessarie qui. Un predicato corretto sulle voci fornite non dimostra che il rilevamento funzioni tramite il percorso di raccolta LDAP. Questo articolo non dichiara alcun test del collector dall’inizio alla fine né una validazione su un dominio reale.

Che cosa conservare nel registro della revisione

Per ogni account, preservate il DN esatto, il controller interrogato, il timestamp, i SID dei soggetti corrispondenti, ObjectType, la direzione Deny o Allow, i diritti e il contesto di ereditarietà. Conservate gli errori d’ispezione anziché scartare le letture non riuscite. Associate le registrazioni precedenti e successive alla stessa identità, insieme all’approvazione della modifica o al responsabile dell’eccezione.

La decisione di chiusura deve indicare ciò che è stato accertato: una restrizione mantenuta con un motivo documentato, un’autorizzazione modificata e riletta in modo indipendente, oppure ulteriori indagini ancora aperte. Registrate un esito funzionale del cambio autonomo solo quando tale verifica è stata realmente effettuata. Non trasformate questa revisione delle fonti, un esempio di comando, un’operazione di reimpostazione o un conteggio nullo del collector in una prova di rotazione autonoma riuscita.