Protected Users in Active Directory: cos'è, limiti, adminCount e rollout senza lockout

Perché questo articolo adesso

Dopo aver lavorato su RC4/AES e fallback Kerberos to NTLM, il passo naturale è decidere come proteggere davvero gli account amministrativi umani. In Active Directory, il gruppo Protected Users è uno dei controlli più forti per ridurre abuso credenziali e downgrade auth.

Il punto è che non è solo un flag cosmetico: quando aggiungi un account a Protected Users, imponi vincoli duri che possono rompere flussi legacy in modo immediato.

Obiettivo di questa guida: darti un percorso operativo chiaro per capire cosa cambia, cosa si rompe prima, e come fare rollout senza lockout.

Risposta rapida: cos'è Protected Users

In una frase, Protected Users è un gruppo di Active Directory che costringe gli account amministrativi umani a usare regole di autenticazione più rigide, soprattutto comportamento Kerberos-only e nessun fallback NTLM.

Perché è importante:

• riduce abuso di credenziali e rischio di relay per account privilegiati
• fa emergere subito dipendenze NTLM o SPN nascoste
• è un controllo di hardening, non uno strumento di escalation di privilegi

Ecco alcuni collegamenti utili con le guide già pubblicate:

• RC4 deprecation in Active Directory
• Fallback Kerberos -> NTLM in Active Directory
• SPN in Active Directory: guida pratica con KCD e RBCD
• GPO Security Filtering vs Delegation in Active Directory: differenze critiche per audit e hardening

Indice

• Cosa è Protected Users e quando usarlo davvero
• Protected Users è gruppo privilegiato? Impatto su adminCount
• Prerequisiti tecnici prima del test
  • 1) Baseline identity e dipendenze
  • 2) Stato Kerberos dell'ecosistema
  • 3) Piattaforme e compatibilità
  • 4) Piano di rientro
• Restrizioni lato Domain Controller
  • Niente NTLM per gli account Protected Users
  • No DES o RC4 nel percorso Kerberos
  • Nessuna delega Kerberos per questi account
  • TGT lifetime ridotta e limiti di rinnovo
• Tutti i punti Microsoft su Protected Users: cosa va, cosa non va, impatti
  • 1) NTLM non consentito
  • 2) DES/RC4 bloccati nel percorso Kerberos
  • 3) Delega Kerberos non consentita
  • 4) TGT lifetime ridotta a 4 ore e niente rinnovo oltre il limite
  • 5) Riduzione cache credenziali lato LSASS/endpoint
  • 6) Offline logon limitato
• FAQ: le domande che le persone cercano
  • Cos'è Protected Users in Active Directory?
  • Protected Users dà privilegi amministrativi?
  • Cosa si rompe quando aggiungi un account a Protected Users?
  • Protected Users è utile per account amministrativi umani?
• Mappa concettuale: what works vs what does not work
  • Esempi reali: task che non va vs task corretto
  • Mini-regola pratica per chi legge
• Chicca operativa: usare Protected Users per testare se Kerberos è davvero pulito
  • Procedura rapida
  • Perché funziona bene come test
  • Mappa concettuale troubleshooting (Mermaid)
• Restrizioni lato endpoint
• Metodo di validazione in sicurezza
  • Step 1 - Crea cohort pilota
  • Step 2 - Esegui test matrix reale
  • Step 3 - Verifica auth effettiva
  • Step 4 - Criterio go/no-go
• GPO audit da attivare (fondamentale)
  • Percorso GPO (Advanced Audit Policy)
  • Opzione sicurezza da non dimenticare
  • Verifica rapida sui DC
  • Scope consigliato
• Eventi e log da monitorare
• Rollout progressivo consigliato
  • Wave 1 - Admin non Tier0 critici
  • Wave 2 - Admin privilegiati core
  • Wave 3 - Standard operativo
• Checklist rapida (30 giorni)
• Errori da evitare
• Conclusione

Cosa è Protected Users e quando usarlo davvero

