- Очистка истории RDP подключений в Windows
- Удаление журнала RDP подключений из реестра системы
- Скрипт очистки истории (логов) RDP подключений
- Как запретить Windows сохранять историю RDP подключений?
- Очистка Bitmap кэша RDP
- Удаление сохраненных RDP паролей
- Очистка RDP логов на сервере
- Allow log on through Remote Desktop Services
- Reference
- Possible values
- Best practices
- Location
- Default values
- Policy management
- Group Policy
- Security considerations
- Vulnerability
- Countermeasure
- Potential impact
Очистка истории RDP подключений в Windows
Встроенный Remote Desktop Connection (RDP) клиент Windows (mstsc.exe) при каждом успешном соединении с удаленным компьютером сохраняет в системе его имя (или ip адрес) и имя пользователя, под которым был выполнен вход. При следующем запуске клиент RDP предлагает пользователю выбрать одно из подключений, которыми он уже пользовался ранее. Пользователь может выбрать из списка имя удаленного RDP/RDS сервера, и клиент автоматически подставляет используемое ранее для входа имя пользователя.
Это удобно с точки зрения конечного пользователя, но не безопасно. Особенно, когда вы подключаетесь к своему RDP серверу с общедоступного или недоверенного компьютера.
Информация о всех RDP сессиях хранится индивидуально для каждого пользователя компьютера в реестре, т.е. обычный пользователь (не администратор) не сможет просмотреть историю удаленных подключений другого пользователя.
В этой статье мы покажем, где в Windows хранится история подключений к удаленным рабочим столам и сохраненные пароли, и каким образом можно эту историю очистить.
Удаление журнала RDP подключений из реестра системы
- Откройте редактор реестра regedit.exe и перейдите в ветку HKEY_CURRENT_USER\Software\Microsoft\TerminalServerClient;
- Внутри этого раздела нас интересуют две ветки: Default (хранит историю о 10 последних RDP подключениях) и Servers (содержит список всех RDP серверов и имен пользователей, используемых ранее для входа);
- Разверните ветку реестра HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default, в которой содержится список 10 адресов или имен удаленных компьютеров, которые использовались последними (MRU – Most Recently Used). Имя (IP адрес) удаленного сервера хранится в значении ключа MRU*. Чтобы очистить историю последних RDP-соединений, выделите все ключи с именами MRU0-MRU9, щелкните правой клавишей и выберите пункт Delete;
- Теперь разверните ветку HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers. В ней содержится список всех RDP подключений, которые использовались ранее под этим пользователем. Разверните ветку с именем (IP адресом) любого хоста. Обратите внимание на значение параметра UsernameHint (подсказка имени пользователя). В нем указано имя пользователя, использующееся для подключения к RDP/RDS хосту. Именно это имя пользователя будет подставлено в окно клиента mstsc.exe, когда вы в следующий раз попытаетесь подключится к этому хосту. Кроме того в переменной CertHash находится отпечаток RDP сертификата сервера (см. статью о настройке доверенных TLS/SSL сертфикатов для RDP);
- Чтобы очистить историю всех RDP-подключений и сохраненных имен пользователей нужно очистить содержимое ветки реестра Servers. Т.к. выделить все вложенные ветки не получится, проще всего удалить ветку Servers целиком, а затем пересоздать ее вручную;
- Кроме указанных выше параметров и веток реестра, вам необходимо удалить файл дефолтного RDP подключения Default.rdp. В этом файле хранится информацию о самом последнем RDP подключении. Файл является скрытым и находится в каталоге Documents (Документы);
- Windows также сохраняет историю RDP подключений в списках быстрого перехода (jump lists). Если вы наберете в поисковой строке Windows 10 mstsc , то в списке появится ранее использованные RDP подключения. Вы можете отключить ведение истории быстрого перехода с помощью dword параметра реестра Start_TrackDocs в ветке HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced , либо можно очистить списки Resent Items, удалив файлы в каталоге %AppData%\Microsoft\Windows\Recent\AutomaticDestinations .
Скрипт очистки истории (логов) RDP подключений
Выше мы показали, как вручную очистить историю RDP подключений в Windows. Однако делать это вручную (особенно на нескольких компьютерах) – занятие достаточно долгое. Поэтому мы предлагаем небольшой скрипт (bat-файл), который позволяет автоматически очистить историю подключений к удаленным рабочим столам.
Для автоматизации очистки истории RDP, данный скрипт можно поместить в автозагрузку, либо распространить его на компьютеры пользователей с помощью логоф скрипта групповой политики.
@echo off
reg delete «HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default» /va /f
reg delete «HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers» /f
reg add «HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers»
attrib -s -h %userprofile%\documents\Default.rdp
del %userprofile%\documents\Default.rdp
del /f /s /q /a %AppData%\Microsoft\Windows\Recent\AutomaticDestinations
Последовательно разберем все команды скрипта:
- Отключен вывод информации в консоль;
- Удаление всех параметров в ветке HKCU\Software\Microsoft\Terminal Server Client\Default (очистка списка последних 10 RDP соединений);
- Удаление ветки HKCU\Software\Microsoft\Terminal Server Client\Servers вместе с вложенными элементами (очистка списка всех RDP подключений и сохраненных имен пользователей);
- Пересоздаем ветку реестра Servers;
- Убираем атрибуты Скрытый и Системный у файла default.rdp в каталоге профиля текущего пользователя;
- Удаление файла default.rdp;
- Очистка Recent Items.
Вы можете скачать готовый скрипт тут: CleanRDPHistory.bat
Кроме того, можно очистить историю подключений RDP с помощью следующего PowerShell скрипта:
Get-ChildItem «HKCU:\Software\Microsoft\Terminal Server Client» -Recurse | Remove-ItemProperty -Name UsernameHint -Ea 0
Remove-Item -Path ‘HKCU:\Software\Microsoft\Terminal Server Client\servers’ -Recurse 2>&1 | Out-Null
Remove-ItemProperty -Path ‘HKCU:\Software\Microsoft\Terminal Server Client\Default’ ‘MR*’ 2>&1 | Out-Null
$docsfoldes = [environment]::getfolderpath(«mydocuments») + ‘\Default.rdp’
remove-item $docsfoldes -Force 2>&1 | Out-Null
Как запретить Windows сохранять историю RDP подключений?
Если вы хотите, чтобы Windows не сохраняла историю RDP подключений, нужно запретить запись в ветку реестра HKCU\Software\Microsoft\Terminal Server Client для всех аккаунтов, в том числе System. Сначала отключите наследование разрешений на указанную ветку (Permissions -> Advanced -> Disable inheritance). Затем измените ACL на ветку, выставив Deny галочку для пользователей (но, вы должны понимать, что это уже unsupported configuration…).
В результате mstsc просто не сможет записать информацию об RDP подключении в реестр.
Очистка Bitmap кэша RDP
В клиенте Remote Desktop Connection есть функционал кэширования изображений (persistent bitmap caching). Клиент RDP при подключении сохраняет редко изменяющиеся куски удаленого экрана в виде кэша растровых изображений. Благодаря этому клиент mstsc.exe загружает из локального кэша части экрана, которые не изменились с момента последней прорисовки. Этот механизм кэширования RDP уменьшает количество данных, передаваемых по сети.
RDP кэш представляет собой два типа файлов в каталоге %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache :
В этих файлах хранятся сырые растровые изображения RDP экрана в виде плиток 64×64 пикселя. С помощью простых PowerShell или Python скриптов (легко ищутся по запросу RDP Cached Bitmap Extractor) можно получить PNG файлы с кусками экрана рабочего стола и использовать их для получения конфиденциальной информации. Размер плиток мал, но достаточен для получения полезной информации для изучающего RDP кэш.
Вы можете запретить RDP клиенту сохранять изображение экрана в кэш, отключив опцию Persistent bitmap caching (Постоянное кэширование точечных рисунков) на вкладке Advanced.
В этом случае нужно очистить каталог RDP кэша или отключить опцию Bitmap Caching.
Удаление сохраненных RDP паролей
Если при установке удалённого RDP подключения, перед вводом пароля пользователь поставил галку Remember Me / Запомнить меня, то имя пользователя и пароль будут сохранены в системном менеджере паролей системы (Credential Manager). При следующем подключении к этому же компьютеру, RDP клиент автоматически использует сохранённый ранее пароль для авторизации на удаленном компьютере.
Вы можете удалить сохраненный пароль прямо из окна клиента mstsc.exe. Выберите в списке подключений тоже самое подключение, и нажмите на кнопку Delete. Далее подтвердите удаление сохраненного пароля.
Либо можно удалить сохраненный пароль непосредственно из менеджера паролей Windows. Перейдите в следующий раздел Панели Управления: Control Panel\User Accounts\Credential Manager. Выберите Manage Windows Credentials и в списке сохранённых паролей найдите имя компьютера (в формате TERMSRV/192.168.1.100 ). Разверните найденный элемент и нажмите на кнопку Remove.
В доменной среде вы можете запретить сохранение паролей для RDP подключений можно с помощью политики Network access: Do not allow storage of passwords and credentials for network authentication (см. статью).
Очистка RDP логов на сервере
Логи подключения так же ведутся на стороне RDP/RDS сервера. Вы можете найти информацию об RDP подключениях в логах Event Viewer:
- Security;
- Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-RemoteConnectionManager -> Operational;
- TerminalServices-LocalSessionManager -> Admin.
Allow log on through Remote Desktop Services
Applies to
Describes the best practices, location, values, policy management, and security considerations for the Allow log on through Remote Desktop Services security policy setting.
Reference
This policy setting determines which users or groups can access the logon screen of a remote device through a Remote Desktop Services connection. It is possible for a user to establish a Remote Desktop Services connection to a particular server but not be able to log on to the console of that same server.
Possible values
- User-defined list of accounts
- Not Defined
Best practices
- To control who can open a Remote Desktop Services connection and log on to the device, add users to or remove users from the Remote Desktop Users group.
Location
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Default values
By default, members of the Administrators group have this right on domain controllers, workstations, and servers. The Remote Desktops Users group also has this right on workstations and servers. The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
Server type or GPO | Default value |
---|---|
Default Domain Policy | Not Defined |
Default Domain Controller Policy | Not Defined |
Domain Controller Local Security Policy | Administrators |
Stand-Alone Server Default Settings | Administrators Remote Desktop Users |
Domain Controller Effective Default Settings | Administrators |
Member Server Effective Default Settings | Administrators Remote Desktop Users |
Client Computer Effective Default Settings | Administrators Remote Desktop Users |
Policy management
This section describes different features and tools available to help you manage this policy.
Group Policy
To use Remote Desktop Services to successfully log on to a remote device, the user or group must be a member of the Remote Desktop Users or Administrators group and be granted the Allow log on through Remote Desktop Services right. It is possible for a user to establish an Remote Desktop Services session to a particular server, but not be able to log on to the console of that same server.
To exclude users or groups, you can assign the Deny log on through Remote Desktop Services user right to those users or groups. However, be careful when you use this method because you could create conflicts for legitimate users or groups that have been allowed access through the Allow log on through Remote Desktop Services user right.
A restart of the device is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local computer at the next Group Policy update:
- Local policy settings
- Site policy settings
- Domain policy settings
- OU policy settings
Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
Vulnerability
Any account with the Allow log on through Remote Desktop Services user right can log on to the remote console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.
Countermeasure
For domain controllers, assign the Allow log on through Remote Desktop Services user right only to the Administrators group. For other server roles and devices, add the Remote Desktop Users group. For servers that have the Remote Desktop (RD) Session Host role service enabled and do not run in Application Server mode, ensure that only authorized IT personnel who must manage the computers remotely belong to these groups.
Caution:В В For RD Session Host servers that run in Application Server mode, ensure that only users who require access to the server have accounts that belong to the Remote Desktop Users group because this built-in group has this logon right by default.
Alternatively, you can assign the Deny log on through Remote Desktop Services user right to groups such as Account Operators, Server Operators, and Guests. However, be careful when you use this method because you could block access to legitimate administrators who also belong to a group that has the Deny log on through Remote Desktop Services user right.
Potential impact
Removal of the Allow log on through Remote Desktop Services user right from other groups (or membership changes in these default groups) could limit the abilities of users who perform specific administrative roles in your environment. You should confirm that delegated activities are not adversely affected.