Почему Windows 7/2008 mstsc запрашивает пароль для имени пользователя ДО предупреждения о сертификате сервера?
При использовании Windows 7 mstsc для подключения к Windows Server 2008 (удаленный рабочий стол) я замечаю проблему, которую не могу объяснить.
mstsc сначала запрашивает пароль для имени пользователя. Если я укажу неверный, mstsc сообщит мне: «Учетные данные, которые использовались для подключения, не работали».
Только после того, как я предоставлю правильный, mstsc предупредит меня, что сертификат сервера не является доверенным.
Я думаю, что mstsc ДОЛЖЕН запрашивать «недоверенный сертификат сервера», прежде чем он проверит, «принимает ли сервер мое имя пользователя / пароль».
Итак, мой вопрос: возможно ли, что если сервер, к которому я подключаюсь, является поддельным (размещенным злоумышленником), мои учетные данные будут скомпрометированы?
Даже если мои учетные данные никогда не будут скомпрометированы в такой ситуации, не лучше ли для mstsc запросить проблему сертификата сервера ПЕРЕД запросом имени пользователя / пароля? По крайней мере, это могло бы избавить обычного пользователя от опасений по поводу кражи пароля.
То, что здесь происходит, немного сложно, но если вы прочтете о NLA и CredSSP, вы получите лучшую картину.
http://technet.microsoft.com/en-us/library/cc749211%28WS.10%29.aspx
http://en.wikipedia.org/wiki/Network_Level_Authentication
В общем, чтобы ответить на ваш вопрос ... Нет, поддельный сервер не скомпрометирует ваши учетные данные. Первое, что им нужно сделать, чтобы быть с ними, - это подменить ваш DNS на неправильный IP-адрес, но даже тогда, как RDP работает сейчас (при условии, что мы говорим о клиенте Win7 или Vista и сервере Win2008 или новее), учетные данные зашифрованы и не раскрыты (предостережение - NTLM объясняется в конце статьи Technet).
Вот отрывок из статьи Technet, который может помочь:
В отличие от Windows Server® 2003 Terminal Server, запрос учетных данных находится на клиентском компьютере, а не на сервере. Что наиболее важно, запрос учетных данных клиента находится на безопасном рабочем столе. Таким образом, даже клиент служб терминалов не может видеть учетные данные, что является важным требованием общих критериев. Кроме того, учетные данные, полученные из приглашения, не будут делегированы до тех пор, пока идентификатор сервера не будет аутентифицирован (в зависимости от конфигурации политики). Наконец, сервер терминалов не будет устанавливать сеанс для пользователя (который потребляет значительный объем памяти и время обработки ЦП на сервере) до аутентификации клиента, что снижает вероятность успешных атак типа «отказ в обслуживании» на сервере.
РЕДАКТИРОВАТЬ: давайте добавим пример, чтобы прояснить ...
ПРИМЕР №1 - ПОЛЬЗОВАТЕЛЬ ИМЕЕТ ДОСТУП К УДАЛЕННОМУ СЕРВЕРУ И ИСПОЛЬЗУЕТ ПРАВИЛЬНЫЙ ПАРОЛЬ
В этом примере вы вводите имя пользователя и пароль, он будет ЛОКАЛЬНО аутентифицироваться в домене, чтобы убедиться, что это действительное имя пользователя / pwd, а затем попытается подключиться к удаленному серверу. В этот момент, если это первое соединение, вы, вероятно, получите сообщение «Удостоверение удаленного компьютера не может быть проверено», и вы можете выбрать, доверять ему или нет.
ПРИМЕР №2 - ПОЛЬЗОВАТЕЛЬ ИМЕЕТ ДОСТУП К УДАЛЕННОМУ СЕРВЕРУ И ИСПОЛЬЗУЕТ НЕПРАВИЛЬНЫЙ ПАРОЛЬ
Здесь вы увидите опубликованное вами фото ... Учетные данные не работают. Пожалуйста, введите новые учетные данные. Это делается локально на клиенте (проверяется по билету Kerberos или DC) без подключения к удаленному серверу.
ПРИМЕР №3 - ПОЛЬЗОВАТЕЛЬ НЕТ ДОСТУПА К УДАЛЕННОМУ СЕРВЕРУ, НО ИСПОЛЬЗУЕТ ПРАВИЛЬНОЕ ИМЯ ПОЛЬЗОВАТЕЛЯ И ПАРОЛЬ
Здесь вы аутентифицируетесь локально, поскольку это действующая учетная запись и pwd, но как только вы подключитесь к серверу для передачи учетных данных, вы получите:
Надеюсь, это поможет...