Protected Users è un gruppo di sicurezza globale AD (CN=Protected Users,CN=Users,<domainDN>) introdotto per applicare restrizioni non configurabili su autenticazione e gestione credenziali.

Target corretto:

• account privilegiati umani (Domain Admin, Enterprise Admin, operatori Tier0/Tier1)
• account usati per amministrazione interattiva o run-as controllato

Target da evitare:

• service account tradizionali
• account computer
• account applicativi con dipendenze legacy non ancora bonificate

Nota importante: oltre agli account umani esistono le non-human identities (service account, gMSA, workload identity, app identity). Le trattiamo in un articolo dedicato, perché richiedono criteri diversi rispetto a Protected Users.

Regola pratica: prima risolvi dipendenze Kerberos/NTLM/SPN, poi abiliti Protected Users.

---

Protected Users è gruppo privilegiato? Impatto su adminCount

Risposta breve: Protected Users non è un gruppo privilegiato amministrativo e non assegna privilegi AD di per sé, anzi, potremmo quasi considerare il contrario.

In pratica:

• aggiungere un utente a Protected Users non imposta adminCount=1 da solo;
• adminCount=1 compare quando l'account è (o è stato) membro di gruppi protetti da AdminSDHolder/SDProp (es. Domain Admins, Enterprise Admins, ecc.);
• se un account resta con adminCount=1 dopo la rimozione dai gruppi privilegiati, può mantenere ACL non ereditarie e comportamento "sporco".

---

Prerequisiti tecnici prima del test

Prima di mettere anche un solo account nel gruppo, verifica questi punti.

1) Baseline identity e dipendenze

• mappa applicazioni dove l'utente amministrativo effettua accesso
• mappa protocolli effettivi (Kerberos, NTLM, Negotiate)
• mappa endpoint coinvolti (jump host, server management, bastion)

2) Stato Kerberos dell'ecosistema

• SPN corretti e univoci sui servizi target
• assenza di fallback sistematico verso NTLM
• encryption types coerenti con AES dove richiesto

3) Piattaforme e compatibilità

• Domain Controller e client aggiornati
• tooling amministrativo compatibile con autenticazione Kerberos moderna
• break-glass account esclusi dal perimetro Protected Users

4) Piano di rientro

• gruppo AD o processo rapido per rimuovere account da Protected Users
• runbook validato per incident response auth
• ownership chiara tra IAM, AD team, SOC, operations

---

Restrizioni lato Domain Controller

Queste sono le limitazioni che hanno più impatto operativo:

Niente NTLM per gli account Protected Users

Se un flusso richiede NTLM, l'auth fallisce. Questo è il primo motivo di outage in ambienti con legacy nascosto, ma anche ambienti moderni in cui è stato inibito l'utilizzo di NTLMv1. Questo impedimento fa sì che un account nei Protected Users non potrà mai fare fallback nell'autenticazione se Kerberos non funziona.

No DES o RC4 nel percorso Kerberos

Gli account Protected Users non devono dipendere da cifrature deboli. Se l'ambiente è ancora ancorato a RC4, l'effetto può essere immediato.

Nessuna delega Kerberos per questi account

I token di questi utenti non devono essere delegati (impatto su alcuni scenari hop-to-hop o middleware legacy).

TGT lifetime ridotta e limiti di rinnovo

Durate ticket più restrittive aumentano sicurezza ma stressano processi con sessioni lunghe e automazioni non progettate correttamente.

---

Tutti i punti Microsoft su Protected Users: cosa va, cosa non va, impatti

In questa sezione mettiamo in modo esplicito i controlli dichiarati da Microsoft per il gruppo Protected Users e li traduciamo in impatti operativi.

Riferimento Microsoft: Protected Users Security Group

1) NTLM non consentito

Cosa dichiara Microsoft:

• un account membro di Protected Users non può autenticarsi con NTLM

Cosa funziona:

• accessi Kerberos corretti con SPN e naming allineati

Cosa non funziona:

• qualsiasi scenario che dipende da fallback Kerberos -> NTLM

Impatto operativo:

