Aggiungere un account al gruppo Protected Users di Active Directory può rompere servizi

Un account aggiunto a Protected Users in Active Directory smette di usare NTLM, non memorizza le credenziali sul device e limita Kerberos alle cifrature più recenti. Il gruppo blocca anche la delega predefinita delle credenziali via CredSSP¹.

Il gruppo applica protezioni non configurabili ai suoi membri, sui sistemi supportati e sui controller di dominio. Microsoft descrive queste protezioni come difesa contro il furto di credenziali. La scelta di inserire un account è quindi anche una decisione di compatibilità, non solo di sicurezza¹. Le restrizioni non dipendono da un’impostazione per utente. Una volta dentro il gruppo, non si possono aggirare le limitazioni su quell’account¹.

Le conseguenze toccano protocolli e meccanismi diffusi. I membri non usano NTLM e Digest, non delegano le credenziali in modo predefinito tramite CredSSP, non si appoggiano al caching locale delle credenziali. Kerberos resta limitato a cifrature più nuove. Servizi che richiedono NTLM, cifrature Kerberos legacy o credenziali memorizzate possono quindi fallire¹.

Questo non è un effetto collaterale raro. È il comportamento previsto dopo l’aggiunta al gruppo, perché le protezioni eliminano proprio quei percorsi di autenticazione. Un intervento di hardening senza analisi preliminare può quindi trasformarsi in un’interruzione operativa e costringere a un ripristino non pianificato¹.

La raccomandazione è avviare un pilot mirato per individuare le dipendenze, prima di estendere la membership in produzione. Il test deve verificare se esistono app che usano NTLM, servizi o configurazioni che negoziano Kerberos con cifrature obsolete, o componenti che basano l’accesso su credenziali in cache. Vanno coperti anche gli scenari di delega delle credenziali tramite CredSSP. L’obiettivo è scoprire i punti di rottura prima che emergano in esercizio¹.

La platea giusta non è “tutti”. I candidati più forti sono gli account interattivi con privilegi elevati, le cui credenziali avrebbero alto valore per un attaccante. La selezione deve restare intenzionale e limitata a identità per cui il bilanciamento tra beneficio di sicurezza e rischio operativo risulta favorevole. Aggiunte indiscriminate aumentano la probabilità di guasti dovuti a dipendenze non aggiornate¹.

C’è un vincolo d’infrastruttura che incide sul comportamento del gruppo: alcune restrizioni lato controller di dominio dipendono dal domain functional level. Prima di pianificare la membership occorre verificare l’ambiente, perché le caratteristiche effettive possono variare in base a quel livello. Attribuire al gruppo proprietà non attive nel dominio porta a conclusioni errate e a decisioni di change non allineate con la realtà dell’infrastruttura¹.

In sintesi operativa, il percorso suggerito dalla fonte unisce scoping, test e verifica dell’ambiente: selezionare gli account ad alto privilegio, eseguire un pilot che cerchi uso di NTLM, cifrature Kerberos legacy, caching locale e delega di credenziali, controllare il domain functional level. Solo dopo, procedere con l’aggiunta al gruppo¹.