Activer l'authentification intégrée de Windows sur un domaine Active Directory

Ce guide est fourni pour configurer l'authentification intégrée Windows (Kerberos/NTLM) avec un compte de service géré par groupe (gMSA) sur le portail Web.

En raison de la nature unique du réseau et de l'architecture de chaque entreprise, nous ne pouvons pas fournir de support pour les problèmes découlant du suivi de cette documentation. Cela répond aux exigences techniques pour le portail Web avec authentification intégrée Windows, mais la mise en œuvre est de votre propre responsabilité.

Configuration de domaine

L'environnement Active Directory doit prendre en charge l'authentification Kerberos ou NTLM.

Configurer un compte de service géré (gMSA)

Installez le service Web Portal et exécutez-le avec un compte de service géré de domaine au lieu d'un compte administrateur de domaine.

Prérequis

Niveau de schéma Active Directory : Windows Server 2012 ou plus tard (nécessaire pour gMSA)
Au moins un contrôleur de domaine en cours d'exécution Windows Server 2012 ou plus tard
Clé racine KDS créée (configuration unique)
Adhésion à Administrateurs de domaine ou Opérateurs de compte pour créer le compte

Créer la clé racine KDS (si elle n'est pas déjà créée)

Exécutez sur un contrôleur de domaine dans une session PowerShell élevée :

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Cela rend la clé racine immédiatement disponible.

Créer le gMSA

Utiliser New-ADServiceAccount :

New-ADServiceAccount `
  -Name "WebPortalSvc" `
  -DNSHostName "WebPortalSvc.domain.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "YourServerGroup" `
  -Enabled $true

Nom nom de compte gMSA
Nom d'hôte DNS FQDN pour le compte
Principaux autorisés à récupérer le mot de passe géré ordinateurs/groupe autorisé à utiliser ce gMSA

Accorder des droits administratifs (optionnel / selon les besoins)

Par défaut, un gMSA n'a aucun privilège spécial.

Pour accorder un accès au niveau du domaine (optionnel) :

Add-ADGroupMember -Identity "Domain Admins" -Members "WebPortalSvc$"

Pour accorder des droits d'administrateur local/capacité de connexion (si nécessaire) :

Add-ADGroupMember -Identity "Administrateurs" -Members "WebPortalSvc$"

Important : le traînant $ est requis pour les références de compte gMSA dans AD.

Exigence de redémarrage

Un redémarrage est nécessaire avant de continuer et d'installer/utiliser le compte de service. Veuillez également actualiser les politiques.

Installer le gMSA sur les serveurs cibles

Exécutez sur chaque serveur qui utilisera le gMSA :

Install-ADServiceAccount -Identity "WebPortalSvc"

Installation de test :

Test-ADServiceAccount -Identity "WebPortalSvc"

Configurer les services pour utiliser le gMSA

Accorder Se connecter en tant que service au compte :
- Ouvrir l'éditeur de stratégie de groupe
- Allez à : Configuration de l'ordinateur > Paramètres Windows > Paramètres de sécurité > Politiques locales > Attribution des droits d'utilisateur
- Ouvrir Se connecter en tant que service
- Ajouter DOMAIN\WebPortalSvc$
Assurez-vous des autorisations NTFS sur les fichiers/dossiers du portail Web :
- Clic droit sur le dossier/application exécutable > Propriétés > Sécurité
- Ajouter DOMAIN\WebPortalSvc$
- Accorder au moins Lire et exécuter ou Contrôle total si nécessaire pour votre déploiement
Configurer l'identité du service :
- Compte : DOMAIN\WebPortalSvc$
- Mot de passe : laisser vide

Configurer le nom principal de service (SPN)

Le service web doit être enregistré dans Kerberos.

Exécuter sur un contrôleur de domaine :

setspn -A HTTP/webserver.domain.com DOMAIN\WebPortalSvc

Remplacez par votre FQDN de serveur et votre compte.

Si le serveur d'hébergement du portail Web utilise HTTP.sys, enregistrez SPN contre le compte machine :

setspn -S HTTP/portal.hiyoko.com:8008 WIN-HLBO0AGABB7
setspn -S HTTP/portal.hiyoko.com:8009 WIN-HLBO0AGABB7

Configurer le réseau sur la machine cliente

Pour placer un client joint au domaine dans le sous-réseau correct :

Identifier l'interface réseau correcte
Supprimer l'IP statique existante (si incorrecte)
Attribuer une adresse IP statique, un masque de sous-réseau et une passerelle par défaut correspondant au sous-réseau DNS/DC
Définir les adresses du serveur DNS

Important : attribuez des adresses IP statiques au contrôleur de domaine et aux clients. La synchronisation de la politique de sécurité nécessite que les machines soient dans le même sous-réseau dans ce contexte.

Autoriser la connectivité client requise

UDP/TCP 53 peut être bloqué, ce qui empêche les requêtes DNS.

Étapes de dépannage

Vérifier l'état du serveur DNS

Sur le contrôleur de domaine :

net start DNS

Vérifiez que le service DNS est en cours d'exécution.

Vérifier l'IP du serveur DNS

Sur le client :

ipconfig /all

Confirmez que l'adresse IP du serveur DNS correspond à l'adresse IP du contrôleur de domaine.

Tester la connectivité de base

Sur le client :

ping <DC_IP_Address>

Si le ping échoue, dépannez le routage réseau/firewall.

Vérifiez les règles du pare-feu

Assurez-vous que le UDP/TCP 53 entrant/sortant est autorisé sur le client et le serveur.

Test avec nslookup

nslookup domain.com <DC_IP_Address>

Si cela fonctionne, le serveur DNS par défaut peut être mal configuré ou inaccessible.

Vérifier le Visualiseur d'événements

Sur le contrôleur de domaine, vérifiez les erreurs liées au DNS.

Configurer Mozilla Firefox pour l'authentification intégrée de Windows

Firefox n'utilise pas WIA par défaut.

Étape 1 : négocier des URI de confiance

Ouvrir Firefox
Aller à à propos:config
Accepter l'avertissement
Définir network.negotiate-auth.trusted-uris à vos domaines, par exemple :
- intranet.domaine.com, domaine.com

Étape 2 : URIs NTLM de confiance

Définir network.automatic-ntlm-auth.uris-de-confiance à la même liste de domaines.

Étape 3 : URIs de délégation Kerberos (si nécessaire)

Définir network.negotiate-auth.delegation-uris D'accord, je suis prêt à traduire le texte que vous fournirez. Veuillez me donner le texte à traduire.

domain.com

Étape 4 : redémarrer le navigateur

Redémarrez Firefox pour appliquer les modifications.

Configurer Google Chrome pour l'authentification intégrée de Windows

Chrome utilise les paramètres d'authentification Windows/system.

Via la stratégie de groupe (recommandé)

Télécharger les modèles ADMX de Chrome :
- https://chromeenterprise.google/policies/
Copier chrome.admx et chrome.adml à :
- C:\Windows\PolicyDefinitions
- C:\Windows\PolicyDefinitions\fr-FR
Ouvrir gpedit.msc
Allez à :
- Configuration de l'ordinateur > Modèles d'administration > Google > Google Chrome
Activer l'authentification intégrée pour les sites intranet et configurer les sites de confiance :
- intranet.domaine.com, domaine.com
Appliquer la politique :

gpupdate /force

Autres méthodes

D'autres méthodes (commutateurs et drapeaux de ligne de commande Chrome) n'ont pas réussi dans ce contexte.

Configurer Microsoft Edge pour l'authentification intégrée de Windows

Edge utilise les politiques de Microsoft Edge et les paramètres de zone de sécurité de Windows.

Activer la connexion automatique dans la zone intranet

Ouvrir les options Internet
Sécurité onglet > Intranet local > Niveau personnalisé
Sous Authentification de l'utilisateur , ensemble :
- Connexion automatique uniquement dans la zone Intranet

Configurer les politiques Edge via GPO

Étape 1 : installer les modèles ADMX Edge

Télécharger :
- https://www.microsoft.com/fr-fr/edge/business/download
Copier msedge.admx et msedge.adml à :
- C:\Windows\PolicyDefinitions
- C:\Windows\PolicyDefinitions\fr-FR

Étape 2 : modifier les paramètres de la politique

Ouvrir gpedit.msc
Allez à :
- Configuration de l'ordinateur > Modèles d'administration > Microsoft Edge
Activer :
- Configurer la liste des serveurs auxquels Microsoft Edge peut déléguer des identifiants.
Configurer les serveurs de confiance :
- intranet.domaine.com, domaine.com

Étape 3 : appliquer les politiques

gpupdate /force

Autres méthodes

D'autres méthodes (commutateurs et indicateurs de ligne de commande Edge) n'ont pas réussi dans ce contexte.

Dépannage de l'authentification intégrée

Vérifier les tickets Kerberos

Sur le client Windows :

klist

Vous devriez voir un ticket pour HTTP/webserver.domain.com .

Effacer les identifiants/tickets mis en cache

klist purge

Vérifier l'enregistrement SPN

Sur le contrôleur de domaine :

setspn -L serviceaccount

Assurez-vous HTTP/webserver.domain.com est répertorié.

Déboguer Kerberos dans Firefox

Démarrer Firefox avec journalisation :

set NSPR_LOG_MODULES=negotiateauth:5
set NSPR_LOG_FILE=%USERPROFILE%\Desktop\firefox.log
start firefox.exe

Examen firefox.log pour les erreurs d'authentification.

Vérifiez les politiques de Chrome

Dans Chrome, ouvrez :

chrome://policy

Assurez-vous AuthServerWhitelist et AuthNegotiateDelegateWhitelist sont appliquées.

Vérifier les politiques Edge

Dans Edge, ouvrez :

edge://policy

Assurez-vous AuthServerWhitelist et AuthNegotiateDelegateWhitelist sont appliquées.