• emergono subito dipendenze legacy prima nascoste
• riduci superficie pass-the-hash e relay su account admin umani

2) DES/RC4 bloccati nel percorso Kerberos

Cosa dichiara Microsoft:

• per questi account non devono essere usati DES o RC4

Cosa funziona:

• ambienti con AES correttamente abilitato end-to-end

Cosa non funziona:

• servizi legacy che ancora richiedono RC4 o hanno key material non aggiornato

Impatto operativo:

• accelera RC4 remediation reale
• riduce rischio downgrade verso cifrature deboli

3) Delega Kerberos non consentita

Cosa dichiara Microsoft:

• credenziali/ticket di account Protected Users non sono delegabili

Traduzione pratica:

• se un flusso applicativo richiede delega dell'identità utente admin verso un backend, il percorso può interrompersi

Cosa funziona:

• amministrazione diretta 1-hop dove non serve delegation

Cosa non funziona:

• scenari dipendenti da unconstrained delegation
• scenari dipendenti da constrained delegation (KCD) quando serve propagare l'identità dell'utente Protected Users
• catene multi-hop non disegnate per account fortemente protetti

Impatto operativo:

• riduce rischio abuso ticket delegated in caso di compromissione host intermedio
• richiede revisione esplicita dei flussi hop-to-hop amministrativi

4) TGT lifetime ridotta a 4 ore e niente rinnovo oltre il limite

Cosa dichiara Microsoft:

• i membri Protected Users ricevono TGT con lifetime di circa 4 ore
• il TGT non è rinnovabile oltre questa finestra

Cosa funziona:

• sessioni admin brevi, task just-in-time, runbook moderni

Cosa non funziona (o richiede redesign):

• sessioni operative molto lunghe senza re-auth pianificata
• processi che assumevano ticket rinnovabili a lungo

Impatto operativo:

• riduce tempo utile di riuso ticket rubati
• aumenta sicurezza ma impone disciplina operativa su finestre di lavoro

5) Riduzione cache credenziali lato LSASS/endpoint

Cosa dichiara Microsoft:

• per questi account vengono ridotte o impedite varie forme di caching credenziali (es. materiale riutilizzabile per NTLM/digest/plaintext)

Cosa funziona:

• modello di amministrazione da host fidati con connettività DC affidabile

Cosa non funziona:

• workflow che contano su credenziali persistenti in cache
• alcune abitudini legacy di remoting che presuppongono caching locale

Impatto operativo:

• riduzione superficie per credential theft su endpoint compromesso
• necessità di jump host igienici e procedure operative aggiornate

6) Offline logon limitato

Cosa dichiara Microsoft:

• l'esperienza offline/non connessa al DC per account Protected Users è più restrittiva

Cosa funziona:

• accesso con line-of-sight ai Domain Controller

Cosa non funziona:

• aspettarsi lo stesso comportamento di cached logon di account standard

Impatto operativo:

• ottimo per account admin umani (dove vuoi controllo centralizzato)
• da considerare attentamente in scenari DR o siti con connettività fragile

---

FAQ: le domande che le persone cercano

Cos'è Protected Users in Active Directory?

Protected Users è un gruppo di sicurezza fornito da Microsoft che applica restrizioni non configurabili su autenticazione, gestione credenziali e comportamento dei ticket per account amministrativi umani.

Protected Users dà privilegi amministrativi?

No. Non assegna privilegi Active Directory di per sé. In pratica limita come l'account può autenticarsi e quali flussi di credenziali o delega può usare.

Cosa si rompe quando aggiungi un account a Protected Users?

Le rotture più comuni sono workflow dipendenti da NTLM, problemi di SPN, scenari di delega Kerberos e assunzioni su ticket a lunga durata. Per questo è spesso usato come controllo diagnostico molto efficace.

Protected Users è utile per account amministrativi umani?

Sì, quando l'account è un vero account amministrativo umano e l'ambiente è già abbastanza pulito da Kerberos e SPN. È uno dei controlli più forti per ridurre l'abuso delle credenziali di amministrazione.

