Bredonosec> в таскманажоре на сессию другого юзера ткнуть просто?
Да. Правой кнопкой мыши на нужную сессию и выбрать "Удаленное управление", при подключении будет выбором хоткея выхода обратно в RDP-сеанс. По-умолчанию, хоткей Ctrl + * на цифровом блоке. Значение хоткей по-умолчанию меняется в реестре машины к которой осуществляется теневое подключение, за это отвечает ветка "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\TaskManager" или "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSADMIN", в ключах "ShadowHotkeyKey" и "ShadowHotkeyShift" указываются в dword порядковые номера записей в выпадающем списке доступных хоткей. Хоткей Ctrl + * действует и при подключении через shadow, причем для shadow нет возможности его изменить через параметры запуска и на 7-ке указанные ключи реестра на хоткей для shadow у меня не повлияли.
Bredonosec> переключит, или откроет в отдельном окне вторую?
Переключит, переведя RDP-сеанс из которого подключился в тип "Теневой", если в теневом подключении нажать хоткей, то вернется обратно в RDP-сеанс.
Bredonosec> по ссылкам из неё же. я всё это сделал,
Так другие тоже могут читать
С консольным shadow все еще забавнее, оказывается. Shadow может подключать любой терминальный сеанс к сессии пользователя, даже если запускать shadow из под терминальной сессии на другом компе в сети. Только shadow не умеет самостоятельно авторизоваться и использует авторизацию клиента сети Майкрософт, поэтому нужна возможность установления между пользовательской и терминальной сессией сетевого сеанса с авторизацией под логином пользователя, в чей сеанс нам надо подключиться, либо под записью имеющей на целевом компьютере права администратора. То есть, терминальный сеанс на клиентской машине вообще не требуется и можно подключаться в теневом режиме к XP/Viste/7-ке без мухлежа с DLL и RDP Wrapper Library, только в цепочку подключений потребуется добавить еще один комп, поскольку к локальному консольному сеансу shadow не умеет подключать сеанс с удаленного компьютера, а через терминальный сервер не создает сеанс на том же компьютере, с которого запускаешь терминальный клиент (по крайней мере по-умолчанию, но этот момент не копал). Несколько путано, но на примере будет понятнее, надеюсь.
Допустим, у нас есть еще три компа: Initiator, Proxy и Target. На Target в локальном сеансе сидит пользователь с логином User и нам надо подключиться к его сеансу в теневом режиме. Этот User имеет на Target права обычного пользователя и даже не входит в группу "Remote Desktop Users". На Proxy есть какой-то пользователь входящий в группу "Remote Desktop Users", админские права ему так же не требуются. Мы сидим на Initiator, пофиг какая у нас ОС, хоть Android на смартфоне, мы можем находиться за пределами основной сети и не видеть Target, но нам нужна возможность подключиться по RDP к Proxy (версия протокола роли не играет). Proxy должен видеть ресурсы SMB на Target, т.е. на Proxy и Target должна работать сеть Майкрософт с возможностью авторизации ("общий доступ к файлам и принтерам" и "доступ по паролю" в случае рабочей группы). Так же на Target должны быть открыты соответствующие порты, присутствовать сетевые ресурсы IPC$, ADMIN$ и C$ (или иная буква системного раздела), а так же, в некоторых случаях понадобится вспомогательная шара доступная пользователю User.
Шаг 1. Подключаемся по RDP с Initiator на Proxy и входим под какой-то учеткой. Учетку с правами админа, даже локального для Proxy, не рассматриваем - это скучно и небезопасно, поэтому возможны два варианта, но оба требуют знания пароля от User:
а) У нас домен, User доменный пользователь и мы вошли на Proxy под ним - это самый простой вариант, в этом случае с Proxy сразу доступны специальные ресурсы Target. Идем в консоль, набираем "qwinsta User /server:Target" и видим ID сеанса под которым сидит этот юзер на Target. Далее набираем "shadow ID /server:Target" и подключаемся к этому сеансу в теневом режиме. Выходим по хоткей.
б) У нас рабочая группа, либо нам не хочется авторизоваться на Proxy под доменной учеткой и мы авторизуемся под локальным пользователем Proxy. Далее идем в Проводник (либо в консоли используем возможности команды "net") и пытаемся войти на Target в шару C$ (если User является админом на Target) или в отдельную шару с доступом для User. В поле авторизации вводим имя пользователя вместе с именем его компьютера (Target\User) или домена (Domain\User), в зависимости от принадлежности учетки и пароль. Если поставить галку "сохранить пароль", то можно будет попасть в засаду при попытке подключиться через Proxy к сеансу другого пользователя на Target и придется удалять пароль User из сохраненных через оснастку хранилища паролей. Далее аналогично: узнаем ID сеанса "qwinsta User /server:Target", подключаемся "shadow ID /server:Target", выходим по хоткей.
Если групповой политикой включен режим доступа не запрашивающий подтверждения на управление, то у пользователя на Target лишь быстро моргнет экран. В Диспетчере Задач не появится новых сеансов и если мы себя никак не проявим или подключаемся в режиме просмотра, то пользователь даже не узнает о нашем подключении. Узнать он сможет только если ему хватит прав на запуск оснастки "Общие файлы", где в списке открытых файлов будут записи типа "LSM_API_service", "Shadowpipe" и "TermSrv_API_service" под именем пользователя которым мы авторизовались на Proxy по SMB. Либо в tcpview из набора Sysinternals, там будет видно входящее подключение с Proxy на порт TCP 445 (microsoft-ds), а если у пользователя хватит прав, то и растущие показания счетчика пакетов у этого соединения.
В теории, подключение по RPC должно отличаться от RDP-подключения по загрузке процессора на Target и утилизации полосы от Target до Proxy, но я не смог увидеть разницы на виртуалках.