Windows Server 2008 R2: Почему нужно пользоваться проверкой подлинности на уровне сети

Переход от служб терминалов Windows Server 2003 к службам удаленных рабочих столов в Windows Server 2008 R2 стал стандартной процедурой обновления. После обновления многие интересуются, почему работа с этими версиями так отличается.

При подключении к службам терминалов Windows 2003 пользователь инициирует создание сеанса и вводит свои учетные данные. А при использовании сервера узла сеансов удаленных рабочих столов пользователь обычно вводит учетные данные в диалоговом окне на стороне клиента. По умолчанию клиентам, которые не поддерживают технологию проверки подлинности на уровне сети (Network-Level Authentication, NLA), подключиться не удается. В чем же разница? Есть причины, по которым Microsoft реализовала NLA, и это хорошие причины.

Что такое NLA

NLA заставляет клиентский компьютер представить учетные данные клиента для проверки подлинности до создания сеанса с этим сервером. По этой причине такой процесс иногда называют фронтальной проверкой подлинности. Серверы под управлением Windows Server 2008, Vista или более поздней ОС, а также клиенты с Windows XP SP3 или более поздней ОС поддерживают NLA. Так как NLA основана на технологии, которая называется протоколом CredSSP (Credential Security Support Provider), при использовании клиента удаленного рабочего стола для другой ОС нужно сначала поинтересоваться у разработчика, поддерживает ли этот клиент NLA.

Так чем же так хорошо предоставление учетных данных до создания сеанса? Есть два положительных момента в создании сеанса только после того, как вы убедитесь, что пользователь является именно тем, за кого себя выдает: это позволяет создать дополнительный уровень защиты от DoS-атак, а также ускоряет процесс посредничества.

При создании сеанса, даже просто для того, чтобы отобразить окно входа, требует от сервера создания многих процессов, необходимых для поддержки такого сеанса, таких как Csrss.exe и Winlogon.exe. По этой причине создание сеанса является дорогой и занимающей значительное время операцией. Если несколько посторонних пользователей попытаются подключиться к сеансу одновременно, они могут заблокировать другим, возможно легальным пользователям, возможность создания сеансов.

Вопрос производительности намного важнее. На базе Windows Server 2003 редко создаются фермы. Начиная с Windows Server 2008, фермы создают чаще. Не забывайте, что каждый сервер в ферме узла сеансов удаленных рабочих столов может одновременно быть перенаправителем. Если серверу узла нужно создавать полноценный сеанс перед перенаправлением подключения посреднику подключений удаленных рабочих столов, это увеличивает время подключения.

В NLA используется CredSSP для представления учетных данных серверу для проверки подлинности перед созданием сеанса. Этот процесс позволяет избежать обоих этих проблем. У использования CredSSP есть и другие преимущества. CredSSP позволяет снизить количество операций вход, выполняемых пользователем, за счет хранения учетных данных подключения.

При первом подключении к новому серверу, виртуальной машине или даже другому компьютеру пользователи должны предоставить свои учетные данные. Вместе с тем, у них есть возможность сохранить их. В этом случае при подключении не придется снова предоставлять учетные данные, пока не поменяется пароль.

Как CredSSP поддерживает NLA

Протокол CredSSP позволяет приложениям безопасно делегировать учетные данные пользователя от клиента к целевому серверу. Этот протокол сначала создает зашифрованный канал между клиентом и сервером с применением протокола TLS (Transport Layer Security) (в соответствии со спецификацией RFC2246).

Вы наверняка заметили, что при подключении клиента RDC 6.x или более поздней версии к серверу узла сеансов удаленных рабочих столов при предоставлении учетных данных вы не подключаетесь непосредственно к окну входа узла сеансов удаленных рабочих столов. Вместо этого диалоговое окно для ввода учетных данных открывается на клиенте. Это диалоговое окно является «лицом» CredSSP.

При вводе учетных данных в это окно, даже если вы решите их не сохранять, они поступают в CredSSP. Затем учетные данные передаются на сервер узла сеансов удаленных рабочих столов по безопасному каналу. Этот сервер начнет создание пользовательского сеанса, только получив эти учетные данные.

Клиенты, поддерживающие CredSSP и RDP 6.x и более поздних версий, всегда используют NLA, если этот протокол доступен. Так как CredSSP (технология, поддерживающая NLA) является частью ОС, а не протокола RDP, для нормальной работы NLA клиентская операционная система должна поддерживать CredSSP.

Поэтому хотя в Windows XP SP2 и есть клиент RDC 6.0, использование NLA в этой ОС невозможно. Клиенты под управлением Windows XP SP3, Windows Vista и Windows 7 поддерживают CredSSP. Кроме того, в окне About (О программе) окна подключения к удаленному рабочему столу указано, поддерживается ли NLA. Чтобы открыть это окно, в окне подключения к удаленному рабочему столу щелкните в левом верхнем углу значок компьютера и выберите About (О программе). В открывшемся окне будет указано, поддерживается ли проверка подлинности на уровне сети.

