Разбор ситуации: не работает Remote Desktop с Windows XP на Windows 7

        Руководство одной из компаний попросило дать доступ к рабочему компьютеру приболевшему сотруднику, чтобы он мог работать с клиентами из дому. Так как в производственных целях используется одновременно несколько программ, вполне логичным и разумным методом доступа я избрал Remote Desktop. Включил поддержку RDP на рабочей станции, при этом не забыв указать обязательное требование Network Layer Authentication (NLA), на NAT-маршрутизаторе перенаправил на нужную рабочую станцию нестандартный порт, внёс учётную запись в группу Remote Desktop Users. В конце концов, сообщил сотруднику, что он может запустить программу Remote Desktop Connection и соединиться со своим рабочим компьютером по адресу вида MyCompany.LV:12345.

        Первая сложность, с которой пришлось столкнуться, — на домашней машине сотрудника установлена операционная система Windows XP Professional SP3, но поддержка NLA не задействована. На клиенте это выглядит примерно следующим образом:

        Поисковики быстро помогли справиться с этой проблемой:

• в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, мы расширили значение Security Packages строкой tspkg;
• в ключе [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders] в значение SecurityProviders добавили строку credssp.dll.

        Перезагрузка, всё отлично, программа Remote Desktop Connection больше не ругается, но уже запрашивает имя и пароль. Вот тут кроется первая засада, которую не все сразу улавливают. Рабочая станция — доменная, учётная запись пользователя, соответственно, тоже. Для того, чтобы успешно зайти в систему, нужно писать полное имя пользователя вида DOMAIN\Username или Username@domain.lv. В противном случае, аутентификация будет производиться против локальной базы рабочей станции, где доменных учётных записей нет. Конечно, я об этом знаю, поэтому проинструктировал сотрудника корректно. Однако, он заявил, что система его всё равно не пускает, требуя пароль снова и снова:

        Пришлось убедиться в этом воочию — действительно, зайти не удаётся, даже если мы вводим заведомо корректные имя и пароль. Некорректно работает Network Layer Authentication? Без него всё происходит нормально, но снижать уровень безопасности я не собирался. Заглянув в Security Log, я увидел интересную картинку:

       Что мы видим? Имя пользователя и домен указаны корректно; значит, система не узнаёт пароль. Почему же это у меня нормально работало на демонстрационном стенде? В чём отличия между Windows XP, успешно соединяющейся внутри моего домена, с проблемной домашней машиной?

        Тут до меня начинает понемногу доходить: все рабочие станции в моих доменах настроены согласно Протоколу Безопасной Инсталляции (кстати, Слава Протоколу!). Одна из его важнейших настроек, касающаяся сетевой безопасности — уровень аутентификации LAN Manager. Я всегда устанавливаю максимально защищённый уровень Send NTLMv2 response only, Refuse LM & NTLM. В то же время, в Windows XP по умолчанию применяется небезопасный уровень Send LM & NTLM responses, не задействующий NTLMv2. Это несовпадение уровня безопасности и было причиной проблемы. Только повысив LAN Manager Authentication Level на домашнем компьютере сотрудника до NTLMv2, удалось успешно соединиться и начать работать.

        Как итог, было интересным обнаружить, что в ситуациях, когда Kerberos недоступен, NLA использует NTLM / NTLMv2 для аутентификации пользователя, поэтому соответствующие параметры Group Policy клиента и сервера должны быть совместимыми. К сожалению, в публичных источниках техническая составляющая NLA документирована крайне слабо, мне так и не удалось найти алгоритм его работы. До сих пор мне неясно, за счёт чего конкретно NLA помогает предотвратить атаку Man-In-The-Middle, но простейшая демонстрация этой атаки с помощью Cain & Abel доказывает, что применение NLA является необходимым и также должно войти в следующую версию Протокола.