🔍 Логирование сессий теневого копирования
Если у вас появится желание отслеживать данные, о подключениях с использованием теневого копирования, то вам необходимо на сервере куда производилось затемнение сеанса перейти в журнал:
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
Вот такая будет последовательность.
Событие ID 20508
Событие ID 20508: Предоставлено разрешение на теневой просмотр. Пользователь barboskin.g (идентификатор сеанса: 440) предоставил разрешение пользователю Сёмину Ивану
Событие ID 20503
Событие ID 20503: Запущен теневой просмотр сеанса. Просмотр пользователем (Иван Сёмин) на компьютере c-10-.root.pyatilistnik.org сеанса пользователя ROOT\barboskin.g (идентификатор сеанса: 440)
Событие ID 20504
Событие ID 20504 : Остановлен теневой просмотр сеанса. Просмотр пользователем (Семин Иван) на компьютере c-10.root.pyatilistnik.org сеанса пользователя ROOT\barboskin.g (идентификатор сеанса: 440)
Событие ID 20513
Событие ID 20513: Сбой теневого доступа к сеансу. Пользователю (Иван Сёмин) не удалось получить теневой доступ к сеансу пользователя Root\barboskin.g (идентификатор сеанса: 440) из-за настроек групповой политики.
Событие ID 20510
Событие ID 20510: Предоставлено разрешение на теневое управление. Пользователь ROOT\barboskin.g (идентификатор сеанса: 440) предоставил разрешение пользователю (Иван Сёмин)
Как разрешить обычном пользователям использовать теневое подключение
В рассмотренных выше примерах для использования теневого подключения к терминальным сессиям необходимы права локального администратора на RDS сервере. Однако можно разрешить использовать теневое (shadow) подключение для подключения к сессиям пользователей и простым пользователям (не давая им прав локального администратора на сервере).
К примеру, вы хотите разрешить членам группы AllowRDSShadow использовать теневое подключение к сессиям пользователей, выполните команду:
wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName=»RDP-Tcp») CALL AddAccount «corp\AllowRDSShadow»,2
В январе 2018 года после установки обновления KB4056898 () пользователи столкнулись, что в Windows Server 2012 R2 перестал работать теневой доступ. При попытке выполнить теневое подключение к чужой сессии появляется сообщение «Неопознанная ошибка» (в логах присутствует ошибка STATUS_BAD_IMPERSONATION_LEVEL). Аналогичная проблема возникала и на RDS ферме на базе Windows Server 2016.
Для решения проблемы нужно установить отдельные обновления:
- для Windows Server 2016 — KB4057142
(от 17 января 2018) - для Windows Server 2012 R2 — KB
4057401
(от 17 января 2018)
Решение проблемы
Ошибка вроде очевидная, что не включен RDP доступ, если бы это был рядовой сервер я бы понял, но тут служба удаленного доступа точно работала и была включена, так как на данный сервер так же распространялась групповая политика делающая, это автоматически, я проверил применение GPO, все было хорошо. Первым делом я полез смотреть логи Windows, это можно сделать классическим методом или через модный Windows Admin Center.
Журналы которые нас будут интересовать находятся в таких расположениях:
- Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
- Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
- Microsoft-Windows-TerminalServices-SessionBroker/Admin
- Microsoft-Windows-TerminalServices-SessionBroker/Operational
- Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
Строим алгоритм обычного пользователя работающего удаленно. Сотрудник подключается к VPN серверу, после успешного подключения, он запускает клиента удаленного рабочего стола и производит подключение к RDS ферме. Далее сотрудник проходит успешно аутентификацию, его логин и пароль принимается брокерами RDS, далее идет процесс подключения, который заканчивается представленной выше ошибкой.
Первое, что мне бросилось в глаза, это предупреждение с кодом ID 101:
ID 101 RemoteDesktopServices-RdpCoreTS: The network characteristics detection function has been disabled because of Reason Code: 2(Server Configuration).
Далее было такое предупреждение:
Событие с кодом ID 226: RDP_UDPLOSSY: An error was encountered when transitioning from UdpLossyStateSynRecv in response to UdpEventErrorHandshakeTO (error code 0x80040004).
Далее нужно посмотреть, как RDCB брокеры взаимодействовали с сессией пользователя. В журнале «Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational» я обнаружил событие с кодом ID 1149, в котором я вижу, что определенный пользователь был успешно аутентифицирован на RDS ферме, он получил некий IP адрес.
Remote Desktop Services: User authentication succeeded: User: vpn_user Domain: Root.PYATILISTNIK.ORG Source Network Address: 10.10.31.47
Далее я стал изучать информацию из журнала «Microsoft-Windows-TerminalServices-SessionBroker/Operational». Тут я так же обнаружил, что брокер успешно ответил и отправил пользователя на определенный RDSH хост. Тут есть событие с кодом ID 787.
Событие с кодом ID 787: Session for user ROOT\vpn_user successfully added to RD Connection Broker’s database. Target Name = term01.root.pyatilistnik.org Session ID = 18 Farm Name = TermRoot
За ним я видел событие с кодом ID 801, которое имело вот такое сообщение:
RD Connection Broker successfully processed the connection request for user ROOT\vpn_user. Redirection info: Target Name = TERM01 Target IP Address = 10.10.31.47 Target Netbios = TERM01 Target FQDN = term01.root.pyatilistnik.org Disconnected Session Found = 0x0
тут видно, что брокер даже смог обнаружить предыдущую сессию на данном терминале, о чем говорит строка Disconnected Session Found = 0x0
И вы увидите событие с кодом ID 800:
RD Connection Broker received connection request for user ROOT\vpn-user. Hints in the RDP file (TSV URL) = tsv://MS Terminal Services Plugin.1.TermRoot Initial Application = NULL Call came from Redirector Server = TERMRDCB.root.pyatilistnik.org Redirector is configured as Virtual machine redirector
тут видно, что определенный брокер успешно направил пользователя на определенную коллекцию.
Далее переходим в журнал «Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational» тут будет два события,об успешном общении RDS брокера и клиента.
Событие с кодом ID 1307: Remote Desktop Connection Broker Client successfully redirected the user ROOT\vpn-user to the endpoint term01.root.pyatilistnik.org. Ip Address of the end point = 10.10.31.47
Remote Desktop Connection Broker Client received request for redirection. User : ROOT\vpn-user RDP Client Version : 5
Исходя из данной информации я точно вижу, что брокер подключения все успешно обработал и перенаправил пользователя на хост RDSH.
#2 – Сброс сессии пользователя и завершение зависших процессов в RDS сессии
Сначала попробуем найти и принудительно сбросить сессию пользователя, который не может зайти на RDS сервер. В диспетчере задач, на вкладке Users найдите нужного пользователя и через контекстное меню кликаем “Log off”. В большинстве случаев, этого достаточно, но иногда в диспетчере задач вы можете обнаружить множество зависших сессий с именем “(4)” вместо имени пользователя. Как правило в зависшей сессии будет присутствовать 4 процесса:
- Client Server Runtime Process (csrss.exe)
- Desktop Windows Manager (dwm.exe)
- Windows Logon Application (winlogon.exe)
- Windows Logon User Interface
В первую очередь попробуйте завершить все зависшие сессии с (4) через диспетчер задач, как описано выше. Если это не поможет, то лучше всего перезагрузить сервер, но зачастую такой возможности нет, поэтому пробуем решить проблему без перезагрузки:
- Запустите командную строку с правами администратора и введите: Она покажет всех пользователей и их сессии на терминальном сервере. В выводе команды есть 3 интересующих нас столбца: SESSIONNAME, USERNAME и ID. Найдите пользователя (4) и соответствующий ему ID, в данном примере ID 2. Нам нужно завершить процесс csrss.exe который работает под этой сессией, сначала найдем его.
- В командной строке введите: Команда выведет все процессы, которые запущены в этой сессии. Нам нужно найти процесс csrss.exe и соответствующий ему PID. В моём случае PID будет 5140. Нам нужно завершить этот процесс.
- Сверимся по диспетчеру задач. Откройте диспетчер задач, перейдите на вкладку Details и найдите нужный вам PID и процесс.Если нужный вам PID соответствует процессу csrss.exe, то завершите процесс через контекстное меню и End task, либо через командную строку:
Это нужно проделать с каждым пользователем “(4)”, если их несколько.
Утилита для человеческого shadow подключения неадмина к RDP сессиям пользователей в WinServer 2012R2
Проблема в период карантинной работы предприятия стала следующей: действительно нужно минимизировать количество посещений кабинетов специалистами, обслуживающими и консультирующими по прикладному ПО, да и сказать откровенно, пользователи частенько злоупотребляют помощью специалистов не желая вникать в сам вопрос, мол «придут — помогут — сделают, а я пока покурю/попью кофе и т.п.». Консультация по телефону при совместном доступе к серверу эффективнее, если просматривать удаленный экран.
Уже после «изобретения» нашего велосипеда подвернулась вменяемая информация на тему статьи: RDS Shadow – теневое подключение к RDP сессиям пользователей в Windows Server 2012 R2 или Режим shadow непривилегированного пользователя в windows server или Делегируем управление RDP-сеансами. Все они подразумевают применение консоли, даже с элементами простого диалога.
Вся изложенная ниже информация предназначена для тех, кто нормально переносит ненормальные извращения для получения нужного результата, изобретая ненужные способы. Чтобы «не тянуть кота за хвост», начну с последнего: велосипед работает у обычного пользователя с помощью утилиты AdmiLink, за что ее автору и спасибо.
I. Консоль и shadow RDP.
Так как использование с админскими правами консоли Server Manager -> QuickSessionCollection -> щелкнув по сессии интересующего пользователя, выбрав в контекстном меню Shadow (Теневая копия) для персонала, инструктирующего по работе с ПО, — не вариант, был рассмотрен другой «деревянный» способ, а именно:
1. Узнаем RDP id сессии:
Причем «| findstr Administrator» было удобно только когда ты знаешь, что именно Administrator тебе нужен, либо использовать только первую часть для лицезрения всех залогинившихся на сервере.
2. Подключаемся к этой сессии, при условии что в доменных групповых политиках параметр «Устанавливает правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов» выбран параметр как минимум «Наблюдение за сеансом с разрешения пользователя» (подробнее):
Прошу обратить внимание что в списке будут только логины пользователей. Повторюсь что без админских прав вы получите следующее:
Повторюсь что без админских прав вы получите следующее:
Но для предварительной отладки программы, о которой пойдет речь, я использовал учетку с правами администратора.
II. Программа
Итак постановка задачи: создание некого простого графического интерфейса для подключения к теневому сенсу пользователя с его разрешения, отправка сообщения пользователю. Среда программирования выбрана Lazarus.
1. Получаем полный доменный список пользователей «логин» — «полное имя» у админа, либо опять таки через консоль:
никто не запрещает даже так:
Скажу сразу, что именно у Lazarus оказалось проблема с обработкой этого файла, так как по умолчанию его кодировка UCS-2, поэтому пришлось просто преобразовать вручную в обычный UTF-8. В структуре файла много табуляций, вернее множество пробелов, которые было решено все-таки программно обработать, рано или поздно задачка с кодировкой будет решена, и файл будет программно обновляться.
Итак, в задумке папка, доступная для пользователей программы, например c:\test, в которой будет 2 файла: первый с login и fullname, второй с id_rdp и login пользователей. Далее эти данные обрабатываем как можем:).
А пока для ассоциирования со списком сессий переносим это (login и fullname) содержимое в массив:
Прошу извинения за «много кода», следующие пункты будут лаконичнее.
2. Аналогично методом из предыдущего пункта считываем результат обработки списка в элемент StringGrid, при этом приведу «значимый» кусок кода:
2.1 Получаем актуальный список RDP сессий в файл:
2.2 Обрабатываем файл (указан только значимые строки кода):
3. Непосредственно само подключение при клике на строку с пользователем и номером его сеанса:
4. Сделано еще пару украшательств типа сортировки по клику на radiobutton, и сообщения пользователю, либо всем пользователям.
Shadow Connection Options in the Windows RDP Client (mstsc.exe)
On Windows Server 2016/Windows 10, the built-in RDP client () has several special options that can be used to remotely shadow connect to an active RDP session of any user:
- /shadow:ID – connect to the user’s RDP session with the specified ID;
- /v:servername – you can specify the hostname or IP address of the remote RDP/RDS host. If not set, connections are made to local user sessions on the current host;
- /control – allows to interact with the user session (desktop). The administrator can control the user’s mouse, input data from the keyboard. If this parameter is not set, the user’s session view mode is used;
- /noConsentPrompt – the option allows the administrator to force the connection to any session without asking the user to confirm the connection;
- /prompt – allows to connect with other credentials. The user name and password are requested to connect to the remote computer.
Shadow sessions can be used to connect to user sessions on computers and servers in both an Active Directory domain and a workgroup. In addition, it is not necessary to have administrator privileges on the RDS host on this the user’s RDP session is running . Administrators can delegate RDS Shadowing permissions to any user account, even for non-admins (more on this below).
Метод №2 Удалить письма из Исходящих, которые находятся на утверждении
- Пройдите в «Исходящие
«. - Выберите письма с изображения, которые добавлены как Альбомы
. - Удалите их всех (сделайте копирование если необходимо).
- Теперь составьте новое письмо с текстом, который вы хотите отправить.
В этот раз, когда вы будете отправлять письмо, то вы сможете сделать без каких-либо осложнений.
В Windows 2012 R2 и Windows 8.1 Microsoft вернула функционал
Remote
Desktop
Shadowing
(теневого подключения). Напомним, что режим Shadow (теневой сеанс) – может использовать администратором для просмотра и управления существующей RDP сессией любого пользователя. Этот режим работы поддерживается практически с первых версий терминального сервера Microsoft и неожиданно был убран в Windows Server 2012 (связано с переносом стека rdp из режима ядра в пользовательский режим). Функционал RDS Shadow работает и в следующих версиях ОС: Windows Server 2016 / Windows 10.
Кроме того, у режима теневого подключения RDS Shadow и RDP клиента появился ряд новых интересных возможностей. Полный список параметров RDPклиента mstsc.exe, определяющих возможность удаленного теневого подключения к сессии конечного пользователя:
Mstsc.exe
]
/shadow:ID
– подключится к RDP сессии с указанным ID.
/v:servername
– имяRDP/RDS терминального сервера (если не задано, используется текущий).
/control
– возможность взаимодействия с сеансом пользователя (если не указано, используется режим просмотра сессии пользователя).
/noConsentPrompt
– не запрашивать у пользователя подтверждение на подключение к сессии.
/prompt –
используется для подключения под другими учетными данными. Запрашивается имя и пароль пользователя для подключения к удаленному компьютеру.
Ограничения теневых сеансов RDS в Windows 2012 R2
-
Подключаться к чужим сессиям может только администратор сервера. Делегировать эти права обычным пользователем нельзя
-
RDS
Shadow
не будет работать в сетях на базе рабочих групп
RDP Wrapper: разрешить несколько RDP сеансов в Windows
Библиотека RDP Wrapper проекта OpenSource позволяет включать конкурентные сеансы RDP в Windows 10 без замены файла systematermrv.dll. Эта программа работает как слой между Service Control Manager (SCM) и службами удаленных рабочих столов. RDPWrap позволяет не только включить поддержку нескольких одновременных сеансов RDP, но и реализовать сервер RDP в домашних выпусках Windows 10. RDP Wrapper не вносит никаких изменений в файл termrv.dll, просто загружая termrv с измененными параметрами.
Следовательно, RDPWrap будет работать даже при обновлении версии filetermrv.dll, что позволяет избежать опасений перед обновлениями Windows.
Перед установкой RDP Wrapper важно убедиться, что вы используете исходную (непропатченную) версию filetermsrv.dll. В противном случае RDP Wrapper может работать нестабильно или вообще не загружаться
Вы можете скачать RDP Wrapper из репозитория GitHub: https://github.com/binarymaster/rdpwrap/releases (последняя версия библиотеки RDP Wrapper – v1.6.2). Утилита не развивалась с 2017 года, но ее можно использовать во всех сборках Windows 10 и даже Windows 11.
Архив RDPWrap-v1.6.2.zip содержит несколько файлов:
- RDPWinst.exe – программа установки / удаления библиотеки RDP Wrapper;
- RDPConf.exe – утилита настройки оболочки RDP;
- RDPCheck.exe – Local RDP Checker – утилита для проверки доступа по RDP;
- install.bat, uninstall.bat, update.bat – командный файл для установки, удаления и обновления RDP Wrapper.
Для установки RDPWrap запустите файл
с правами администратора.
После завершения установки запустите RDPConfig.exe. Убедитесь, что в разделе «Диагностика» все элементы окрашены в зеленый цвет.
После завершения установки запустите RDPConfig.exe. Скорее всего, сразу после установки утилита покажет, что оболочка RDP запущена (Установлена, Выполняется, Прослушивается), но не работает
Обратите внимание на красные буквы. Сообщите, что эта версия Windows 10 (ver.10.0.19041.1320) не поддерживается ()
Дело в том, что для каждой версии Windows 10 обязательно должно быть описание в файле конфигурации rdpwrap.ini. В вашем файле конфигурации просто нет настроек для вашей сборки Windows 10.
Текущую версию файла rdpwrap.ini можно скачать здесь https://raw.githubusercontent.com/sebaxakerhtc/rdpwrap.ini/master/rdpwrap.ini
Вручную скопируйте содержимое этой страницы в файл «C: \ Program Files \ RDP Wrapper \ rdpwrap.ini». Или загрузите файл с помощью командлета Invoke-WebRequest PowerShell (сначала необходимо остановить службу удаленного рабочего стола):
Перезагрузите компьютер, запустите утилиту RDPConfig.exe. Убедитесь, что в разделе “Диагностика” все элементы зеленого цвета и отображается сообщение … На скриншоте ниже показано, что RDP Wrapper с этой конфигурацией также отлично работает в Windows 11.
Осталось перезагрузить компьютер. Попробуйте подключиться к своим компьютерам с разными сеансами RDP (используйте любой клиент RDP: mstsc.exe, rdcman и т.д.). Все заработало (также можно использовать сохраненные пароли RDP)! Ваша Windows 10 теперь позволяет двум (или более) удаленным пользователям одновременно подключаться через RDP.
Утилита RDPWrap поддерживается в выпусках Windows, поэтому вы можете создать сервер терминалов из любой клиентской версии Windows.
Также среди интересных особенностей RDP Wrapper можно выделить:
- Включить удаленный рабочий стол – включить доступ RDP
- Параметр «Скрыть пользователей на экране входа в систему» позволяет скрыть список пользователей на экране приветствия;
- Если параметр Один сеанс на пользователя отключен, несколько одновременных сеансов RDP будут разрешены под одной учетной записью (параметр реестра fSingleSessionPerUser = 0 установлен в ветке HKLM \ SYSTEM \ CurrentControlSet \ Control \ Terminal Server \ fSingleSessionPerUser).
- Порт RDP: вы можете изменить номер порта удаленного рабочего стола со стандартного TCP 3389 на любой другой;
- В разделе Session Shadowing Mode вы можете настроить теневое подключение к рабочему столу пользователей Windows 10.
Ограничения продолжительности сеансов RDP можно настроить через GPO.
Requirements
There are three main requirements that a Windows-based system must meet to allow you to use the feature.
The first and the most essential part is Remote Desktop Protocol version. It must be 8.1 or higher. The following versions of Microsoft Windows can be used on a server side and as a client as they have RDP 8.1 out of the box:
- Windows 8.1 and later;
- Windows Server 2012 R2 and later.
Windows 7, Windows Server 2008, Windows 8, Windows Server 2012 versions don’t support this feature on the server side.
If you want to use these versions as client the first thing you do is install additional updates to update Remote Desktop Protocol version up to 8.1. After that you are able to connect to any Windows version on a remote host that supports the RDS Shadowing feature. For details see https://support.microsoft.com/en-us/help/2830477/update-for-remoteapp-and-desktop-connections-feature-is-available-for.
The next but not less important thing is that a remote host must have RDP services running.
Thirdly, besides software and service requirements, some additional changes must be made to firewall rules. The Remote Desktop Services Shadowing feature doesn’t use 3389/TCP port (RDP), it uses 445/TCP port (SMB), instead, and ephemeral ports, also known as dynamic port range (RPC).
These changes can be done by adding new custom rules or by enabling the following built-in ones:
- The first rule is called , which allows to connect to port 445/TCP;
- The second one is . It only allows the binary to handle inbound connections on any local TCP port.
Note: the dynamic port range on Windows usually includes TCP ports from 49152 to 65535. The current value can be determined by issuing the following command:
Commands and described further also require the port 445/TCP to be open, otherwise you get the following error:
Note: in the situation when the shadowing connection seems to be successful, but a window with a shadowed session doesn’t pop up, check the firewall rules (dynamic ports must be open or Shadow rule is enabled).