Windows XP SP3 поддерживает CredSSP, но по умолчанию этот протокол отключен. В статье «Описание учетных данных поставщика поддержки безопасности (CredSSP) в Windows XP с пакетом обновления 3» базы знаний Microsoft есть ссылка для включения этого протокола, а также описано, как включить его вручную. После включения CredSSP нужно перезагрузить компьютер.

Если ваша клиентская машина не настроена надлежащим образом для поддержки NLA, вы увидите соответствующее сообщение при попытке удаленно подключиться к машине, которая требует поддержку NLA. Например, если на вашем клиенте с Windows XP SP3 не включен CredSSP, при попытке подключиться к серверу узла сеансов удаленных рабочих столов, который требует NLA, вы получите следующее сообщение об ошибке: «The remote computer requires Network Level Authentication, which your computer does not support» (Удаленный компьютер требует проверки подлинности на уровне сети, которую данный компьютер не поддерживает).

Как обеспечить принудительное использование NLA

По умолчанию серверы узла сеансов удаленных рабочих столов не требуют NLA. Но их можно настроить на поддержку подключений только с компьютеров, поддерживающих NLA — средствами групповой политики или, для конкретных компьютеров, в конфигурации узла сеансов удаленных рабочих столов.

Чтобы требовать NLA при подключении к серверу узла сеансов удаленных рабочих столов, откройте окно конфигурации узла сеансов удаленных рабочих столов. Дважды щелкните RDP-Tcp (в разделе Connections) и на вкладке General отметьте флажком Allow Connections Only From Computers Running Remote Desktop with Network Level Authentication (Разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности). Это не позволит подключиться к серверу клиентам, не поддерживающим NLA (а именно клиентам с RDC версии более ранней, чем 6.x, и под управлением ОС, не поддерживающей CredSSP).

Чтобы включить NLA средствами групповой политики, включите следующую политику и примените ее к подразделению, в котором находится сервер узла сеансов удаленных рабочих столов: Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security/Require User Authentication For Remote Connections By Using Network Level Authentication (Конфигурация компьютера/Политики/Административные шаблоны/Компоненты Windows/Службы удаленных рабочих столов/Узел сеансов удаленных рабочих столов/Безопасность/Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети).

Если отключить или не сконфигурировать эту политику, поддержка NLA требоваться не будет.

VDI-запросы

В средах виртуализации настольных компьютеров (VDI) можно заставить Windows Vista и Windows 7 принимать подключения только от клиентов, поддерживающих NLA. Выберите апплет Control Panel/System/Remote Settings (Панель управления/Система/Настройка удаленного доступа). На вкладке Remote (Удаленный доступ) окна свойств системы установите флажок Allow Connections Only From Computers Running Remote Desktop With Network Level Authentication (More Secure) [Разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности (безопаснее)].

В этой статье рассказано, почему так важно включать NLA на серверах узла сеансов удаленных рабочих столов и в средах виртуализации настольных компьютеров. Вы должны понимать, как требовать использования NLA на серверах и на виртуальных машинах среды VDI, а также как настраивать клиентские компьютеры для поддержки NLA.

Хотя мы не упоминали о сертификатах, но они являются обязательным компонентом любой среды, где используются удаленные рабочие столы. И это касается не только NLA, но и серверной проверки подлинности, использования шлюза удаленных рабочих столов, веб-доступа к удаленным рабочим столам и даже посредника подключений к удаленному рабочему столу. В следующей статье мы поговорим подробнее о требованиях к сертификатам в средах доступа к удаленным рабочим столам.

Часто задаваемые вопросы по NLA

Вопрос У меня компьютер под управлением Windows XP SP3. Я включил CredSSP, но при попытке подключения к серверу узла сеансов удаленных рабочих столов, требующему NLA, получаю ошибку: «An authentication error has occurred» (Произошла ошибка проверки подлинности).

Ответ В моем блоге есть исправление, позволяющее устранить эту проблему.

Эта ошибка наблюдается при наличии следующих условий:

• Клиент работает под управлением Windows XP SP3, и на нем включен CredSSP.
• Вы сконфигурировали сервер на использование реального SSL-сертификата при идентификации (а не автоматически сгенерированного сертификата, который имеется по умолчанию).
• Клиент не доверяет центру сертификации, который подписал этот SSL-сертификат.

NLA требуется безопасный канал, по которому он получает учетные данные, но он не может создать туннель, если не доверяет сертификату. Поэтому NLA не работает. Для исправления ситуации надо позаботиться, чтобы на клиентской машине с Windows XP сертификат, использованный для подписания SSL-сертификата сервера узла сеансов удаленных рабочих столов, был помещен в хранилище сертификатов Trusted Root Certification Authorities (Доверенные корневые центры сертификации).

Примечание В разных версиях — от RDC 6.x до RDC 7.0 — текст ошибки разный. В RDC 7.0 вы можете увидеть такое сообщение: «The connection has been terminated because an unexpected server authentication certificate was received from the remote computer» (Подключение было разорвано, поскольку был получен непредусмотренный сертификат проверки подлинности сервера от удаленного компьютера).