Enablecredsspsupport i 0 что это
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.
Как выглядит ошибка credssp
Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:
Ну и конечно в русском исполнении:
Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.
Назначение CredSSP
После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.
Windows SSP
Следующие поставщики общих служб устанавливаются вместе с Windows:
Причины ошибки шифрования CredSSP
В марте 2018 года, компания Microsoft выпустила обновление безопасности для устранения уязвимостей для протокола поставщика поддержки безопасности учетных данных (CredSSP) под именем CVE-2018–0886 (https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018), используемого подключениями по протоколу удаленного рабочего стола (RDP) для клиентов Windows и Windows Server. Как только пользователи и системные администраторы произвели установку апдейтов, то по всему миру начались массовые жалобы, что люди не могут подключаться по протоколу RDP к серверам, компьютерам, получая ошибку, что причиной ошибки может быть шифрование CredSSP.
К сожалению 99% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.
Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8.1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.
Варианты исправления ошибки CredSSP
На самом деле вариантов много, есть правильные, есть и временные и обходные, которые нужно сделать быстро, чтобы хоть как-то работало, так как бизнес может в этот момент простаивать и терять деньги.
Отключаем credssp в Windows через NLA
Данный метод выхода из ситуации я бы рассматривал, как быстрое, временное решение, до того, как вы установите обновления безопасности. Чтобы разрешить удаленное подключение к серверу и избегать ситуации, что произошла ошибка при проверке подлинности credssp, сделайте вот что. Откройте свойства моего компьютера, попав в систему, так же можно нажать одновременно WIN+Pause Breake или как вариант в командной строке ввести control /name Microsoft.System. В окне «Система» находим пункт меню «Настройка удаленного доступа»
Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:
Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».
Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.
У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSP\Parameters, то нужно будет их создать):
Или можно так же отключить NLA, для этого найдите ветку реестра:
Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.
Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:
Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:
Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:
Еще раз обращаю ваше внимание, что данный метод временный и самый не безопасный, применяемый в случаях, когда уже ничего сделать нельзя или дольше, а нужно уже вчера, обязательно установите все нужные обновления.
Отключаем шифрование credssp через GPO
Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.
Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc.
Вам необходимо перейти в ветку:
Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:
Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.
После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра
На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory
Самый правильный метод, это установка обновлений
Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).
Раньше были вот такие KB, но они со временем могут меняться свой номер, поэтому пройдите по ссылке выше, так будет надежнее.
Страна Админа
Популярно об информационных системах и технологиях
admin@adminland.ru
Вы здесь
Поддержите adminland
За 2020 год из пары десятков тысяч посетителей, набралось всего пару десятков перечислений от 50 до 300 рублей.
Пустяк в денежном выражении, но большая ценность для автора. Посмотрим что год грядущий нам готовит ))
CredSSP NLA и смена пароля через RDP
Текст:
При удаленном соединении с Server 2003 для пользователя сразу создавалась сессия в которую затем вводился логин/пароль, после успешной проверки предоставлялся доступ к рабочему столу. Создание сессии до проверки учетных данных открывало большие возможности для DDoS и несанкционированного исполнения процессов.
Для решения этой проблемы, начиная с Server 2008 R2 для терминальных подключений по RDP была введена технология Network Level Authentication (NLA). При использовании NLA учетные данные вводятся в RDP клиент, который передает их на сервер. И только после их успешной проверки на сервере создается пользовательская сессия. Для передачи учетных данных в NLA используется протокол Credential Security Support Provider (CredSSP).
NLA однозначно полезна и рекомендуема к использованию, но как и любой защитный механизм приносит определенные неудобства для пользователей и администраторов. Наиболее заметной является проблема смены пароля при RDP подключении. Нет, если пользователь уже зашел по RDP, то поменять пароль через net user или ctrl+alt+end не составит никакой сложности.
Проблемный сценарий №1: администатор создает нового пользователя, устанавливает ему стандартный пароль, например QWErty123 и ставит галочку User must change password at next login.
Проблемный сценарий №2: у пользователя истекает пароль, а смена пароля через 30-60 дней это стандартное требование информационной безопасности практически в любой организации.
Если у пользователя имеется доступ к рабочей станции то он может поменять пароль и далее заходить и работать по RDP. А если нет?
В этом случае, учетные данные будут считаться недействительными и пользовательская сессия на сервере, благодаря NLA, не будет создана. Вы получите сообщение об ошибке You must change your password before loggin on first time. Please update your password or contact your system administrator or technical support.
Одним из способов решения проблемы является отключение NLA со стороны сервера и клиента. Тут возможны разные сочетания версий ОС и как следствие разные сочетания настроек по умолчанию. У кого-то все заработает после отключения NLA на сервере, у кого-то придется делать дополнительные шаги и отключать на клиенте. Данное решение допустимо использовать для серверов и клиентов находящихся в защищенной сети, где угрозы DDoS и несанкционированного доступа минимальны.
Отключение NLA со стороны сервера.
Возможны два варианта: просто сервер и сервер с ролью Remote Desktop Session Host.
Отключение NLA со стороны клиента.
Сохраняем файл и двойным щелчком запускаем его.
Еще раз повторюсь, что отключение NLA не рекомендуется. Если все таки деваться некуда, то правильно будет выделить отдельный сервер БЕЗ роли Remote Desktop Session Host предназначенный только для смены паролей и только на нем отключить NLA. На этом сервере пользователей НЕ НУЖНО включать в группу Remote Desktop Users так как проверка и смена пароля выполняются до входа в систему. В этом случае пользователь при подключении по RDP сможет поменяет пароль, но не сможет зайти на сервер.
Способы смены пароля учётной записи пользователя в RDP-сессии
При использовании удалённого подключения к операционным системам Microsoft Windows/Windows Server по протоколу RDP в некоторых случаях может возникать потребность в смене пароля учётной записи пользователя. При этом инициатором смены пароля в разных ситуациях может выступать как сам пользователь, так и администратор Windows-системы. В некоторых сценариях может получиться так, что, казалось бы, несложная задача смены пароля может стать не такой уж и простой. Поэтому в данной записи я попробую собрать информацию о самых разнообразных способах смены пароля учётной записи пользователя в RDP-сессии.
В случае, если пользователю Windows необходимо самостоятельно изменить пароль своей учётной записи, то в стандартной Windows-сессии пользователем может использоваться всем известное сочетание «горячих» клавиш Ctrl-Alt-Del. Это сочетание клавиш вызывает специальный экран Безопасности Windows (Windows Security), с которого доступна функция изменения пароля :
Если же речь заходит об использовании горячих клавиш в RDP-сессиях, то стоит заметить то, что во избежание перехвата некоторых сочетаний клавиш локальной клиентской системой (системой, с которой запускается RDP-клиент), перенаправление сочетаний клавиш Windows должно быть явно разрешено в свойствах RDP-клиента. Например в клиенте mstsc.exe, встроенном в Windows, данную опцию можно включить на закладке управления локальными ресурсам.
В стандартной первичной RDP-сессии для вызова специального экрана Безопасности Windows с функцией изменения пароля используется сочетание клавиш: Ctrl—Alt—End
В случае использования вложенных RDP-сессий (второго и последующего уровней), то есть когда из одной RDP-сессии открывается другая RDP-сессия, стандартное сочетание клавиш работать не будет. В разных источниках в интернете можно найти информацию об использовании более сложных сочетаний клавиш, таких как Ctrl—Alt—Shift-End или Shift-Ctrl-Alt-End. Однако мои эксперименты с Windows 10/Windows Server 2012 R2 показали, что данные сочетания клавиш попросту не работают (возможно они работали в ранних версиях ОС Windows). В этом случае на выручку нам может прийти следующий способ.
В составе Windows имеется приложение «Экранная клавиатура» (On-Screen Keyboard), расположенное по умолчанию в %SystemRoot%\System32\osk.exe. Используя это приложение, мы можем решить проблему использования «горячих» клавиш во вложенных RDP-сессиях.
Находясь во вложенной RDP-сессии, вызовем окно запуска приложений. Вызвать его можно разными способами, например, через контекстное меню по кнопке Windows, или через Диспетчер задач (Task Manager):
Либо можно использовать сочетание клавиш Win-R.
В окне запуска приложений выполним запуск исполняемого файла osk.exe
После того, как откроется приложение «Экранная клавиатура», нажмём на физической клавиатуре сочетание клавиш Ctrl—Alt, так, чтобы это отобразилось на экранной клавиатуре и затем, удерживая это сочетание клавиш, на экранной клавиатуре мышкой нажмём кнопку Del.
Таким образом мы отправим в удалённую RDP-сессию сочетание клавиш Ctrl-Alt-Del, в следствие чего откроется специальный экран Безопасности Windows с функцией изменений пароля пользователя.
Способ №3 – Ярлык на VBS-скрипт или Powershell
Вызов экрана Безопасности Windows можно выполнить не только интерактивными способами, но и программными, например, с помощью скриптов.
Разместим скрипт в месте, доступном на чтение (но не для редактирования) для всех пользователей удалённого рабочего стола, например в каталоге %SystemRoot% ( C:\Windows ). А ярлык на запуск скрипта можно разместить в любом доступном пользователям месте, например, в каталоге общего профиля %SystemDrive%\Users\Public\Desktop\
При запуске данного ярлыка у пользователя будет открываться экран Безопасности Windows с возможностью изменения пароля.
Для любителей PowerShell приведённый VBS-скрипт можно заменить PS-скриптом следующего вида:
Либо запускать из ярлыка команду вида:
Однако стоит отметить тот факт, что запуск варианта с PowerShell будет происходить медленней, чем варианта с VBS-скриптом.
Описанные здесь способы с запуском ярлыка, ссылающегося на скрипт, может попросту не сработать, так как в некоторых окружениях серверов служб удалённых рабочих столов может быть заблокирована возможность выполнения скриптов. В таком случае, можно воспользоваться следующим способом.
Способ №4 – Ярлык оболочки Windows Explorer
Если говорить о создании ярлыка запуска экрана Безопасности Windows, то имеется ещё один вариант создания такого ярлыка. Создаётся ярлык со ссылкой на расширение оболочки Windows Explorer следующего вида:
Опять же, при запуске такого ярлыка у пользователя будет открываться экран Безопасности Windows с возможностью изменения пароля. Этот способ одинаково хорошо работает на Windows 10 и на Windows Server 2012 R2.
Способ №5 – Панель управления Windows (локальные учётные записи)
Данный способ относится лишь к локальным учётным записям пользователей. Изменить пароль учётной записи рядового локального пользователя можно через Панель управления Windows. В Windows 10 из раздела Панели управления «Учётные записи пользователей» доступен вызов окна «Параметры компьютера«, в котором имеется функция изменения пароля текущего локального пользователя.
Такие методы вызова апплета управления учётными записями пользователей Панели управления Windows, как, например команда «control userpasswords2«, в качестве отдельного способа мы выделять не будем, так как подобные действия требуют административных прав в удалённой системе. То же самое касается и таких CLI-утилит Windows, как net.exe ( %SystemRoot%\System32\net.exe ) (пример команды «net user username newpassword«), так как они тоже требуют повышения уровня прав пользователя.
Ремарка
Отдельно хочется отметить обстоятельство, про которое порой забывают администраторы, и это может приводить к разным курьёзным ситуациям.
Попытки смены пароля, инициированные самим пользователем, могут оказаться безуспешными в случае, если пароль был недавно изменён и на удалённую Windows систему действует политика безопасности, определяющая минимальный срок действия пароля.
Повторюсь, что повлиять на ситуацию эта политика может только в случаях, когда пользователь самостоятельно инициирует процедуру смены пароля.
Далее мы поговорим о сценарии, при котором требование смены пароля включается для учётной записи пользователя форсировано администратором сервера (для локальных учётных записей), либо администратором службы каталогов Active Directory (для доменных учётных записей).
Практика показывает, что как только администратором включено требование смены пароля пользователя при следующем входе в систему, у пользователя могут возникнуть проблемы с подключением по протоколу RDP, если на стороне RDS сервера (а в некоторых случаях и на стороне RDS клиента) предварительно не предпринято никаких действий по специальной настройке обработки таких ситуаций. Далее мы рассмотрим пару примеров такой настройки.
Клиентский доступ к службам Windows Server RDS может быть организован через веб-интерфейс серверной роли Remote Desktop Web Access (RDWA). В функционале этой роли имеется выключенная по умолчанию возможность смены пароля пользователя в процессе аутентификации на веб-странице RDWA.
Чтобы включить данную возможность в Windows Server 2012/2012 R2 откроем консоль управления Internet Information Services (IIS) Manager, выберем сайт RDWA, развернём RDWeb > Pages и в разделе настроек ASP.NET выберем настройку опций веб-приложения Application Settings:
В перечне опций находим PasswordChangeEnabled и меняем установленное по умолчанию значение false на true:
Если серверов RDWA несколько и они работают в пуле за балансировщиком, например Windows NLB, то не забываем выполнить данное изменение на всех других серверах пула.
Теперь попытаемся от имени пользователя, у которого в свойствах учётной записи установлено требование смены пароля при следующем входе, аутентифицироваться на веб-странице RDWA:
После ввода учётных данных пользователя появится сообщение о том, что пароль пользователя требует замены и ссылка на страницу с функцией смены пароля ( https:// /RDWeb/Pages/ru-RU/password.aspx ):
На этой отдельной странице пользователь сможет ввести свои текущие учётные данные и новый пароль:
В случае успешной смены пароля пользователь получит соответствующее сообщение: 
При необходимости ссылку на страницу смены пароля можно сделать доступной не только тем пользователям, у которых после аутентификации возникает требование смены пароля, но и всем остальным пользователям, чтобы они могли самостоятельно выполнять смену пароля по собственной инициативе через веб-страницу RDWA. Для этого можно будет внедрить ссылку на страницу password.aspx на странице входа login.aspx (по умолчанию страницы расположены в каталоге %windir%\Web\RDWeb\Pages\ru-RU )
Способ №7 – Специальный RDP-файл
Если пользователь выполняет подключение к удалённому рабочему столу на базе Windows Server 2012/2012 R2 через прямой запуск стандартного клиента mstsc.exe, то в ситуации с включенным признаком требования смены пароля, попытка подключения может быть завершена с ошибкой » You must change your password before logging on the first time. Please update your password or contact your system administrator or technical support «.
Если ситуация требует того, чтобы пользователь самостоятельно изменил свой пароль при первом входе в систему, то это потребует некоторого изменения уровня безопасности настроек протокола RDP на стороне RDS сервера и подготовки специального RDP-файла на стороне клиента.
Сначала на клиентской стороне откроем mstsc.exe, настроим все нужные параметры подключения к серверу RDS и используя кнопку Сохранить как, создадим RDP-файл.
После этого откроем RDP-файл в текстовом редакторе и добавим в конец файла строку «enablecredsspsupport:i:0«
Разрешить эту ситуацию можно только понизив уровень безопасности RDP на стороне RDS сервера, отключив обязательное требование проверки подлинности на уровне сети (NLA). Изменить эту настройку можно в свойствах системы на закладке Удалённый доступ:
В английской версии Windows название опции звучит как «Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)»
Если NLA нужно отключить на уровне коллекции серверов Windows Server 2012 R2, то сделать этом можно в свойствах коллекции сеансов, например через оснастку Server Manager:
После того, как отключено требование NLA на стороне RDS сервера, клиент с помощью специального RDP-файла, о котором мы сказали выше, должен успешно установить RDP-сессию и уже в ней получить сообщение о необходимости смены пароля:
И после этого пользователю будет показан экран, на котором он сможет задать новый пароль:
После успешной смены пароля последующие подключения по протоколу RDP будут проходить в штатном режиме без лишних запросов.
Заключение
Приведённый здесь перечень способов смены пароля при использовании протокола RDP не претендует на какую-то полноту и исключительность, а лишь отражает ту информацию, которую мне удалось найти в разных источниках по этому поводу. На мой взгляд, ни один из перечисленных способов нельзя считать наиболее удобным или универсальным, так как каждый из способов может применяться в определённых ограниченных сценариях и имеет, как преимущества, так и недостатки по сравнению с другими способами.
Дополнительные источники информации:
