Windows defender remote credential guard

Тема безопасности сервера Windows не раз поднималась, в том числе и в этом блоге. Тем не менее мне хотелось бы еще раз освежить в памяти старые методы защиты и рассказать о малоизвестных новых. Разумеется, будем использовать по максимуму встроенные средства.

Итак, предположим, что у нас есть небольшая компания, которая арендует терминальный сервер в удаленном дата-центре.

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

За тобой как за огненной стеной

Во времена Windows 2003 встроенный фаервол представлял собой жалкое зрелище, и в случае невозможности применения сторонних средств приходилось использовать IPSec. Пример такой настройки разобран, например, в материале Secure Windows Servers using IPSec Firewall.

Сейчас, с появлением WFP (Windows Filtering Platform) дела стали получше. В принципе, с этим фаерволом так или иначе сталкивался, наверное, каждый системный администратор Windows, поэтому настройка удаленного доступа к серверу только с определенных IP не должна вызывать затруднений. Я обращу внимание на некоторые «фишки», которые используются редко.

По умолчанию фаервол блокирует все входящие соединения, кроме явно разрешенных, но исходящие разрешает все, кроме явно запрещенных. Политику эту можно изменить, открыв управление фаерволом через wf.msc и выбрав «Свойства».

Настройка фаервола.

Теперь, если мы захотим запретить пользователям терминального сервера выходить с этого сервера в интернет — у нас это получится.

Стоит отметить, что при настройке правил доступа к серверу (входящие подключения) явно создавать правила для исходящего трафика не нужно. В терминах iptables — established и related всегда разрешены.

Для ценителей командной строки настройку фаервола можно производить в контексте netsh advfirewall. Почитать про команды можно в материале «Брандмауэр Windows 7 в режиме повышенной безопасности», я же добавлю, что блокировка входящих и исходящих подключений включается командой:

netsh advfirewall set currentprofile firewallpolicy blockinbound,blockoutbound

Еще одной особенностью фаервола windows является то, что любая программа или настройка меняет его правила без уведомлений. Например, отключили вы все правила на нашем дедике, рядом появился второй, вы сделали между ними локальную сеть, настроили общий доступ и… внезапно у вас включается smb для всех и вся со всеми вытекающими последствиями.

Выхода, по сути, два с половиной (напомню, мы пока говорим только про встроенные средства): регулярно проверять, не изменились ли правила, и использовать старый добрый IPSec или — как по мне, самый разумный вариант — настраивать фаервол групповой политикой. Настройка производится в Конфигурация компьютера — Конфигурация Windows — Параметры Безопасности — Монитор брандмауэра Защитника Windows в режиме повышенной безопасности.

Настройка фаервола групповой политикой.

Также при помощи фаервола windows можно реализовать простой fail2ban. Достаточно включить аудит неудачных попыток входа и при нескольких неудачах подряд блокировать IP источника. Можно использовать самописные скрипты, а можно уже готовые средства, о которых я писал в статье «Как дать шифровальщикам потопить компанию».

Если же встроенного фаервола не хватает и хочется использовать что-то более серьезное, то можно установить стороннее ПО. Жаль, что большинство известных решений для Windows Server — платные. Другим вариантом будет поставить перед сервером роутер. Понятно, что такая установка подойдет, если мы используем colocation, а не аренду сервера где-то далеко-далеко за рубежом. Если же зарубежный дата-центр — это наш выбор, то можно использовать виртуализацию — например, встроенный Hyper-V — и установить в виртуалку привычный GNU\Linux или FreeBSD.

Возникает вопрос: как сделать так, чтоб виртуалка имела прямой выход в интернет, а сервер — нет? Да еще чтобы MAC-адрес сервера не светился хостеру и не требовал тем самым покупки еще одного IP-адреса.

Осторожно! Дальнейшие действия лучше проводить через IP-KVM!

Для этого виртуальную машину нужно снабдить двумя сетевыми адаптерами. Один — для непосредственного подключения к интернету, для него мы сделаем виртуальный коммутатор типа «внешний» и снимем галочку, разрешающую операционной системе взаимодействие с этим коммутатором. Этой самой галочкой мы лишим сервер прямого доступа в интернет (настройку виртуальной машины-фаервола лучше произвести заранее), и его MAC не будет светиться хостеру.

Настройка внешнего виртуального коммутатора.

Другой виртуальный коммутатор следует сделать типа «внутренний» для взаимодействия виртуальной машины и сервера. На нем уже нужно настроить локальную адресацию. Так получится создать виртуальный роутер, стоящий перед сервером и защищающий его.

Заодно на этой виртуальной машине можно настроить любимый VPN до офиса или удаленных сотрудников, не заморачиваясь с ролью «Маршрутизация и удаленный доступ» или со встроенным IPSec, как я рассказывал в статье «Как я базы 1С в Германии прятал». Главное, не забыть проверить автозапуск этой виртуальной машины при старте системы.

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

Снаружи сервер мы более-менее защитили, перейдем к защите внутренней.

Защита внутренняя: остановить и не пущать

Конечно, для защиты сервера изнутри очень хочется поставить какой-нибудь антивирус — мало ли что пользователи сервера накопируют или накачают из интернета. Но на практике антивирус на сервере может принести больше вреда, чем пользы. Поэтому я обычно использую механизмы блокировки запуска ПО не из белого списка — в частности, механизм SRP (software restriction policies), о котором я тоже упоминал в статье «Как дать шифровальщикам потопить компанию».

Остановлюсь чуть подробнее на одном подводном камне, о котором часто забываем при включении SRP со стандартными настройками, когда блокируется все, кроме папок Windows и Program Files. Действительно, это отфильтровывает почти всех зловредов. Но не очень работает со злонамеренностью сотрудников, ведь в системных папках есть подпапки с правом на создание объектов пользователями. Например, можно посмотреть на папку C:\Windows\Temp.

Разрешения на папку, которая попадет в белый список.

И такая папка не одна. Можно, конечно, проводить аудит системных папок самостоятельно, а можно довериться людям, которые это уже сделали. Например, специалист Stefan Kanthak в своем блоге (по ссылке есть тестовый вирус EICAR, антивирус может сработать) в довольно агрессивной манере проходится по антивирусам и методам защиты Windows и заодно предлагает уже собранный пакет настроек SRP, который будет блокировать и такие подозрительные папки. По запросу автор предоставляет и программу для конвертирования этих настроек реестра в файлы локальных политик.

Если вы предпочитаете использовать механизм AppLocker c более гибкими настройками, то вам может помочь решение AaronLocker.

Редакция не рекомендует использовать и устанавливать скрипты и прочие программы из интернета без предварительного их изучения.

Если AppLocker появился уже довольно давно, а возраст SRP перевалил за 15 лет, то относительно свежей альтернативой является WDAC (Windows Defender Application Control). Действительно, со времен Security Essentials встроенный «антивирус» обзавелся многими интересными возможностями. Например, WDAC — модуль, который отвечает за политики доступа к приложениям и библиотекам. Ранее он являлся частью Device Guard (защита компьютера, в том числе с применением технологий виртуализации), и немного про его настройку рассказывалось в материале «Принцип работы S Mode в Windows 10 и настройка Device Guard своими руками». Подробнее со всеми тонкостями можно ознакомиться в официальной документации, мне же остается добавить несколько минусов, отличающих его от классических решений вроде SRP и AppLocker:

• Графической настройки нет, все через командлеты PowerShell.
• Нет настроек в срезе пользователя, только для компьютера.
• Настройка делается довольно непривычно — подготавливается файл в формате xml, который затем приводится к бинарному, и распространяется по компьютерам.

Зато возможна настройка в срезе приложения: например, если вы хотите дать доступ к cmd.exe вашему скрипту, а не стороннему вирусу — это можно реализовать. Да еще и политику можно применить до загрузки системы, при помощи UEFI.

Блокировка хрома через WDAC.

В целом из-за тягостной настройки сложилось впечатление, что WDAC больше позиционируется не сам по себе для управления компьютерами, а как средство, позволяющее интегрироваться с централизованными MDM-системами вроде Microsoft Intune. Но при этом разработка старых добрых SRP прекращена в Windows 10 1803.

Если говорить про Защитник Windows, нельзя не упомянуть про Credential Guard и Remote Credential Guard.

Первое средство использует опять же виртуализацию, запуская компонент LSA (Local Security Authority) в изолированном от операционной системы процессе, что сильно усложняет процесс кражи хешей паролей и билетов Kerberos. Подробнее про технологию можно почитать в официальной документации. Для работы процессор должен поддерживать виртуализацию, а также в системе должна быть включена безопасная загрузка (Secure Boot) и модуль TPM для привязки учетных данных к оборудованию. Включить Credential Guard можно через групповую политику Конфигурация компьютера — Административные шаблоны — Система — Device Guard — Включить средство обеспечения безопасности на основе виртуализации.

Включение Credential Guard.

Второе средство служит для защиты передаваемых учетных данных (особенно админских!) для удаленного подключения, например, по тому же RDP. Ранее для этих целей предлагался механизм Restricted Admin Mode, но он ограничивал подключение только одним сервером. Подключившись к серверу, нельзя было просто так использовать ресурсы сети, права администратора применялись только к одному серверу а-ля системный аккаунт Local System.

Remote Credential Guard позволяет передавать учетные данные с локальной машины удаленному серверу без явного ввода пароля, что, помимо расширенной безопасности, даст и удобство подключения к серверам (SSO). Почитать подробнее можно в документации, ну а я добавлю, что для работы механизма достаточно включить его поддержку на сервере — например, через реестр командой:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0

А потом подключаться к серверу командой:

mstsc.exe /remoteGuard

Теперь учетные данные в безопасности, а сервер достаточно защищен. Правда, в материале я осознанно не касался вопросов защиты от злонамеренного хостера, но тут все сводится в общем-то к одному — к шифрованию дисков.

Расскажите, а как вы защищаете свои удаленные серверы?

Проголосовали 88 пользователей.

Воздержались 22 пользователя.

Remote Defender Credential Guide was introduced in Windows 10 version 1607 to be precise and helps protect your credentials over a Remote Desktop connection by redirecting Kerberos requests back to the device that’s requesting the connection. It also provides single sign-on experiences for Remote Desktop sessions. You may want to learn about how to enable or disable Memory integrity in windows, reputation based protection, and how to enable or disable Windows Defender Credential Guard I wrote yesterday :-). Please refer to the original guide, I will do my best to limit internal links from my website that are vital.

You will agree with me that highly privileged Administrators’ credentials are very critical and must be adequately and correctly protected. Note: Neither Windows Defender Remote Credential Guard nor Restricted Admin mode will send credentials in clear text to the Remote Desktop server.

How does Windows Defender Remote Credential Guard compare to Restricted Admin and  Remote Desktop Connection?

In this section, we will be discussing Windows Remote Desktop connection types, and how the standard remote desktop connection differs from others without employing a Windows Defender Remote Credential Guard or the Restricted Admin Mode. In order to connect remotely, Remote Desktop Settings must be enabled on the destination server to allow remote connection to the device. 

Scenario 1: Remote Desktop Connection to a Server without the Windows Defender Remote Credential Guard

This scenario involves the standard Remote Desktop connection we initiate to VMs and physical devices. Since we will be protecting Remote Desktop credentials, this step is worth discussing. You may want to learn about Remote Desktop Web Clients, Remote Desktop Services (RDS) etc. Remote Desktop Protocol is a proprietary protocol developed by Microsoft which provides a user with a graphical interface to connect to another computer over a network connection. In this guide, we will learn about the various options available. see the following guides: How to remove saved RDP credentials entries in Windows 10, how to remove entries histories from the Remote Desktop Connection, and how to prevent the saving of Remote Desktop Credentials in Windows. In place of an RDP client, you can also use AnyDesk!

Src: Microsoft

Add on; Note that with the Mstsc command. every time you connect to the server it opens a new user session. To avoid this we can open a connection to the console. This allows us to login back into the same user session if we already have one. To do this, you will need to append the  /console switch to the mstsc command as shown below.

With the above option, When administrators connect to a remote computer using RDP, their credentials are normally stored on the remote computer, which is a security threat if that system is to be compromised.

Scenario 2: Remote Desktop Connection to a Server with the Restricted Admin mode or Windows Defender Remote Credential Guard

This guide describes the steps to enable RestrictedAdmin mode for Remote Desktops. RestrictedAdmin mode prevents the transmission of credentials to the remote system to which you are connecting via the Remote Desktop Client. This prevents your credentials from being harvested during the initial connection process if the remote server has been compromised.

Enable Restricted Admin mode

Restricted Admin mode is disabled by default, and must be explicitly enabled on the destination server using the Group Policy or the Windows Registry setting. The account that will be used to connect to the remote server must be a member of the local Administrators group on the destination system. To do this, launch the Local Group Policy Editor or the Group Policy or the Group Policy Management tool and Navigate to theComputer Configurations > Administrative Templates > System > Credential Delegation

Then Set Restrict Delegation of credentials to remote servers to enable

This setting will take effect when Group Policy refreshes. To immediately refresh the group policy, open an elevated command prompt and enter the following command below. Alternatively, to ensure this applies immediately on the remote server itself, run GPUpdate. For more information on GPO switches, see all about GPUpdate switches – GPUpdate vs GPUpdate /force.

Gpupdate.exe /target:computer /force

To disable RestrictedAdmin mode, configure the above group policy setting to

Enable Enable Restricted Admin mode via the Windows Registry

To do that we need to add a registry entry. Note that these steps can also be published via the Registry Windows Settings in the Group Policy Management Editor as well.

We will be using the Windows Registry editor, therefore, log in to server or pc as administrator and start > Run > regedit

Browse to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Add Registry Key DisableRestrictedAdmin Type: REG_DWORD Value: 0. A reboot is not required to have these settings applied.

How to connect to a remote server using the Restricted Admin Mode

Once this configuration are done via the registry or GPO, you can connect to the remote RDP server via the command line or run command. To use Restricted Admin mode, an additional parameter must be added to the Remote Desktop client application at the command line, as follows

Note: If you do not connect using the connection method specified when the Restricted Admin mode is configured (Mstsc.exe /RestrictedAdmin), you can’t connect to other network resources as it’s not passing the credentials. With the policy setting «Require Restricted Admin«: Participating applications must use Restricted Admin to connect to remote hosts.

How to enable Windows Defender Remote Credential Guard

By using Windows Defender Remote Credential Guard to connect during Remote Desktop sessions, if the target device is compromised, your credentials are not exposed because both credential and credential derivatives are never passed over the network to the target device. Here are some guides that I highly recommend that you take a look at. Windows Defender Credential Guard which employs virtualization-based security to isolate secrets. In this way, only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket.

Windows Defender Credential Guard prevents these attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets, and credentials stored by applications as domain credentials. As described above and in the image below, the Windows Defender Remote Credential Guard blocks NTLM (allowing only Kerberos), thereby preventing Pass-the-Hash (PtH) attacks, and also preventing the use of credentials after disconnection.

Step 1: Enable Windows Defender Remote Credential Guard on the remote host via Windows GPO

From the Group Policy Management Console, go to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation, and then double-click Restrict delegation of credentials to remote servers.

This will open the Restrict delegation of credentials to remote server’s policy settings

Note: We have two restricted modes and a good understanding of both is paramount. They are

• Require Remote Credential Guard, and
• Restrict credential Delegation

Note: If you enable any of these policy settings, the following options are supported:

• Restrict Credential Delegation: Participating applications must use Restricted Admin or Remote Credential Guard to connect to remote hosts.  In this configuration, Windows Defender Remote Credential Guard is preferred, but it will use Restricted Admin mode (if supported) when Windows Defender Remote Credential Guard cannot be used.
• Require Remote Credential Guard: Participating applications must use Remote Credential Guard only to connect to remote hosts (mstsc /remoteguard).

For test purposes, I will be using require Remote Credential Guard since I am only interested in testing the Remote Credential Guard. When you are done with the policy, click on Ok.

How to enable Windows Defender Remote Credential Guard using Windows Registry

In order to save time, you can enable the Windows Defender Remote Credential Guard via the command line as shown below. To do this from the command line, ensure to run the command below with Administrative rights.

Navigate t the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa. Add a new DWORD value named DisableRestrictedAdmin. To turn on Restricted Admin and Windows Defender Remote Credential Guard, set the value of this registry setting to 0 to turn on Windows Defender Remote Credential Guard.

When you are done, click on OK and close Registry Editor. 

Use Remote Credential Guard with a parameter to Remote Desktop Connection

If you don’t use Group Policy in your organisation, you can add the remoteGuard parameter when you start Remote Desktop Connection to turn on Remote Credential Guard for that connection.

Note: If you are not authorised to connect to the remote server using RDP. The user or admin must be a member of the  Remote Desktop Users local group on the remote computer

mstsc.exe /remoteGuard

Встроенный RDP клиент Windows (mstsc.exe) позволяет сохранить на компьютере имя и пароль пользователя для подключения к удаленному рабочему столу. Благодаря этому пользователю не нужно каждый раз вводить пароль для подключения к удаленному RDP компьютеру/серверу. В этой статье мы рассмотрим, как разрешить сохранять учетные данные для RDP подключений в Windows, и что делать, если несмотря на все настройки, у пользователей не сохраняются пароли для RDP подключения (пароль запрашивается каждый раз)

Как сохранить пароль для RDP подключения в Windows?

По умолчанию Windows разрешает пользователям сохранять пароли для RDP подключений. Для этого в окне клиента Remote Desktop Connection (mstsc.exe) пользователь должен ввести имя удаленного RDP компьютера, учетную запись и поставить галку “Разрешить мне сохранять учетные данные” (Allow me to save credential). После того, как пользователь нажимает кнопку “Подключить”, RDP сервер запрашивает пароль и компьютер сохраняет его в Windows Credential Manager (не в .RDP файл).

При следующем подключении к удаленному RDP серверу под этим же пользователем, клиент автоматически получит сохраненный пароль из менеджера паролей Windows и использует его для RDP-аутентификации.

Если для данного компьютера имеется сохраненный пароль, в окне RDP клиента будет указано:

При подключении к данному компьютеру будут использоваться сохранённые учетные данные. Эти учетные данные можно изменить или удалить.

Saved credentials will be used to connect to this computer. You can edit or delete these credentials.

В большинстве случаев администраторы не рекомендуют пользователям сохранять пароли подключений в Windows. Например, в домене Active Directory лучше настроить SSO (Single Sign-On) для прозрачной RDP аутентификации.

По умолчанию Windows не разрешает пользователю использовать сохраненный пароль RDP подключения с компьютера, добавленного в домен Active Directory, к компьютеру/серверу, который находится в другом домене или рабочей группе. Несмотря на то, что пароль для подключения сохранен в Credentials Manager, Windows не позволяет его использовать, и требует от пользователя каждый раз вводить пароль. Также Windows не разрешает использовать сохраненный пароль для RDP, если вы подключаетесь не под доменной, а под локальной учетной записью.

При попытке RDP подключения с сохраненным паролем в этой ситуации появляется окно с ошибкой:

Или (в русской редакции Windows 10):

Windows считает такое подключение небезопасным, т.к. отсутствуют доверительные отношения между этим компьютером и удаленным компьютером/сервером в другом домене (или рабочей группе).

Вы можете изменить эти настройки на компьютере, с которого выполняется RDP подключение:

1. Откройте редактор локальной GPO, нажав Win + R -> gpedit.msc ;
2. В редакторе GPO перейдите в раздел Computer Configuration –> Administrative Templates –> System –> Credentials Delegation (Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учетных данных). Найдите политику с именем Allow delegating saved credentials with NTLM-only server authentication (Разрешить передачу сохраненных учетных данных с проверкой подлинности сервера только NTLM);
3. Дважды щелкните по политике. Включите политику (Enable) и нажмите на кнопку Показать (Show);
4. В открывшемся окне нужно будет указать список удаленных компьютеров (серверов), для которых будет разрешено использовать сохранные пароли для RDP подключения. Список удаленных компьютеров нужно указать в следующих форматах:
   • TERMSRV/server1
     — разрешить использование сохранённых паролей для RDP подключения к одному конкретному компьютеру/серверу;
   • TERMSRV/*.winitpro.ru
     — разрешить RDP подключение ко всем компьютерам в домене winitpro.ru;
   • TERMSRV/*
     — разрешить использование сохранённого пароля для подключения к любым компьютерам.

   

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

5. Аналогичным образом включите и добавьте ваши значения TERMSRV/ в параметр Allow Delegating Saved Credentials (“Разрешить передачу сохранённых учетных данных”);

   Этим настройкам GPO соответствуют следующие параметры реестра:

   Windows Registry Editor Version 5.00
   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]
   "AllowSavedCredentialsWhenNTLMOnly"=dword:00000001
   “AllowSavedCredentials”=dword:00000001
   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowSavedCredentialsWhenNTLMOnly]
   "1"="TERMSRV/*"
   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowSavedCredentials]
   "1"="TERMSRV/*"
   [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\CredentialsDelegation]
   “AllowSavedCredentialsWhenNTLMOnly”=dword:00000001
   “AllowSavedCredentials”=dword:00000001
   [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\CredentialsDelegation\AllowSavedCredentialsWhenNTLMOnly]
   "1"="TERMSRV/*"
   [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\CredentialsDelegation\AllowSavedCredentials]
   "1"="TERMSRV/*"
   

6. Проверьте, что политика Deny delegating saved credentials / Запретить передачу сохраненных учетных данных отключена (или не настроена). Запретительные политики GPO имеют более высокий приоритет, чем разрешающие;
7. Также должен быть отключен параметр Network access: Do not allow storage of passwords and credentials for network authentication (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options); Если этот параметр включен, то при попытке сохранить пароль в хранилище пользователь получит ошибку:

   Credential Manager ErrorUnable to save credentials. 
    To save credentials in this vault, check your computer configuration.Error code: 0x80070520
   Error Message: A specified logon session does not exist. It may already have been terminated.

8. Сохраните изменения и обновите групповые политики командой
   gpupdate /force

Теперь при выполнении RDP подключения клиент mstsc сможет использовать сохранённый пароль.

Вы можете вывести список сохранённых паролей для RDP подключений с помощью команды:

cmdkey /list ^| findstr "target=TERMSRV"

Чтобы очистить сохраненные пароли подключений, выполните команду:

For /F "tokens=1,2 delims= " %G in ('cmdkey /list ^| findstr "target=TERMSRV"') do cmdkey /delete %H

С помощью локального редактора групповых политик вы сможете переопределить политику только на локальном компьютере. Если вы хотите чтобы политика разрешения использования сохранённых паролей для RDP подключения действовала на множество компьютеров домена, используете доменные политики, которые настраиваются с помощью консоли gpmc.msc.

Что делать, если в Windows не сохраняется пароль для RDP подключения?

Если вы настроили Windows по инструкции выше, но клиент все равно при каждом повторном RDP подключении требует ввести пароль следует проверить следующее:

1. В окне RDP подключения нажмите на кнопку “Показать параметры” и убедитесь, что опция “Всегда запрашивать учетные данные” (Always ask for credentials) не выбрана;
2. Если вы используете для подключения сохранённый RDP файл, проверьте, что параметр “prompt for credentials” равен 0 (
   prompt for credentials:i:0
   );
3. Запустите редактор локальной групповой политики
   gpedit.msc
   , перейдите в раздел Конфигурация компьютера -> Компоненты Windows -> Службы удаленных рабочих столов -> Клиент подключения к удаленному рабочему столу (Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client). Параметры “Запретить сохранение паролей” (Do not allow passwords to be saved) и Prompt for credentials on the client computer должны быть не заданы или отключены. Также убедитесь, что он отключен в результирующей политике на вашем компьютере (html отчет с применёнными настройками доменных политик можно сформировать с помощью gpresult);
4. Удалите все сохраненные пароли в менеджере паролей Windows (Credential Manager). Наберите
   control userpasswords2
   и в окне “Учетные записи пользователей” перейдите на вкладку “Дополнительно” и нажмите на кнопку “Управление паролями”; В открывшемся окне выберите “Учетные данные Windows”. Найдите и удалите все сохраненные RDP пароли (начинаются с TERMSRV/…).

   Из этого окна вы можете самостоятельно добавить учетных данные для RDP подключений. Обратите внимание, что имя удаленного RDP сервера (компьютера) нужно указывать в формате TERMSRV\server_name1. При очистке истории RDP подключений на компьютере, не забывайте удалять сохраненные пароли.

5. Вход с сохраненным паролем также не будет работать, если удаленный RDP сервер давно не обновлялся и при подключении к нему появляется ошибка CredSSP encryption oracle remediation.

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

Политика проверки подлинности сервере не допускает подключение сохраненными учетными данными

При подключении к RDP хосту или ферме RDS с помощью сохраненного пароля может появится ошибка:

Windows Security
Your credentials did not work
The server’s authentication policy does not allow connection requests using saved credentials. Please enter new credentials.

Политика проверки подлинности на сервере не допускает запросы на подключение с использованием сохраненных учетных данных.

В этом случае на удаленном сервере нужно отключить параметр “Always prompt for password upon connection” в разделе Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security.

Если эта политика включена, RDP хост всегда запрашивает у клиента пароль для подключения.

Credential Guard в Защитнике Windows не разрешает использовать сохраненные учетные данные

После обновления до Windows 11 22H2 пользователи стали жаловаться, что теперь они не могут использовать сохраненные пароли для RDP подключений:

Windows Security: Your credentials did not work
Windows Defender Credential Guard does not allow using saved credentials. Please enter your credentials.

Credential Guard в Защитнике Windows не разрешает использовать сохраненные учетные данные.

Представленные еще в Windows 10 1607 компонент Windows Defender Remote Credential Guard должен защищать ваши учетные данные для RDP подключений. В обновлении 22H2 по умолчанию он разрешает использовать сохраненные учетные данные только при использовании Kerberos аутентификации на RDP хосте. Если нельзя использовать Kerberos (контроллер домена не доступен, или вы подключаетесь к хосту в рабочей группе), Remote Credential Guard блокирует аутентификацию с помощью NTLM.

Для решения этой проблемы придется отключить Credential Guard через реестр:

New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\LSA" -Name "LsaCfgFlags" -PropertyType "DWORD" -Value 0 -Force

У всех системных администраторов есть одна очень серьезная проблема – защита учетных данных через подключение к удаленному рабочему столу. Это связано с тем, что вредоносные программы могут проникать на любой другой компьютер через соединение с настольным компьютером и представлять потенциальную угрозу вашим данным. Вот почему ОС Windows высвечивает предупреждение «Убедитесь, что вы доверяете этому ПК, подключение к ненадежному компьютеру может нанести вред вашему ПК» при попытке подключения к удаленному рабочему столу. В этом посте мы увидим, как функция Remote Credential Guard , представленная в Windows 10 v1607 , может помочь защитить учетные данные удаленного рабочего стола в Windows 10 Enterprise. и Windows Server 2016 .

Удаленная проверка учетных данных в Windows 10

Эта функция предназначена для устранения угроз, прежде чем она перерастет в серьезную ситуацию. Он помогает защитить ваши учетные данные через подключение к удаленному рабочему столу, перенаправляя запросы Kerberos обратно на устройство, которое запрашивает подключение. Он также предоставляет возможности единой регистрации для сеансов удаленного рабочего стола.

В случае какого-либо несчастья, когда целевое устройство скомпрометировано, учетные данные пользователя не раскрываются, поскольку как целевые, так и производные учетные данные никогда не отправляются на целевое устройство.

Способ работы Remote Credential Guard очень похож на защиту, предлагаемую Credential Guard на локальном компьютере, за исключением того, что Credential Guard также защищает сохраненные учетные данные домена через диспетчер учетных данных.

Человек может использовать Remote Credential Guard следующими способами:

1. Поскольку учетные данные администратора являются привилегированными, они должны быть защищены. Используя Remote Credential Guard, вы можете быть уверены, что ваши учетные данные защищены, поскольку они не позволяют учетным данным проходить по сети на целевое устройство.
2. Сотрудники службы поддержки в вашей организации должны подключаться к присоединенным к домену устройствам, которые могут быть скомпрометированы. Благодаря Remote Credential Guard сотрудник службы поддержки может использовать RDP для подключения к целевому устройству, не подвергая риску свои учетные данные для вредоносных программ.

Требования к аппаратному и программному обеспечению

Чтобы обеспечить бесперебойную работу Remote Credential Guard, убедитесь, что выполнены следующие требования клиента и сервера Remote Desktop.

1. Клиент и сервер удаленного рабочего стола должны быть присоединены к домену Active Directory
2. Оба устройства должны быть либо присоединены к одному домену, либо сервер удаленного рабочего стола должен быть присоединен к домену с доверительными отношениями к домену клиентского устройства.
3. Аутентификация Kerberos должна быть включена.
4. Клиент удаленного рабочего стола должен работать не ниже Windows 10 версии 1607 или Windows Server 2016.
5. Приложение Remote Desktop Universal Windows Platform не поддерживает Remote Credential Guard, поэтому используйте классическое приложение Windows Remote Desktop.

Включить удаленную проверку учетных данных через реестр

Чтобы включить Remote Credential Guard на целевом устройстве, откройте редактор реестра и перейдите к следующему ключу:

HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA

Добавьте новое значение DWORD с именем DisableRestrictedAdmin . Установите значение этого параметра реестра в 0 , чтобы включить Remote Credential Guard.

Закройте редактор реестра.

Вы можете включить Remote Credential Guard, выполнив следующую команду с повышенным уровнем CMD:

 reg add HKLM \ SYSTEM \ CurrentControlSet \ Control \ Lsa/v DisableRestrictedAdmin/d 0/t REG_DWORD 

Включите Remote Credential Guard с помощью групповой политики

Можно использовать Remote Credential Guard на клиентском устройстве, установив групповую политику или используя параметр с подключением к удаленному рабочему столу.

В консоли управления групповой политикой выберите Конфигурация компьютера> Административные шаблоны> Система> Делегирование полномочий .

Теперь дважды щелкните Ограничить делегирование учетных данных удаленным серверам , чтобы открыть его окно «Свойства».

Теперь в поле Использовать следующий ограниченный режим выберите Требуется удаленная защита учетных данных. Другой параметр Режим ограниченного администрирования также присутствует. Его значение в том, что, когда Remote Credential Guard не может быть использован, он будет использовать режим Restricted Admin.

В любом случае, ни Remote Credential Guard, ни режим Restricted Admin не будут отправлять учетные данные в виде открытого текста на сервер удаленного рабочего стола.

Разрешить удаленную проверку учетных данных, выбрав параметр Предпочитать удаленную проверку учетных данных .

Нажмите кнопку ОК и выйдите из консоли управления групповой политикой.

Теперь из командной строки запустите gpupdate.exe/force , чтобы убедиться, что объект групповой политики применяется.

Используйте Remote Credential Guard с параметром для подключения к удаленному рабочему столу

Если вы не используете групповую политику в своей организации, вы можете добавить параметр remoteGuard при запуске подключения к удаленному рабочему столу, чтобы включить Remote Credential Guard для этого подключения.

mstsc.exe/remoteGuard

Что нужно учитывать при использовании Remote Credential Guard

1. Remote Credential Guard нельзя использовать для подключения к устройству, подключенному к Azure Active Directory.
2. Remote Desktop Credential Guard работает только с протоколом RDP.
3. Remote Credential Guard не включает в себя претензии устройства. Например, если вы пытаетесь получить доступ к файловому серверу с удаленного компьютера, а файловый сервер требует утверждения устройства, в доступе будет отказано.
4. Сервер и клиент должны пройти аутентификацию с использованием Kerberos.
5. Домены должны иметь доверительные отношения, либо клиент и сервер должны быть присоединены к одному домену.
6. Шлюз удаленного рабочего стола не совместим с Remote Credential Guard.
7. Учетные данные не передаются на целевое устройство. Однако целевое устройство по-прежнему получает билеты службы Kerberos самостоятельно.
8. Наконец, вы должны использовать учетные данные пользователя, который вошел в устройство. Использование сохраненных учетных данных или учетных данных, отличных от ваших, запрещено.

Вы можете прочитать больше об этом в Technet.