Quatre-vingt-dix pour cent des violations de sécurité commencent encore par des identifiants volés, et les annuaires on-premises restent la cible principale. Active Directory fête ses 25 ans cette année, pourtant la plupart des stacks d'identité d'entreprise s'appuient encore sur des tickets Kerberos émis par des contrôleurs de domaine que vos auditeurs comprennent à peine. Le résultat : des architectures hybrides où Entra ID se superpose à un AD hérité, Seamless SSO ouvre des vecteurs d'attaque silencieux et ADFS persiste malgré la déprecation discrète de Microsoft.
Ce guide sort des sentiers balisés par les éditeurs. Vous y trouverez un cadre de décision protocolaire qui associe Kerberos, SAML, OIDC et FIDO2 à des cas d'usage on-prem concrets, une voie pragmatique pour les organisations sans licences P1/P2, des recettes de durcissement pour la délégation Kerberos et une matrice de conformité liée à NIS2, GDPR et PCI-DSS 8.x. L'objectif : donner aux architectes et aux RSSI la clarté technique pour sécuriser le SSO dans les environnements hybrides sans reconstruire l'annuaire.
Ce que signifie vraiment le SSO on-prem dans un monde hybride
Mécanique de base : Kerberos, LDAP, SAML et OIDC face à Active Directory
Le SSO on-prem commence à la Local Security Authority. Lorsqu'un utilisateur se connecte, la LSA demande un Ticket-Granting Ticket à un contrôleur de domaine localisé, puis échange des tickets de service pour chaque ressource on-prem. Entra Connect ou Cloud Sync réplique vers le haut l'UPN, le SAM Account Name et les attributs de domaine, de sorte qu'un appareil joint à Entra reçoit son Primary Refresh Token accompagné de l'indication de domaine on-prem. De là, l'appareil accède aux partages de fichiers, aux imprimantes et aux applications métier via Kerberos ou NTLM par le DC localisé.
SAML et OIDC gèrent les applications web fédérées, mais l'annuaire de référence reste on-prem. Le DC fait autorité pour les sessions RDP, les thick clients, les segments SCADA/OT et les charges de travail air-gapped où aucun IdP cloud n'a de visibilité.
Pourquoi Seamless SSO est considéré comme un risque de sécurité
Seamless SSO repose sur le compte d'ordinateur AZUREADSSOACC$ dans Active Directory. Sa clé Kerberos ne tourne jamais par défaut, exposant le tenant à la falsification de Silver Ticket : un attaquant disposant du hash peut émettre des tickets de service valides pour n'importe quel utilisateur fédéré. Microsoft recommande désormais de passer à Cloud Kerberos Trust, aux clés de sécurité FIDO2 ou à l'authentification par certificat pour un accès résistant au phishing.
Choisir son protocole : matrice de décision pour le SSO on-prem
Comparaison côte à côte : Kerberos, SAML, OIDC, LDAP, FIDO2
Le choix du protocole détermine votre surface d'attaque pour la prochaine décennie. La matrice note chaque option selon les critères qui comptent pour un architecte sécurité déployant un SSO on-prem.
| Critère | Kerberos | SAML | OIDC | LDAP | FIDO2 |
|---|---|---|---|---|---|
| Support des applications héritées | Élevé | Moyen | Faible | Élevé | Moyen (via pont AD) |
| Résistance au phishing | Faible | Faible | Moyenne | Faible | Élevée |
| Compatibilité hybride | Moyenne | Élevée | Élevée | Faible | Élevée |
| Fonctionnement hors ligne | Oui | Non | Non | Oui | Oui |
| Coût de licence | Inclus | Variable | Faible | Inclus | Matériel uniquement |
| Complexité de déploiement | Moyenne | Élevée | Moyenne | Faible | Faible |
| Granularité d'audit | Moyenne | Élevée | Élevée | Faible | Élevée |
Recommandations : thick clients → Kerberos ; SaaS web → SAML ou OIDC ; RDP/RemoteApp → Kerberos + FIDO2 ; réseaux OT → LDAP + pont FIDO2.
Arbre de décision et combinaison de protocoles
Combiner les protocoles délibérément. Conserver Kerberos pour les ressources intégrées à Windows, SAML pour le SaaS fédéré en proxy vers AD, FIDO2 comme authentificateur universel. Appliquer une hygiène stricte des SPN, des claims UPN cohérents et un seul cookie de session pour éviter les doubles invites d'authentification.
Trois architectures SSO on-prem sans ADFS ni Entra ID P1/P2
Architecture 1 — Kerberos uniquement avec Active Directory natif
Tirez parti de ce que le contrôleur de domaine fournit déjà : SPNs enregistrés avec setspn, Windows-Integrated Authentication sur IIS et Group Policy distribuant les listes blanches de navigateurs. Aucun IdP supplémentaire, aucune dépendance cloud. La couverture s'arrête aux applications intranet parlant Kerberos ou NTLM.
Architecture 2 — Proxy SAML relié à AD pour SaaS et applications web héritées
Un appliance SAML léger relié à AD pour SaaS et applications web héritées (Keycloak, SimpleSAMLphp, Shibboleth) lit les utilisateurs via LDAP, émet des assertions vers le SaaS et fait office d'intermédiaire OIDC pour les applications modernes. Sans Entra Connect, sans Intune, sans licences P1/P2. Le déploiement s'effectue en quelques jours sur une seule VM.
Architecture 3 — Pont d'authentification FIDO2 + AD pour SSO sans mot de passe
Le modèle Hideez Server pour SSO sans mot de passe FIDO2 + AD associe des clés FIDO2 à un pont d'authentification on-prem qui émet des tickets Kerberos après vérification matérielle. Il couvre la connexion Windows, RDP et la délégation aux applications héritées. L'inscription, la récupération des clés et la console d'administration fonctionnent en local.
Sécuriser le SSO on-prem : authentification résistante au phishing et durcissement Kerberos
Clés matérielles FIDO2 et durcissement de la délégation Kerberos
L'intégration des clés matérielles suit un chemin prévisible : enregistrer la credential FIDO2 sur l'objet utilisateur, activer l'émulation de carte à puce et laisser Kerberos PKINIT émettre un TGT après que la clé déverrouille le certificat. YubiKey, Token2 et Hideez Key couvrent la connexion Windows et RDP via le même flux.
Le durcissement de Kerberos est non négociable. Désactiver la délégation sans contrainte dans toute la forêt, n'imposer que AES-256, auditer les SPN avec setspn -X et placer chaque identité de Niveau 0 dans le groupe Protected Users. Cela neutralise le Kerberoasting, la falsification de golden ticket et les chemins DCSync.
Superposer Zero Trust au SSO on-prem
Le contrôleur de domaine reste en place ; la confiance implicite, non. Ajouter un MFA contextuel au niveau de l'IdP, transmettre les signaux de posture des appareils depuis l'agent endpoint, protéger les actions d'administration par une élévation just-in-time et réévaluer les sessions en cas de changement de risque. L'annuaire continue de fonctionner ; la vérification devient continue.
Résolution des problèmes, migration depuis ADFS et conformité
Principaux modes de défaillance et commandes de diagnostic
La plupart des incidents SSO on-prem se ramènent à six défaillances récurrentes. Les timeouts DCLocator apparaissent lorsque le client ne peut pas joindre un DC accessible en écriture ; vérifiez avec nltest /dsgetdc:contoso.corp.com et contrôlez l'affinité de site. Les erreurs de résolution NETBIOS renvoyant STATUS_BAD_VALIDATION_CLASS 0xc00000a7 indiquent que l'application a envoyé contoso\user au lieu d'un UPN ; forcez la syntaxe user@contoso.corp.com. Les incohérences d'UPN cassent les assertions SAML, le décalage d'horloge Kerberos supérieur à 5 minutes invalide les tickets (auditez avec w32tm /monitor), les SPN en double empêchent l'émission de tickets (setspn -X les détecte) et les chaînes de certificats brisées tuent PKINIT. Utilisez klist purge puis klist pour inspecter les tickets en cache.
Migration depuis ADFS et correspondance avec NIS2, GDPR, HIPAA, PCI-DSS
Retirer ADFS par phases : recenser les parties de confiance, les classer par protocole (WS-Fed vs SAML ou OIDC), sélectionner le stack cible, faire coexister les deux systèmes, puis basculer. Mettre en correspondance les contrôles avec NIS2 Art. 21, GDPR Art. 32, HIPAA §164.312(a)(2)(i) et PCI-DSS 8.3–8.5.
Foire Aux Questions
Puis-je configurer un SSO on-prem sans ADFS ni licence complète Microsoft Entra ID P1/P2 ?
Oui. Une conception basée uniquement sur Kerberos adossée à Active Directory fournit le SSO pour les postes de travail joints au domaine sans aucune couche cloud. Pour les applications modernes, associez un proxy SAML léger ou un fournisseur d'identité on-prem avec AD comme source d'annuaire. Hideez Server combiné à des clés FIDO2 couvre la connexion Windows, RDP et les ressources héritées sans Entra ID P1/P2.
Quelles clés matérielles FIDO2 prennent en charge le SSO on-prem sans mot de passe avec Active Directory ?
Tout authentificateur certifié FIDO2 fonctionne, y compris Hideez Key, YubiKey et Feitian. Pour l'AD on-prem, la clé doit prendre en charge le flux de vérification utilisateur WebAuthn et être couplée à un serveur qui serve d'intermédiaire pour les tickets Kerberos après attestation.
Comment les appareils joints uniquement à Entra accèdent-ils aux partages de fichiers on-prem et aux applications héritées ?
Via Cloud Kerberos Trust ou un serveur d'authentification on-prem qui émet des TGT après vérification FIDO2, offrant à l'appareil une session Kerberos valide pour les chemins UNC et les applications intégrées à Windows.
Prêt à retirer ADFS et déployer un SSO résistant au phishing dans votre environnement hybride ? Réservez une démonstration technique avec l'équipe Hideez ou explorez le programme partenaire Hideez pour proposer un accès passwordless FIDO2 à vos clients.