Mappa concettuale: what works vs what does not work

flowchart TD

PU([Protected Users<br/>Human Administrative Accounts]) --> W[What Works]
PU --> NW[What Does Not Work]
PU --> SI[Security Impact]
PU --> OI[Operational Impact]
PU --> NHI[Non-human identities require a separate playbook]

W --> W1[Kerberos-first authentication with healthy SPNs]
W --> W2[AES-only capable services and clients]
W --> W3[Direct one-hop admin use cases]
W --> W4[Short-lived privileged sessions]

NW --> N1[NTLM Authentication]
NW --> N2[DES or RC4 Dependency]
NW --> N3[Delegation-dependent flows]
NW --> N4[Long Sessions Expecting Ticket Renewal]
NW --> N5[Offline or Cache-Dependent Admin Workflows]

MC[Microsoft-Enforced Controls] --> C1[NTLM Blocked]
MC --> C2[DES and RC4 Blocked]
MC --> C3[Kerberos Delegation Blocked]
MC --> C4[TGT Lifetime About 4 Hours]
MC --> C5[Credential Caching Reduced On Endpoints]
MC --> C6[Offline Logon Behavior More Restrictive]
PU --> MC

SI --> S1[Smaller credential theft surface]
SI --> S2[Reduced downgrade and relay exposure]
SI --> S3[Reduced reuse window for stolen tickets]

OI --> O1[Hidden NTLM dependencies become visible]
OI --> O2[SPN hygiene becomes mandatory]
OI --> O3[Auth Flow Redesign May Be Required]
OI --> O4[Runbooks Need Re-Auth Checkpoints]

RG{Environment Ready For Protected Users Rollout}
PU --> RG
RG -->|Yes| GO([Proceed With Phased Rollout])
RG -->|No| FIX([Remediate Dependencies First])

classDef root fill:#2f5b6b,color:#f5fbff,stroke:#21424f,stroke-width:3px;
classDef section fill:#ffffff,color:#0f1720,stroke:#2f5b6b,stroke-width:2px;
classDef control fill:#ffffff,color:#0f1720,stroke:#d9dde1,stroke-width:1px;
classDef danger fill:#fdecec,color:#0f1720,stroke:#c0392b,stroke-width:2px;
classDef success fill:#e8f5ee,color:#0f1720,stroke:#2e8b57,stroke-width:2px;
classDef warning fill:#fff7e6,color:#0f1720,stroke:#d4a017,stroke-width:2px;
classDef muted fill:#ffffff,color:#4b5a65,stroke:#d9dde1,stroke-width:1px;
classDef decision fill:#ffffff,color:#0f1720,stroke:#2f5b6b,stroke-width:2px;

class PU root;
class W,NW,SI,OI,MC section;
class W1,W2,W3,W4,S1,S2,S3,O1,O2,O3,O4,C1,C2,C3,C4,C5,C6 control;
class N1,N2,N3,N4,N5 danger;
class NHI muted;
class RG decision;
class GO success;
class FIX warning;

Esempi reali: task che non va vs task corretto

Qui sotto trovi esempi pratici nel formato "fatto così non va" -> "fatto in questo altro modo funziona".

Scenario reale	Fatto così non va	Per funzionare va fatto così
Accesso a un'app IIS interna con account admin	URL via alias non registrato, SPN assente, Kerberos fallisce e si spera nel fallback NTLM	Registra SPN HTTP/app.contoso.com sull'account corretto, verifica unicità SPN, forza percorso Kerberos
Query SQL amministrativa da jump host	Connessione a SQL con nome non coerente/SPN duplicato, auth intermittente	Usa FQDN previsto, correggi MSSQLSvc/..., rimuovi duplicati, retest con klist purge
Accesso a server via IP (es. RDP/SMB/WinRM)	Connessione verso 10.10.10.25 e non verso nome host: Kerberos spesso non entra nel flusso corretto e l'ambiente tenta fallback	Usa sempre FQDN (es. srv-admin01.contoso.com), verifica DNS/SPN coerenti, poi retest eventi 4768/4769
Gestione share SMB amministrativa	Accesso legacy che dipende da NTLM trasparente	Assicura Kerberos end-to-end (SPN/CIFS corretto, DNS coerente), elimina dipendenza NTLM dal client/tool
Task multi-hop (jump host -> server app -> backend SQL)	Si richiede delega implicita dell'identità admin Protected Users	Ridisegna il flusso: 1-hop diretto, run-as dedicato non umano dove necessario, oppure modello JIT/PAM
Manutenzione notturna lunga	Sessione unica di 6-8 ore assumendo ticket rinnovabili	Spezza il runbook in finestre con re-auth pianificata entro TGT lifetime (circa 4 ore)
Admin in sito remoto con connettività instabile	Si presume cached logon come per account standard	Usa host con line-of-sight ai DC o bastion locale con connettività affidabile, evita dipendenza offline

Mini-regola pratica per chi legge

• Se un task "funzionava prima" e con Protected Users si rompe, quasi sempre stavi usando una stampella invisibile: NTLM, SPN errato, delega non esplicitata o assunzioni sbagliate su durata ticket/cache.
• Connessioni admin via IP sono una causa classica di problemi silenziosi: usa FQDN come default operativo, non IP.
• Se vuoi validare rapidamente, ripeti lo stesso task in due fasi: prima fuori dal gruppo, poi dentro Protected Users, e confronta eventi 4768, 4769, 4771, 4776.

---

Chicca operativa: usare Protected Users per testare se Kerberos è davvero pulito

Questo è un trucco molto utile in assessment: aggiungere temporaneamente un account amministrativo umano a Protected Users come test di verità del tuo ecosistema Kerberos.

Se il flusso continua a funzionare, hai forte evidenza che non stai vivendo di fallback NTLM o deleghe opache.

Procedura rapida

1. Crea account pilota amministrativo umano (non break-glass).
2. Esegui baseline senza Protected Users:
   • klist purge
   • accesso ai sistemi target (RDP, SMB admin share, RSAT, tool interni)
   • raccolta eventi DC (4768, 4769, 4771, 4776)
3. Aggiungi l'account al gruppo Protected Users.
4. Esegui logoff/logon e attendi replica AD se multi-DC.
5. Ripeti gli stessi test.
6. Interpreta risultato:
   • funziona tutto: Kerberos probabilmente corretto end-to-end
   • qualcosa si rompe: hai dipendenze residue (NTLM, SPN, delega, cifrature)

Perché funziona bene come test

• è veloce
• è ripetibile
• produce segnali chiari nei log
• trasforma un controllo di hardening in strumento diagnostico

Mappa concettuale troubleshooting (Mermaid)

flowchart TD

%% PATH

A([FAILED USE CASE])

A --> B{Authentication Type}

B -->|Kerberos| C[Review Events 4768 and 4769]

B -->|NTLM| N1[NTLM Dependency Detected]

N1 --> N2[Protected Users Blocks NTLM]

N2 --> N3[Application Remediation Required]

N2 --> N4[Remove NTLM Dependency Or Exclude Use Case]

C --> D{SPN Healthy}

D -->|Missing| D1[Validate With setspn -Q]

D -->|Duplicate| D2[Remove Duplicate SPNs]

D -->|Stale| D3[Realign SPN And Service Account]

D -->|Valid| E{AES Negotiated}

D1 --> SPNFIX[SPN Remediation]
D2 --> SPNFIX
D3 --> SPNFIX

E -->|No| E1[RC4 Dependency Detected]

E1 --> E2[Review Encryption Types]

E2 --> E3[Enable AES]

E -->|Yes| F{Kerberos Delegation Required}

F -->|Yes| F1[Delegation Not Supported]

F1 --> F2[Redesign Authentication Flow]

F -->|No| G{TGT Or Session Lifetime Issue}

G -->|Yes| G1[Review TGT Expiration]

G1 --> G2[Validate Ticket Renewal]

