Windows Server 2008 R2 : Pourquoi utiliser l'authentification au niveau du réseau ?
À l'aide de l'authentification au niveau réseau (NLA), au lieu de la méthode de terminal services plus âgée, est plus rapide et plus sécuritaire.
Kristin Griffin
Passer de Services Terminal Server de Windows Server 2003 à Windows Server 2008 R2 Remote Desktop Services est devenu un chemin de mise à niveau assez commun. Comme les gens font de cette mise à niveau, vous souvent entendrez leur demandais pourquoi l'expérience de l'utilisateur de connexion entre les deux versions est tellement différent.
Lors de la connexion à un serveur Terminal de 2003, un utilisateur démarre une session et types dans leurs titres de compétences. Lorsque vous utilisez un serveur hôte de la Session RD, un utilisateur entre généralement les informations d'identification dans une boîte de dialogue côté client. Par défaut, les clients qui ne supportent pas une technologie appelée authentification au niveau de réseau (NLA) ne peut pas se connecter. Pourquoi la différence ? Il y a des raisons pourquoi Microsoft a introduit l'authentification au niveau du réseau et les raisons pour lesquelles il est en effet une bonne chose.
Qu'est-UÇK ?
NLA forces le présentes informations d'identification pour l'authentification de l'ordinateur client avant que le serveur va créer une session pour cet utilisateur. En raison de ce processus, elle est parfois appelée « l'authentification à l'avant. » Les serveurs qui exécutent Windows Server 2008/Vista ou plus tard, et les clients exécutant Windows XP SP3 ou appuyer plus tard, NLA. Parce que l'UÇK s'appuie sur une technologie appelée Protocole Credential Security Support Provider (CredSSP), si vous utilisez un client Remote Desktop Protocol (RDP) pour un autre système d'exploitation, vous aurez besoin de demander son développeur si elle prend en charge la NLA.
Alors pourquoi est présentant des informations d'identification avant la création de session telle une bonne chose ? Il y a deux principaux avantages à ne pas créer une session jusqu'à ce que vous ne savez pas la personne tentant de se connecter est autorisée à le faire : Il offre une couche de défense contre les attaques par déni de Service (DoS), et il accélère le processus de courtage.
Démarrage d'une session — même seulement présenter un écran d'ouverture de session — exige que le serveur de créer beaucoup des processus nécessaires pour appuyer une session, tels que Csrss.exe et Winlogon.exe. De ce fait, la création de session est dispendieux et chronophage relativement. Si un certain nombre d'utilisateurs non autorisés a tenté de se connecter à une session en même temps, ils pouvaient potentiellement d'autres bloquer d'utiliser ce serveur parce qu'il a créé des séances d'accepter ces informations d'identification de connexion faux.
Le problème de performances est plus critique. Dans Windows Server 2003, les fermes étaient relativement rares. À partir de Windows Server 2008, les fermes sont devenues plus courantes. N'oubliez pas que chaque serveur dans une ferme de l'hôte de la Session RD est potentiellement un redirecteur. Si le serveur hôte doit créer une session complète avant de redirection d'une demande de connexion au courtier connexion RD, cela ralentit le temps de connexion.
NLA utilise CredSSP pour présenter les informations d'identification de l'utilisateur sur le serveur d'authentification avant de créer une session. Ce processus permet d'éviter tous les deux de ces questions. À l'aide de CredSSP offre d'autres avantages aussi bien. CredSSP peut réduire le nombre d'ouvertures de session qu'utilisateur doit faire en stockant les informations d'identification pour une connexion particulière.
La première fois qu'un utilisateur se connecte à un serveur, machine virtuelle (VM) ou même un autre PC, ils devrez fournir leurs informations d'identification. Cependant, ils vous ont également l'option de les sauver. S'ils le font, ils n'aurez pas besoin de fournir des informations d'identification à nouveau pour cette connexion jusqu'à ce qu'ils changent leur mot de passe.
Comment CredSSP appuie NLA
Le protocole CredSSP aide les applications solidement déléguer des informations d'identification d'un client à un serveur cible. Premièrement, ce protocole établit un canal chiffré entre le client et le serveur cible à l'aide de Transport Layer Security (TLS) (tel que spécifié dans [RFC2246]).
Lorsque vous vous connectez à un serveur hôte de la Session RD avec un RDC 6.x ou le client plus tard, vous avez peut-être remarqué que vous ne vous connectiez directement à l'écran de connexion du serveur hôte de la Session RD de fournir vos informations d'identification. Au lieu de cela, une boîte de dialogue locale surgit de prendre vos informations d'identification sur le client. Cette boîte de dialogue est l'extrémité avant de CredSSP.
Lorsque vous tapez vos informations d'identification dans cette boîte de dialogue, même si vous ne choisissez pas de les sauver, ils vont à CredSSP. Cette époque passe les informations d'identification pour le serveur hôte de la Session RD via un canal sécurisé. Le serveur hôte de la Session RD commencera uniquement à construire une session d'utilisateur une fois qu'il accepte ces informations d'identification.
Les clients qui CredSSP et RDP 6.x et plus tard seront toujours utiliser UÇK si elle est disponible. Parce que la CredSSP (la technologie qui appuie l'UÇK) est la partie du système d'exploitation et non pas de RDP, le client OS doit prendre en charge CredSSP pour l'UÇK au travail.
Par conséquent, bien qu'il y a un client RDC 6.0 pour Windows XP SP2, cela ne laisse Windows XP SP2 utilisent l'UÇK. Les clients exécutant Windows XP SP3, Windows Vista et Windows 7 tous en charge CredSSP. Aussi, RDC vous dira si elle prend en charge NLA dans l'écran de propos. Pour cela, cliquez sur l'icône dans le coin supérieur gauche de la RDC et choisissez sur. Cela vous indiquera si elle prend en charge la NLA.
Windows XP SP3 soutient CredSSP, mais ne le fait pas activé par défaut. Pour l'activer, Microsoft a publié un article de la base de connaissances avec une Fix It for Me link. L'article explique également comment activer CredSSP manuellement. Une fois que vous activez CredSSP, redémarrez l'ordinateur.
Si votre ordinateur client n'est pas configuré pour correctement en charge NLA, vous obtiendrez un message disant de sorte que lorsque vous essayez d'une connexion à distance à une machine qui nécessite NLA. Par exemple, si votre client Windows XP SP3 n'a pas permis de CredSSP, vous obtiendrez cette erreur lorsque vous essayez d'une connexion à distance à un serveur hôte de la Session RD requis NLA : « L'ordinateur distant exige authentification au niveau réseau, qui ne supporte pas de votre ordinateur ».
Comment forcer l'utilisation de l'UÇK
Serveurs de l'hôte de la Session RD ne requièrent pas NLA par défaut. Vous pouvez configurer leur afin de permettre les connexions uniquement des ordinateurs prenant en charge l'UÇK, soit par le biais de stratégie de groupe ou sur une base par serveur de Configuration d'hôte RD Session.
Pour exiger l'UÇK pour se connecter au serveur hôte de la Session RD sur une base par serveur, ouvrez RD Session Host Configuration. Double-cliquez sur RDP-Tcp (en vertu de la section de connexions) et sous l'onglet général, sélectionnez la case à cocher à côté de permettre les connexions uniquement d'ordinateurs exécutant Remote Desktop avec l'authentification de niveau réseau. Cela empêchera toute les clients qui ne supportent pas NLA (à savoir, si le client RDC en cours d'exécution antérieure à la version 6.x et tout OS ne pas soutenir CredSSP) de se connecter au serveur.
Pour activer l'UÇK via la stratégie de groupe, activer la politique suivante et l'appliquer au serveur hôte de la Session RD OU : Configuration de l'ordinateur | Politiques | Modèles d'administration | Composants Windows | Les Services de bureau distants | Hôte de la Session bureau distant | Sécurité | Une authentification de l'utilisateur pour les connexions à distance en utilisant l'authentification de niveau réseau.
La désactivation ou la configuration ne pas cette politique signifie NLA n'est pas obligatoire.
Demandes VDI
Pour les déploiements virtual desktop infrastructure (VDI), vous pouvez également restreindre Windows Vista et Windows 7 à accepter les demandes de connexion uniquement à partir de clients qui prennent en charge UÇK. Aller au panneau de contrôle | Système | Paramètres distants. Distant sous l'onglet de la boîte de dialogue Propriétés système, sélectionnez l'option pour permettre à connexions uniquement d'ordinateurs exécutant Remote Desktop avec réseau authentification au niveau (plus sécurisé).
Cela devrait expliquer pourquoi l'UÇK habilitante sur vos serveurs hôte de la Session RD et VDI VMs sont une bonne idée. Vous devez comprendre comment exiger NLA sur vos serveurs et VDI VMs et comment configurer vos ordinateurs clients pour soutenir l'UÇK.
Certificats, alors qu'il est ne mentionné que brièvement, sont un élément essentiel de tout déploiement de RDS. Et ce n'est pas juste pour l'UÇK, mais aussi de serveur d'authentification, à l'aide de la RD Gateway, RD Web Access et même agent de connexion RD. La prochaine fois je vais fouiller plus des exigences de certificat pour les déploiements de RDS.
.jpg)
Kristin Griffinest un MVP de Services Remote Desktop. Elle modère un forum de Microsoft dédié à aider la communauté informatique sur serveur (Remote Desktop Services) et tient à jour un blog RDS à blog.kristinlgriffin.com. Elle est un contributeur de "Mastering Windows Server 2008" de Mark Minasi (Sybex, 2008) et « Mastering Windows Server 2008 R2 » (Sybex, 2010). Elle a également coauteur de "Microsoft Windows Server 2008 Terminal Services Resource Kit" (Microsoft Press, 2008) et "Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit" (Microsoft Press, 2010) avec Christa Anderson.
NLA q et r
Q. J'exécute Windows XP SP3. J'ai activé CredSSP, mais j'obtiens toujours l'erreur suivante lors de la connexion à un serveur hôte de la Session RD qui nécessite NLA : « L'authentification a commis une erreur. »
R : Il existe un correctif qui résout ce problème sur mon blog.
Cette erreur se produit également dans le cadre de cette circonstance spécifique avec ces facteurs présents :
- Le client s'exécute Windows XP SP3 avec CredSSP activé.
- Vous avez configuré le serveur à utiliser un certificat SSL réel pour s'identifier (il n'utilise pas le certificat généré automatiquement, ce qui est en place, par défaut).
- Le client n'est pas confiance le certificat utilisé pour signer le certificat SSL utilisé sur le serveur.
Parce que l'UÇK exige un canal sécurisé sur lesquels il reçoit des informations d'identification, et il ne peut pas créer ce tunnel si elle n'est pas confiance le certificat, NLA fonctionnera. Pour résoudre ce problème, assurez-vous que la machine client XP a le certificat utilisé pour signer RD hôte de la Session du certificat du serveur SSL installé dans son certificat d'autorités de Certification racine de confiance ordinateur stocker le dossier.
Remarque Cette erreur spécifique peut varier légèrement de la RDC 6.x RDC 7.0. Si vous installez RDC 7.0, vous pourriez voir ce message d'erreur : « La connexion a été terminée parce qu'un certificat d'authentification de serveur inattendu a été reçu de l'ordinateur distant. »