Copyright © 2013, Oracle et/ou ses affiliés. Tous droits réservés. Legal Notices
Afin de sécuriser toutes les données transférées depuis et vers le serveur Windows, le connecteur Windows prend en charge la sécurité réseau RDP intégrée et des options de sécurité réseau améliorées. La sécurité RDP intégrée utilise le chiffrement RC4, qui permet de chiffrer des données de tailles variées à l'aide d'une clé de 56 ou 128 bits. Les options de sécurité réseau améliorées comprennent TLS/SSL (avec vérification du serveur facultative) et l'authentification au niveau du réseau (NLA) à l'aide de CredSSP.
Le connecteur Windows fait appel au chiffrement RC4 de RSA Security de façon à sécuriser toutes les données transférées depuis et vers le système Windows. Ce chiffrement chiffre des données de taille variable avec une clé 56 bits ou 128 bits.
Tableau 17.8, « Niveaux de chiffrement pour la sécurité du réseau » énumère les quatre niveaux de chiffrement qui peuvent être configurés dans le système Windows.
Tableau 17.8. Niveaux de chiffrement pour la sécurité du réseau
Niveau | Description |
|---|---|
Faible | Toutes les données du client envoyées au serveur sont chiffrées selon le niveau de clé maximum pris en charge par le client. |
Compatible client | Toutes les données échangées entre le client et le serveur sont chiffrées selon le niveau de clé maximum pris en charge par le client. |
Elevé | Toutes les données échangées entre le client et le serveur sont chiffrées selon le niveau de clé maximum pris en charge par le serveur. Les clients ne prenant pas en charge ce niveau de chiffrement ne peuvent pas se connecter. |
Compatible FIPS | Le chiffrement compatible FIPS n'est pas pris en charge. |
Le chiffrement des données est bidirectionnel, sauf pour le paramètre Faible, qui chiffre uniquement les données envoyées par le client au serveur.
Les options de sécurité réseau améliorées comprennent TLS/SSL (avec vérification du serveur facultative) et l'authentification au niveau du réseau (NLA) à l'aide de CredSSP. Ces options protègent la session Windows des utilisateurs et des logiciels malveillants avant l'établissement d'une connexion de session complète.
Tableau 17.9, « Exemples de ligne de commande améliorant la sécurité du réseau » fournit une liste d'exemples de commande uttsc qui illustrent le mécanisme de sécurité utilisé lorsque le service Windows Remote Desktop est configuré pour négocier avec le client. Le résultat "RDP" signifie que la sécurité RDP intégrée est utilisée.
Tableau 17.9. Exemples de ligne de commande améliorant la sécurité du réseau
Exemples de ligne de commande uttsc | Windows XP | Windows Server 2003 R2 | Windows 7, Windows Server 2008 R2 | Windows 8, Windows Server 2012 |
|---|---|---|---|---|
| Protocole RDP | SSL/TLS | Authentification au niveau du réseau | Authentification au niveau du réseau |
| Protocole RDP | SSL/TLS | SSL/TLS | SSL/TLS |
| Protocole RDP | SSL/TLS | Authentification au niveau du réseau | Authentification au niveau du réseau |
| Protocole RDP | Protocole RDP | Protocole RDP | Protocole RDP |
Utilisez les notes suivantes pour configurer la sécurité TLS/SSL :
L'hôte RDP doit être en cours d'exécution Windows Server 2003 R2, Windows 7, Windows Server 2008 R2, Windows 8 ou Windows Server 2012.
Il faut configurer la couche de sécurité du système Windows doit être configuré en tant que "SSL (TLS 1.0)" ou "Négocier".
Pour vous connecter à un hôte Windows avec la vérification TLS/SSL activée (-j VerifyPeer:on), vous devez ajouter le certificat d'origine dans le magasin de certificats OpenSSL du client ou spécifier un autre chemin de recherche/fichier PEM à l'aide des options -j CAPath: ou path-j CAfile n: de la commande uttsc. fichier-pem
Les connexions TLS/SSL nécessitent la présence d'un certificat sur le système Windows. Dans le cas contraire, la connexion peut revenir à la sécurité RDP intégrée (si cette opération est autorisée) ou échouer.
Utilisez les notes suivantes pour configurer la sécurité NLA :
L'hôte RDP doit être en cours d'exécution Windows 7, Windows Server 2008 R2, Windows 8 ou Windows Server 2012.
Il faut configurer la couche de sécurité du système Windows doit être configuré en tant que "SSL (TLS 1.0)" ou "Négocier".
Vous pouvez appliquer la sécurité par authentification au niveau du réseau (NLA) sur un système Windows. Par exemple, sur Windows Server 2008 R2, sélectionnez l'option suivante dans l'onglet Utilisation à distance de la fenêtre Propriétés du système : "N'autoriser que la connexion des ordinateurs exécutant Bureau à distance avec Authentification au niveau du réseau (plus sûr)". Si cette option est sélectionnée, les utilisateurs doivent indiquer les options -u et -p avec la commande uttsc pour se connecter au serveur.
Par défaut, l'authentification Kerberos est utilisée pour la sécurité NLA. Si le connecteur Windows ne peut pas obtenir un ticket Kerberos pour le service de bureau distant, il utilisera l'authentification NT LAN Manager (ntlm). Vous pouvez spécifier l'option -N kerberos de la commande uttsc pour l'obliger à n'utiliser que l'authentification Kerberos ou l'option -N ntlm pour l'obliger à n'utiliser uniquement que l'authentification NTLM.
Lors de l'authentification Kerberos, le nom d'utilisateur spécifié doit être un nom principal kerberos valide. Utilisez la commande kinit pour vérifier si un nom principal est valide.
Lors de l'authentification Kerberos, Kerberos doit être configuré sur le serveur Sun Ray, comme décrit dans Section 17.9.2.3, « Configuration de l'authentification Kerberos pour la sécurité NLA ».
Si vous souhaitez utiliser l'authentification Kerberos pour la sécurité NLA, Kerberos doit être correctement configuré dans le serveur Sun Ray. Reportez-vous aux informations suivantes concernant la configuration de l'authentification kerberos :
Page de manuel krb5.conf(4) : http://docs.oracle.com/docs/cd/E19253-01/816-5174/6mbb98ufn/index.html
Service Kerberos sous Oracle Solaris : http://docs.oracle.com/docs/cd/E19253-01/816-4557/seamtm-1/index.html
Kerberos sous Oracle Linux : http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/ch-kerberos.html
Une fois configuré, vous pouvez vérifier que Kerberos et la résolution de noms requise sont correctement configurés à l'aide des commandes getent, nslookup et kinit.
Exemple :
# getent hosts my.windows.host doit renvoyer l'adresse IP et le nom d'hôte
# getent hosts IP_of_my.windows.host doit renvoyer l'adresse IP et le nom d'hôte
# nslookup -query=any _gc._tcp.domain_name doit résoudre le domaine
# kinit -V super-user@domain_name doit réussir
Copyright © 2013, Oracle et/ou ses affiliés. Tous droits réservés. Legal Notices