Le service proxy Kerberos Key Distribution Center (KDC) agit comme un pont sécurisé, qui permet aux clients distants d’utiliser l’authentification Kerberos lorsqu’ils ne peuvent pas accéder directement aux contrôleurs de domaine Active Directory. Le proxy KDC est utilisé pour les scénarios d’authentification Kerberos impliquant des utilisateurs externes (c’est-à-dire ceux qui se connectent depuis Internet) ou des utilisateurs de groupes de travail. Le service proxy KDC a été initialement conçu pour DirectAccess, Remote Desktop Gateway, Azure Virtual Desktop (AVD) et l’accès aux fichiers SMB via QUIC. Cependant, avec la dépréciation prévue par Microsoft des protocoles d’authentification NTLM v1 et v2, il peut être nécessaire d’utiliser un proxy KDC pour des services d’accès à distance supplémentaires.
Les ports suivants doivent être ouverts pour effectuer l’authentification Kerberos entre le client et le service KDC sur le contrôleur de domaine Active Directory (AD).
-
UDP/TCP 88 – Authentification Kerberos, obtention de Ticket Granting Tickets (TGT)
-
UDP/TCP 464 – modification du mot de passe d’un utilisateur via Kerberos
L’ouverture de ces ports aux contrôleurs de domaine pour les utilisateurs externes n’est pas sécurisée, un service proxy KDC peut donc être créé au point de connexion utilisateur. Le proxy KDC s’exécute sur un serveur joint au domaine, écoute les requêtes Kerberos sur le port HTTPS (TCP/443) provenant de clients externes et les tunnelise en toute sécurité vers le contrôleur de domaine.
Considérez le scénario simple suivant : un serveur de passerelle Bureau à distance est déployé dans le périmètre interne et des utilisateurs externes s’y connectent. Les utilisateurs externes sur des machines n’appartenant pas au domaine ne peuvent pas se connecter en raison de la désactivation de l’authentification NTLM sur l’hôte RD Gateway, qui fonctionne en mode Kerberos uniquement. Cela entraîne une erreur RDP :
An authentication error has occurred.The function requested is not supportedRemote computer: xxxxThis could be due to CredSSP encryption oracle remediation.
Dans cette situation, comme le client ne peut pas s’authentifier sur le contrôleur de domaine via Kerberos, une tentative sera effectuée pour revenir à NTLM, qui est désactivé sur l’hôte. Cela empêchera l’utilisateur de se connecter à distance.
Pour permettre aux clients externes de s’authentifier sur cet hôte RDP via Kerberos, le service proxy KDC (KPSSVC) sera déployé sur l’hôte RDGW.
L’hôte du service proxy KDC doit disposer d’un certificat installé pour chiffrer le trafic et l’authentification du serveur. L’utilisation étendue de la clé (EKU) du certificat doit inclure l’authentification du serveur, l’authentification du client et l’authentification Kerberos. Le nom alternatif du sujet ( SAN ) du certificat doit inclure le nom de domaine complet (FQDN) du proxy KDC que les clients utiliseront pour se connecter. Un tel certificat peut être émis par une autorité de certification interne ou commerciale (pour les déploiements de test et hors production, un certificat auto-signé peut être utilisé).
Le certificat doit être ajouté au magasin de certificats du serveur. Copiez l’empreinte digitale de votre certificat :
Get-ChildItem-Path Cert:\LocalMachine\My | Where-Object { $\_.Subject-like "*CN=rds01.woshub.com*"} | Select-Object-ExpandProperty Empreinte
Si vous utilisez un certificat auto-signé ou celui d’une autorité de certification interne, installez la clé publique du certificat sur les appareils Windows des clients afin qu’ils lui fassent confiance.
Passons maintenant à la configuration du service proxy KDC.
Créez un point de terminaison d’URL de connexion :
NETSH http add urlacl url=https://+:443/KdcProxy user="Autorité NT\Service réseau"
URL reservation successfully added
Générez un GUID unique :
$appguid=Guid::NewGuid().ToString("B")
Définissez la valeur de l’empreinte numérique du certificat :
$kdccert="F00AB752B63F3B840A44BF6A20F6EF0E25DEF4D4"
Liez le certificat au point de terminaison de connexion :
netsh http add sslcert ipport=0.0.0.0:443 certhash=$kdccert appid=$appguid
SSL Certificate successfully added
Comme je n’ai pas l’intention d’utiliser l’authentification par carte à puce ou Windows Hello, je désactiverai les exigences d’authentification du certificat client HTTPS pour les opérations du proxy KDC. Cela permettra d’utiliser des méthodes alternatives, telles que les mots de passe ou Kerberos sur HTTPS, sans carte à puce.
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings"/v HttpsClientAuth/t REG\_DWORD/d 0x0/f
Activer l’authentification par mot de passe :
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings"/v DisallowUnprotectedPasswordAuth/t REG\_DWORD/d 0x0/f
Activez le service proxy KDC (KPSSVC) :
Set-Service kpssvc-StartupType Automatique
Service de démarrage kpssvc
Autorisez le trafic entrant sur le port TCP 443 sur le serveur afin que les clients puissent se connecter au proxy KDC. Créez une règle d’autorisation du pare-feu Windows à l’aide de PowerShell :
New-NetFirewallRule-DisplayName "KDCProxy TCP\_In"-Direction Inbound-Protocol TCP-LocalPort 443
Maintenant, apportons quelques modifications côté client afin qu’ils utilisent le proxy KDC pour les connexions.
Les paramètres de proxy KDC sur les clients peuvent être configurés via l’option de stratégie de groupe Spécifier les serveurs proxy KDC pour les clients Kerberos dans la section Configuration ordinateur-> Stratégies-> Modèles d’administration-> Système-> Kerberos.
Activez la stratégie, cliquez sur le bouton Afficher et ajoutez une chaîne de connexion pour votre proxy KDC. La chaîne doit être au format suivant :
-
Nom de la valeur : votre nom de domaine AD,
woshub.com -
Valeur : chaîne de connexion proxy KDC pour ce domaine (plusieurs serveurs peuvent être spécifiés) :
Ou vous pouvez configurer les paramètres du proxy KDC directement sur le client via le registre.
` reg ajoute “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos”/v KdcProxyServer_Enabled/t REG_DWORD/d 1/f
reg ajoute “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers”/v woshub.com/t REG_SZ/d “"/f `
Afin d’appliquer les paramètres GPO, l’ordinateur client doit être redémarré.
Maintenant, essayez de vous connecter à la passerelle RDP à partir du client. Le client doit utiliser le proxy KDC pour s’authentifier auprès du contrôleur de domaine et obtenir un ticket Kerberos. Pour vérifier qu’un ticket Kerberos a été émis via kdcproxy , exécutez la commande ci-dessous :
klist récupère krbtgt
Les journaux d’authentification du proxy Kerberos se trouvent dans la section suivante de l’Observateur d’événements : Observateur d’événements-> Applications et services-> Microsoft-> KDCProxy-> Opérationnel.
Dans les prochaines versions de Windows, Microsoft prévoit d’automatiser et de simplifier le déploiement du proxy KDC via l’interface Web Windows Admin Center (WAC).
*️⃣ Lien source :
Passerelle Bureau à distance, accès aux fichiers SMB via QUIC, dépréciation des protocoles d’authentification NTLM v1 et v2, modification du mot de passe d’un utilisateur, authentification NTLM désactivée, une erreur d’authentification s’est produite, certificat auto-signé, installer la clé publique du certificat sur les appareils Windows des clients, le pare-feu Windows autorise la règle utilisant PowerShell, appliquer les paramètres GPO,