← Field Guides
Active DirectoryDomain ControllersGroup PolicyHardeningKerberosNTLMProtected UsersSecurity

Protected Users in Active Directory: what it is, limits, adminCount, and rollout without lockout

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:

Indice

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:

Appreciation

If this guide is useful, leave a like.

LinkedIn