G -->|No| H{Endpoint Dependency}

H -->|Offline Login| H1[Credential Cache Required]

H1 --> H2[Redefine Operational Requirement]

H -->|No| I[Collect Additional Evidence]

I --> J{Root Cause Identified}

J -->|Yes| K([TECHNICAL REMEDIATION])

J -->|No| L([CONTROLLED EXCLUSION])

%% REFERENCES

K --> M1[4768 - AS Request TGT]
K --> M2[4769 - TGS Request]
K --> M3[4771 - Kerberos Failure]
K --> M4[4776 - NTLM Authentication]

L --> M5[KDC ERR S PRINCIPAL UNKNOWN]
L --> M6[KRB AP ERR MODIFIED]
L --> M7[NTLM Fallback]

K --> GOAL([KERBEROS FIRST AES ONLY UNIQUE SPNS])

%% COLORS

classDef root fill:#2f5b6b,color:#f5fbff,stroke:#21424f,stroke-width:3px;
classDef section fill:#ffffff,color:#0f1720,stroke:#2f5b6b,stroke-width:2px;
classDef control fill:#ffffff,color:#0f1720,stroke:#d9dde1,stroke-width:1px;
classDef danger fill:#fdecec,color:#0f1720,stroke:#c0392b,stroke-width:2px;
classDef success fill:#e8f5ee,color:#0f1720,stroke:#2e8b57,stroke-width:2px;
classDef warning fill:#fff7e6,color:#0f1720,stroke:#d4a017,stroke-width:2px;
classDef muted fill:#ffffff,color:#4b5a65,stroke:#d9dde1,stroke-width:1px;
classDef decision fill:#ffffff,color:#0f1720,stroke:#2f5b6b,stroke-width:2px;

class A root;
class B,D,E,F,G,H,J decision;
class K,GOAL success;
class N1,N2,D2,E1,F1,H1,L,M5,M6 danger;
class D1,D3,SPNFIX,E2,E3,F2,G1,G2,H2,N3,N4,M7 warning;
class C,I,M1,M2,M3,M4 control;

---

Restrizioni lato endpoint

Oltre al DC, Protected Users riduce la superficie di esposizione sul client/server dove l'utente effettua logon.

Effetti comuni:

• riduzione caching credenziali riutilizzabili
• riduzione persistenza di materiale utile a pass-the-hash / replay
• comportamenti diversi in scenari remoti dove tool legacy si aspettano cache o fallback

Conseguenza pratica: alcuni runbook storici "hanno sempre funzionato" ma non erano hardening-compatible.

---

Metodo di validazione in sicurezza

Step 1 - Crea cohort pilota

• 2-5 account amministrativi non critici ma rappresentativi
• no account break-glass nel pilot
• no account servizio

Step 2 - Esegui test matrix reale

Copri almeno:

• accesso RDP su server management
• accesso SMB a share amministrative
• strumenti AD (MMC, PowerShell remoting, RSAT)
• casi applicativi (IIS/SQL/backend) dove l'utente opera davvero

Step 3 - Verifica auth effettiva

• conferma Kerberos dove previsto
• rileva ogni tentativo NTLM fallito
• traccia failure per host, applicazione, account

Step 4 - Criterio go/no-go

Go solo se:

• nessun blocco operativo critico
• failure residue classificate con remediation pianificata
• SOC e operations allineati sui segnali di monitoraggio

---

GPO audit da attivare (fondamentale)

Hai ragione: se questa parte non è configurata, parlare di eventi serve a poco.

Per raccogliere in modo affidabile 4768, 4769, 4771, 4776, applica una GPO dedicata ai Domain Controller (linkata alla OU Domain Controllers).

Percorso GPO (Advanced Audit Policy)

Computer Configuration
 └─ Policies
	 └─ Windows Settings
		 └─ Security Settings
			 └─ Advanced Audit Policy Configuration
				 └─ Audit Policies
					 └─ Account Logon

Abilita:

• Audit Kerberos Authentication Service -> Success, Failure
• Audit Kerberos Service Ticket Operations -> Success, Failure
• Audit Credential Validation -> Success, Failure

Opzione sicurezza da non dimenticare

Per evitare conflitti con la legacy audit policy, nella stessa GPO imposta anche:

Computer Configuration
 └─ Policies
	 └─ Windows Settings
		 └─ Security Settings
			 └─ Local Policies
				 └─ Security Options
					 └─ Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings = Enabled

Verifica rapida sui DC

Dopo gpupdate /force (o normale refresh GPO), verifica da prompt amministrativo sul DC:

auditpol /get /subcategory:"Kerberos Authentication Service"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"
auditpol /get /subcategory:"Credential Validation"

Se il risultato non mostra Success/Failure attesi, gli eventi nel Security log saranno incompleti o fuorvianti.

Scope consigliato

• questa audit policy va prima sui DC;
• lato endpoint/jump host puoi aggiungere logging complementare, ma i 4768/4769/4771/4776 nascono dal punto di vista autenticazione del dominio.

---

Eventi e log da monitorare

Per il monitoraggio iniziale, lavora su correlazione tra DC Security log e telemetria endpoint.

Eventi utili lato DC:

• 4768 (TGT request)
• 4769 (TGS request)
• 4771 (Kerberos pre-auth failure)
• 4776 (NTLM authentication) per evidenziare dipendenze residue

Lettura pratica per account Protected Users:

• vedi 4768 e 4769 coerenti: Kerberos sta lavorando
• vedi tentativi 4776 associati allo stesso use case: c'è dipendenza NTLM da rimuovere
• vedi failure Kerberos ripetute: controlla SPN, etype, delega e clock skew

Approccio operativo:

• dashboard minima con trend per account Protected Users
• top host con failure ricorrenti
• top servizi con mismatch Kerberos/SPN

---

Rollout progressivo consigliato

Wave 1 - Admin non Tier0 critici

Usa account con uso reale ma impatto contenuto. Obiettivo: trovare dipendenze nascoste.

Wave 2 - Admin privilegiati core

Procedi su account ad alto privilegio solo dopo bonifica dei failure principali.

Wave 3 - Standard operativo

Rendi Protected Users parte del lifecycle IAM per account amministrativi umani.

Controlli obbligatori per ogni wave:

• finestra di osservazione post-change
• runbook rollback testato
• comunicazione operativa ai team coinvolti

---

Checklist rapida (30 giorni)

Settimana 1:

• identifica cohort pilota
• prepara baseline eventi e dashboard
• valida break-glass e rollback

Settimana 2:

• abilita Protected Users su pilot
• esegui test matrix completa
• registra failure e cause

Settimana 3:

• remediation SPN/NTLM/delega
• retest sui casi risolti
• aggiorna runbook operativi

Settimana 4:

• approvazione go/no-go
• avvio wave 2
• review finale con SOC/IAM/AD team

---

Errori da evitare

• aggiungere in Protected Users account servizio "per hardening" senza validazione
• fare rollout massivo senza pilot
• ignorare fallback NTLM storico e SPN debt
• non predisporre percorso rapido di rimozione gruppo in caso di blocco

---

Conclusione

Protected Users è uno dei controlli più efficaci per proteggere account privilegiati umani, ma funziona bene solo se arriva dopo una fase seria di pulizia Kerberos/NTLM.

In pratica: prima elimini le dipendenze legacy, poi applichi enforcement.

Se l'adozione è fatta a wave con test e monitoraggio, ottieni hardening reale senza trasformare il progetto in una sequenza di lockout.

Se vuoi, puoi usare questa guida come checklist operativa per il tuo pilot: parti da 2-5 account amministrativi umani, verifica eventi e dipendenze, poi decidi il go/no-go con evidenze concrete.

Per i prossimi step:

• Contattami se vuoi una approfondire il tema dei Protected Users, adminCount e readiness Kerberos nel tuo ambiente.
• Supporta il progetto su PayPal se queste guide ti aiutano nel lavoro quotidiano.