Virtualisation de sessions

Terminal Server 2008: L’authentification du serveur

Par Laurent Falguière ⋅ 28 octobre 2008 ⋅  Envoyer cet article ⋅  Imprimer cet article ⋅

Evaluer cet article:

 Chargement ...

Nous avons vu précédemment comment mettre en oeuvre l’ authentification au niveau réseau. Pour renforcer encore la sécurité, il est possible de vérifier, avant d’initier la connexion, que le serveur cible est bien celui attendu. Ceci évite de fournir éventuellement des informations de connexions à un serveur tiers…

En fait, l’authentification du serveur existe depuis Windows Server 2003 SP1 et le client RDP 5.2 et permet au client d’authentifier le server en se basant sur un certificat de serveur SSL/TLS.

Dans Windows 2008, on peut aller plus loin puisque l’authentification au niveau réseau (NLA) s’appuie sur CredSSP (fournisseur de services de sécurité des informations d’identification, également utilisé pour le SSO). Afin de garantir l’identité du serveur cible à qui il va fournir des informations sensibles, CredSSP peut authentifier la machine distante en utilisant  SSL/TLS, Kerberos ou en dernier recours NTLM…

L’authentification du serveur (NLA) avec NTLM

L’authentification NTLM est utilisée par CredSSP pour authentifier le serveur cible lorsque l’authentification Kerberos ou TLS/SSL ne sont pas disponibles. En réalité, on ne peut pas parler d’authentification, puisque l’authentification du serveur basée sur NTLM ne valide pas l’identité du serveur cible, mais permet seulement de valider l’appartenance de la machine cible au même domaine que celui fourni par l’utilisateur dans la fenêtre d’authentification du client Connexion bureau à distance. Afin d’accroître la sécurité, l’authentification NTLM devrait être désactivée, et une authentification du serveur cible basée sur Kerberos ou TLS/SSL devrait être utilisée.

Pour ce faire on peut utiliser les stratégies de groupe ou le registre du poste client.

Stratégies de groupe:

Dans Configuration Ordinateur / Stratégies / Modèles d’administration / Système  / Délégation d’informations d’identification, désactiver:

• Autoriser les informations d’identification par défaut avec l’authentification de serveur NTLM uniquement
• Autoriser les nouvelles informations d’identification avec l’authentification de serveur NTLM uniquement
• Autoriser les informations d’identification enregistréec avec l’authentification de serveur NTLM uniquement

Registre:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation
"AllowDefCredentialsWhenNTLMOnly"=dword:00000000
"AllowFreshCredentialsWhenNTLMOnly"=dword:00000000
"AllowSavedCredentialsWhenNTLMOnly""=dword:00000000

Une fois désactivée, et si aucune autre méthode d’authentification du serveur n’est disponible, vous recevrez le message suivant:

L’authentification du serveur (NLA) avec Kerberos

L’authentification Kerberos permet de garantir l’identité du serveur Cible en se basant sur l’infrastructure de distribution de clés intégrée nativement à Active Directory. Aucun paramétrage supplémentaire n’est nécessaire.

L’authentification NLA basé sur Kerberos fonctionne dans les cas suivants:

• Le serveur dispose de Windows 2008 et se trouve dans un domaine et non un groupe de travail
• Le serveur Windows 2008 et le client (Windows XP SP3, Vista ou Windows 2008) se trouvent dans le même domaine.
• Le client a accès au centre de distribution de clés Kerberos.

Cette méthode a ses limites, puisqu’ elle ne fonctionne pas depuis les machines non membres du domaine, lors des connexions depuis internet ( TSGateway et dans tous les cas où le centre de distribution de Clés Kerberos n’est pas accessible par le client), lorsque l’équilibrage de charge est utilisé et avec tout autre client que ceux supportant CredSSP (les Systèmes d’exploitation autres que Windows Server 2008, Windows  XP SP3 ou WIndows Vista).

L’authentification du serveur (NLA) avec SSL/TLS

Pour tous les scénarios où Kerberos n’est pas utilisable, il est possible d’utiliser un certificat TLS/SSL sur chacun des serveurs Terminal Server pour garantir l’identité de celui-ci auprès des machines clientes. Le certificat sera émis par une autorité de certification reconnu par le client et correspondra, en règle générale, au FQDN du serveur Terminal Server. L’article suivant du technet détaille l’obtention du certificat: http://technet.microsoft.com/fr-fr/library/cc740173.aspx

Le paramétrage du certificat  s’effectue depuis la console Configuration des services Terminal Server, dans RDP-Tcp (Onglet Général). Cliquer sur Choisir et sélectionner le certificat à utiliser.

Coté Client

L’authentification du serveur est activée par défaut. Il est possible de changer ce paramètre coté client dans les propriétés du client Connexion Bureau à Distance, menu Options, onglet Connexion…

Cette option est, bien évidemment, paramétrable par stratégie de groupe: Dans Configuration Ordinateur / Stratégies / Modèles d’administration / Composants Windows  / Services Terminal Server / Client Connexion Bureau à distance, en activant “Configurer l’authentification du serveur pour le client”…

Les trois options possibles sont les suivantes:

• Etablir la connexion et ne pas m’avertir

Même si l’authentification du serveur échoue, la connexion au serveur est établie…

• M’avertir si l’authentification échoue

Si l’authentification du serveur échoue, un message d’avertissement est affichée pour valider la poursuite de la connexion:

• Ne pas établir la connexion

Si l’authentification du serveur échoue, un message d’erreur explicite est affichée:

Un exemple lors de la connexion à un serveur Windows 2003:

Quelques cas de figure et messages correspondants:

Dans cette  exemple, la connexion s’effectue depuis un client RDP 6.x vers un serveur Windows 2008 dans le même domaine, mais l’authentification Kerberos n’est pas disponible. Une tentative d’authentification du serveur en utilisant TLS/SSL a lieu, mais le serveur distant ne présente pas un certificat valide:

Un dernier exemple: la connexion s’effectue vers un serveur Windows 2003 dans le même domaine. La seule méthode d’authentification possible est donc TLS/SSL (la seule supportée par 2003)… L’authentification échoue car le serveur ne présente pas un certificat valide…

http://www.ditii.com/2008/02/21/windows-server-2008-frontside-authentication-and-sso/

http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-CSSP%5D.pdf

http://blogs.msdn.com/ts/archive/2008/07/21/configuring-terminal-servers-for-server-authentication-to-prevent-man-in-the-middle-attacks.aspx

http://blogs.technet.com/askperf/archive/2008/02/16/ws2008-network-level-authentication-and-encryption.aspx

http://technet.microsoft.com/en-us/library/cc754832.aspx

http://blogs.msdn.com/ts/archive/2008/04/30/problems-using-default-credentials-with-vista-rdp-clients-with-single-sign-on-enabled.aspx

http://msdn.microsoft.com/en-us/magazine/bb985042.aspx

Articles relatifs

• Les utilisateurs chargent des profils temporaires… (0)
• Automatiser l’installation des services Remote Desktop (Terminal Services) (0)
• Configuration de Remote Desktop Services / Terminal Server (0)
• Installer Remote Desktop Services (Windows 2008 R2) (0)
• Correctifs Windows 2008 pour les services Terminal Server (0)