Il novanta per cento delle violazioni di sicurezza inizia ancora con credenziali rubate e le directory on-premises rimangono il bersaglio principale. Active Directory compie 25 anni quest'anno, eppure la maggior parte degli stack di identità aziendali si affida ancora a ticket Kerberos emessi dai domain controller che i vostri auditor faticano a comprendere. Il risultato: architetture ibride in cui Entra ID si sovrappone all'AD legacy, Seamless SSO apre vettori di attacco silenziosi e ADFS sopravvive nonostante la silenziosa deprecazione di Microsoft.
Questa guida va oltre i manuali dei vendor. Troverete un framework decisionale sui protocolli che associa Kerberos, SAML, OIDC e FIDO2 a casi d'uso on-prem concreti, una strada pragmatica per le organizzazioni prive di licenze P1/P2, ricette di hardening per la delega Kerberos e una matrice di compliance collegata a NIS2, GDPR e PCI-DSS 8.x. L'obiettivo: fornire ad architetti e CISO la chiarezza tecnica per proteggere il single sign-on negli ambienti ibridi senza ricostruire la directory.
Il vero significato dell'SSO on-prem in un mondo ibrido
Meccanica di base: Kerberos, LDAP, SAML e OIDC contro Active Directory
L'SSO on-prem inizia alla Local Security Authority. Quando un utente accede, la LSA richiede un Ticket-Granting Ticket a un domain controller localizzato, poi scambia ticket di servizio per ogni risorsa on-prem. Entra Connect o Cloud Sync replica verso l'alto UPN, SAM Account Name e attributi di dominio, così un dispositivo unito a Entra riceve il suo Primary Refresh Token insieme all'indicazione di dominio on-prem. Da lì, il dispositivo raggiunge condivisioni file, stampanti e applicazioni LOB tramite Kerberos o NTLM attraverso il DC localizzato.
SAML e OIDC gestiscono le app web federate, ma la directory di riferimento rimane on-prem. Il DC mantiene l'autorità per le sessioni RDP, i thick client, i segmenti SCADA/OT e i carichi di lavoro air-gapped in cui nessun IdP cloud ha visibilità.
Perché Seamless SSO è considerato un rischio di sicurezza
Seamless SSO si affida all'account computer AZUREADSSOACC$ in Active Directory. La sua chiave Kerberos non ruota mai per impostazione predefinita, esponendo il tenant alla falsificazione di Silver Ticket: un attaccante con l'hash può emettere ticket di servizio validi per qualsiasi utente federato. Microsoft raccomanda ora di passare a Cloud Kerberos Trust, alle chiavi di sicurezza FIDO2 o all'autenticazione basata su certificati per un accesso resistente al phishing.
Scelta del protocollo: matrice decisionale per l'SSO on-prem
Confronto diretto: Kerberos, SAML, OIDC, LDAP, FIDO2
La scelta del protocollo determina la superficie di attacco per il prossimo decennio. La matrice valuta ciascuna opzione secondo i criteri che contano per un architetto della sicurezza che implementa l'SSO on-prem.
| Criterio | Kerberos | SAML | OIDC | LDAP | FIDO2 |
|---|---|---|---|---|---|
| Supporto app legacy | Alta | Media | Bassa | Alta | Media (via bridge AD) |
| Resistenza al phishing | Bassa | Bassa | Media | Bassa | Alta |
| Prontezza ibrida | Media | Alta | Alta | Bassa | Alta |
| Funzionamento offline | Sì | No | No | Sì | Sì |
| Costo di licenza | Incluso | Variabile | Basso | Incluso | Solo hardware |
| Complessità di implementazione | Media | Alta | Media | Bassa | Bassa |
| Granularità dell'audit | Media | Alta | Alta | Bassa | Alta |
Verdetti: thick client → Kerberos; SaaS web → SAML o OIDC; RDP/RemoteApp → Kerberos + FIDO2; reti OT → LDAP + bridge FIDO2.
Diagramma decisionale e combinazione di protocolli
Combinare i protocolli in modo deliberato. Mantenere Kerberos per le risorse integrate in Windows, SAML per il SaaS federato con proxy verso AD, FIDO2 come autenticatore universale. Applicare una rigorosa igiene degli SPN, claim UPN coerenti e un singolo cookie di sessione per evitare doppie richieste di autenticazione.
Tre architetture SSO on-prem senza ADFS né Entra ID P1/P2
Architettura 1 — Solo Kerberos con Active Directory nativo
Utilizzate ciò che il domain controller già fornisce: SPN registrati con setspn, Windows-Integrated Authentication su IIS e Group Policy che distribuisce le whitelist dei browser. Nessun IdP aggiuntivo, nessuna dipendenza cloud. La copertura si ferma alle applicazioni intranet che utilizzano Kerberos o NTLM.
Architettura 2 — Proxy SAML collegato ad AD per SaaS e app web legacy
Un appliance SAML leggero collegato ad AD per SaaS e app web legacy (Keycloak, SimpleSAMLphp, Shibboleth) legge gli utenti via LDAP, emette asserzioni verso il SaaS e fa da intermediario OIDC per le app moderne. Nessun Entra Connect, nessun Intune, nessuna licenza P1/P2. L'implementazione si completa in pochi giorni su una singola VM.
Architettura 3 — Bridge di autenticazione FIDO2 + AD per SSO senza password
Il modello Hideez Server per SSO passwordless FIDO2 + AD abbina chiavi FIDO2 a un bridge di autenticazione on-prem che emette ticket Kerberos dopo la verifica hardware. Copre il login Windows, RDP e la delega alle app legacy. La registrazione, il recupero delle chiavi e la console di amministrazione funzionano in locale.
Proteggere l'SSO on-prem: autenticazione resistente al phishing e hardening Kerberos
Chiavi hardware FIDO2 e hardening della delega Kerberos
L'integrazione delle chiavi hardware segue un percorso prevedibile: registrare la credenziale FIDO2 sull'oggetto utente, abilitare l'emulazione smart card e lasciare che Kerberos PKINIT emetta un TGT dopo che la chiave sblocca il certificato. YubiKey, Token2 e Hideez Key coprono il login Windows e RDP attraverso lo stesso flusso.
Il hardening di Kerberos è imprescindibile. Disabilitare la delega senza vincoli in tutta la foresta, applicare solo AES-256, controllare gli SPN con setspn -X e inserire ogni identità di Livello 0 nel gruppo Protected Users. Questo neutralizza il Kerberoasting, la falsificazione di golden ticket e i percorsi DCSync.
Applicare Zero Trust sopra l'SSO on-prem
Il domain controller rimane; la fiducia implicita, no. Aggiungere un MFA contestuale all'IdP, inviare segnali di postura del dispositivo dall'agente endpoint, proteggere le azioni di amministrazione con l'elevazione just-in-time e rivalutare le sessioni al variare del rischio. La directory continua a funzionare; la verifica diventa continua.
Risoluzione dei problemi, migrazione da ADFS e compliance
Principali modalità di guasto e comandi di diagnostica
La maggior parte degli incidenti SSO on-prem riconduce a sei guasti ricorrenti. I timeout DCLocator emergono quando il client non riesce a raggiungere un DC scrivibile; verificate con nltest /dsgetdc:contoso.corp.com e controllate l'affinità del sito. Gli errori di risoluzione NETBIOS che restituiscono STATUS_BAD_VALIDATION_CLASS 0xc00000a7 indicano che l'applicazione ha inviato contoso\user invece di un UPN; forzate la sintassi user@contoso.corp.com. Le discrepanze UPN rompono le asserzioni SAML, il disallineamento dell'orologio Kerberos oltre 5 minuti invalida i ticket (verificate con w32tm /monitor), gli SPN duplicati impediscono l'emissione dei ticket (setspn -X li individua) e le catene di certificati interrotte uccidono PKINIT. Utilizzate klist purge e poi klist per ispezionare i ticket in cache.
Migrazione da ADFS e mappatura a NIS2, GDPR, HIPAA, PCI-DSS
Dismettere ADFS per fasi: censire le relying party, classificarle per protocollo (WS-Fed vs SAML o OIDC), selezionare lo stack di destinazione, far coesistere i sistemi, poi effettuare il cutover. Mappare i controlli su NIS2 Art. 21, GDPR Art. 32, HIPAA §164.312(a)(2)(i) e PCI-DSS 8.3–8.5.
Domande Frequenti
Posso configurare l'SSO on-prem senza ADFS né la licenza completa Microsoft Entra ID P1/P2?
Sì. Un'architettura basata solo su Kerberos supportata da Active Directory fornisce il single sign-on per le workstation unite al dominio senza alcun livello cloud. Per le app moderne, abbinate un proxy SAML leggero o un provider di identità on-prem con AD come fonte di directory. Hideez Server combinato con chiavi FIDO2 copre il login Windows, RDP e le risorse legacy senza Entra ID P1/P2.
Quali chiavi hardware FIDO2 supportano l'SSO on-prem senza password con Active Directory?
Qualsiasi autenticatore certificato FIDO2 funziona, inclusi Hideez Key, YubiKey e Feitian. Per AD on-prem, la chiave deve supportare il flusso di verifica utente WebAuthn ed essere abbinata a un server che intermedie ticket Kerberos dopo l'attestazione.
Come accedono i dispositivi uniti solo a Entra alle condivisioni file on-prem e alle applicazioni legacy?
Tramite Cloud Kerberos Trust o un server di autenticazione on-prem che emette TGT dopo la verifica FIDO2, fornendo al dispositivo una sessione Kerberos valida per i percorsi UNC e le app integrate in Windows.
Pronti a dismettere ADFS e implementare un SSO resistente al phishing nel vostro ambiente ibrido? Prenotate una demo tecnica con il team Hideez o esplorate il programma partner Hideez per portare l'accesso passwordless FIDO2 ai vostri clienti.
