В версии windows установленной на этом сервере не поддерживается теневой доступ пользователей

• 
  Вопрос задан
  
  15 окт. 2022
  

• 539 просмотров

Минуточку внимания

• Remove From My Forums

Все ответы

• похоже, или откатывать обновления до версии rdp 7.1, или обновлять версию ОС:

  https://support.microsoft.com/en-us/help/2592687

  Issue
  Windows 7 SP1 supports the Shadow command (Remote Control). This command can be used by an administrator to view or control an active session of another user. After RDP 8.0 is enabled on a computer that’s running Windows 7 SP1, an administrator
  user cannot use the Shadow command to view or control another user’s session.

  Resolution
  Administrators can use Remote Assistance or another product that provides similar capability to view or control another user’s session.

• как бы откатил RDP до версии 7.1

  lnk

  но shadow вообще исчез
  

  • Изменено
    korggrodno3
    28 марта 2017 г. 9:46

• Погодите:) Я думал, вы в режиме shadow хотите подключаться к windows 7 и написал для этого сценария, что если на ней rdp обновлен до 8 версии, то подключиться не получиться.

  К какой версии windows вы пытаетесь подключиться?

• lnk

  Для RDP версии 8.0 тоже самое shadow не доступен.

  Хочу подключиться к windows 7 sp1 

  lnk

• хм, тут мне кажется все просто:

  нужно rdp на windows7 обновить, чтоб появился shadow (на той, с которой осуществляется подключение), а на той, куда подключаетесь, наоборот, откатить до 7.1 — оно или заработает, или нет.

  и если не заработает, то воспользоваться предлагаемым решением kb microsoft:

  Resolution
  Administrators can use Remote Assistance or another product that provides similar capability to view or control another user’s session.

  Вообще, это все похоже на какие-то костыли и я бы сразу перешел к рекомендуемому решению:)

• В итоге выяснилось, что shadow работает на win7sp1 для случае когда RDP 7.1
  Но экспериментально установлено ряд особенностей.
  — команда подключения вместе привычного mstsc /shadow:2 выглядит shadow 2
  — Подключиться можно только из терминального сеанса к другому терминальному или консольному.  

  При попытке подключиться к сеансу с другого компьютера командой
  mstsc /shadow:2 /v:192.168.1.40 /noConsentPrompt
  получаем такую ошибку
  ошибка

• Столкнулся с точно такой же проблемой и ошибкой… Так и не удалось подключиться в Shadow с другого физического клиента на win7? 

  Быть может кто подскажет как параметр реестра AllowRemoteRPC  назначить через групповые политики ?

  • Изменено
    IwinstonI
    12 апреля 2021 г. 14:46

В.Н.> взял-таки себе такой монитор
В.Н.> ну так. прикольно. ярко только очень

Не угодишь вам.. Из отзывов по твоей ссылке:

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

А исключительно оценить твои извращенные пристрастия по поводу ориентации монитора?

Bod> Не угодишь вам.. Из отзывов по твоей ссылке:

ну уж хз. сейчас яркость поставил на тридцать процентов и мне норм.

GOGI> А исключительно оценить твои извращенные пристрастия по поводу ориентации монитора?

первый раз работаю с таким большим разрешением. прям дофига всего влезает на экран. непривычно.

В мониторе есть встроенные колонки. и датчик присутствия пользователя. Отходишь — монитор гаснет. и начинает усиленно экономить электричество. Фигово только, что и звук вырубается

пс.но если вместо себя оставить кружку, система не срабатывает.
ппс. но срабатывает жена — ты чего кружки за собой не убираешь?
блин косой с этой автоматизацией

вопрос возник.
Есть утиль под вынь. RDP Wrapper
Снимает ограничения обычных несерверных версий выни на только один сеанс в одно время. По дефолту можно настраивать до 15 сеансов, и, что самое главно, подключаться к активному сеансу удаленно, не выбивая локального юзера из него.
Условно «не-запретный», бо она всего навсего кидает на диск свою длл-ку и в реестре путь к терм.серверу переписывает на свою длл-ку вместо виндовой termsrv.dll
Собсно вопрос такой:
На машинвах вне домена — всё пашет отлично.
На машинах в домене — почему-то можно всё кроме того, что мне надо — подключения вдвоем к одному сеансу.
Можно сидеть под разными юзерами одновременно. Можно даже одному юзеру открыть несколько сеансов, если снять галку single session per user. Но вот вместе один сеанс — хрен. Выбрасывает локального при подключении удаленного хоть убейся веником.
Была мысль, что в политиках что-то накосячено, но сколько искал, ничего не нашел.
Куда тут еще можно копать?

ЗЫ всякие тимвьюеры-vnc-радмины и прочее нелегальное не надо предлагать, запрещено. remote assistance тоже нихрена не то, что нужно, бо не работает так, как мне надо. Интересует решение именно в рамках вопроса

e.m.> Наверняка эта та же MS’овская DLL, только или пропатченная по примеру DLL из беты или вообще родная из беты без каких-то изменений. Нарушение лицензионного соглашения
ну.. формально да.. но по факту я всё равно один буду юзать, мне просто важно, чтоб на том компе экран показывал в точности то же самое, что и я делаю удаленно, не выкидывая.

e.m.> Если DLL на базе MS’овской из беты, то она будет смотреть политику «Административные шаблоны» -> «Компоненты Windows» -> «Службы терминалов» -> «Ограничить пользователей службы терминалов одним удаленным сеансом»,
спасибо )
Вообще-то
Local PC policies -> admin templates -> windows components -> Remote desktop services -> RDP session host -> limit number of connections
Но всё равно не задано. Ни это, ни каких-либо слов о том, что нужно мне: удаленное подключение к той же активной сессии консоли. Теперь хоть уверен в том

>а если эта политика не задана, то смотрятся настройки службы терминалов.
копаю щас RDP session host config tool с настройкой limit monitors per session.. походу оснастку сначала надо установить…

Bredonosec> Вообще-то
По старой версии винды смотрел, другой нет сейчас под рукой.

Bredonosec> Ни это, ни каких-либо слов о том, что нужно мне: удаленное подключение к той же активной сессии консоли
А, так еще и Remote Desktop Shadowing требуется? Тогда хочется подробностей про ОС и как подключаешься.

В принципе, патченная DLL для этого не требуется на сравнительно новых виндах:

e.m.> А, так еще и Remote Desktop Shadowing требуется? Тогда хочется подробностей про ОС и как подключаешься.
В принципе, не «еще», а только она Я просто не знал этого термина )

e.m.> В принципе, патченная DLL для этого не требуется на сравнительно новых виндах:
e.m.> Теневое RDP подключение к рабочему столу пользователя в Windows 10 | Windows для системных администраторов
Спасибо за наводку, материал по виду то, что мне и надо, но!
Но при попытке отработать на 2 машинах с вин7 и в домене, даже несмотря на установку указанных обнов (на обе, несмотря на то,что они говорили, что уже установлены), и выставление в реестре RPC на 1 и термсервис на 2 (без спроса) — всё равно шиш. Тупо «имя компьютера неправильное».
Что по имени, что по ИПу. Пробовал еще два бэкслеша добавлять в начале — без разницы, реакция идентична.
При попытке qwinsta на тему вывода сессий — ошибка 1722.
Что им еще может не хватать тогда?

Проверил на 7-ке, обобщаю:

Использовать shadow-подключение к пользовательскому сеансу возможно двумя способами: локально и удаленно, при любом из них требуется задать разрешение на подключение к сеансу пользователя через реестр или групповые политики, иначе при попытке использовать shadow в доступе будет отказано.

Локальное использование shadow: зайти в отдельный сеанс на сервере, локально на консоли компьютера или удаленно по RDP-протоколу (версия RDP-протокола не важна) и уже внутри открытой сессии подключиться для управления к сессии другого пользователя через консольную команду shadow, либо через «Менеджер Задач» или RDC Manger. При включенном UAC потребуется запуск от администратора, но при подключении через «Менеджер Задач» достаточно сначала подтвердить запрос UAC включив «Отображать процессы всех пользователей» во вкладке «Процессы». Этот способ накладывает ограничения на ОС выступающую в роли сервера — она должна позволять держать активными минимум две сессии. XP/Vista/7/8 это не позволят без мухлежа (патч на DLL или замена на DLL из беты, либо использование RDP Wrapper Library — он не патчит, но все равно нарушает лицензионную политику и поддерживает минимум 7-ку).

Удаленное использование shadow: подключиться к серверу терминалов по RPC-протоколу, запустив терминального клиента с ключом shadow — это требует поддержки и от клиента, и от сервера. В Windows от 8.1 и выше терминальный сервер RPC-подключение поддерживает. На 7-ке и 2008/2008R2 терминальный сервер не поддерживает подключение по RPC, поэтому при попытке подключения через shadow к этим ОС терминальный клиент покажет сообщение «В версии Windows, установленной на этом сервере, не поддерживается теневой доступ пользователей», т.е. для них доступен только локальный способ, причем на 7-ке потребуется еще и мухлеж. Клиенты с поддержкой RPC есть для Windows от 7-ки и выше, для 7-ки требуется установить апдейты из KB2830477, в остальных поддержка имеется изначально. Поскольку соединение с сервером терминалов в режиме теневого доступа идет не по RDP, а по RPC, то требуется не только разрешить использование RPC сервером терминалов, присвоив значение dwоrd:00000001 ключу “AllоwRemotеRPС” в ветке реестра «HKLM\SYSTЕM\CurrеntCоntrоlSеt\Cоntrol\Tеrminal Sеrvеr\», но и убедиться в том, что сервер может принимать входящие соединения на порт RPC — это TCP 445, на десктопных системах с брэндмауэром Windows этот порт закрыт по-умолчанию. При попытке подключиться к серверу с закрытым RPC-портом RDP-клиент выдаст сообщение «Неправильное имя компьютера».

e.m.> Локальное использование shadow: зайти в отдельный сеанс на сервере, локально на консоли компьютера или удаленно по RDP-протоколу (версия RDP-протокола не важна) и уже внутри открытой сессии подключиться для управления к сессии другого пользователя через консольную команду shadow, либо через «Менеджер Задач» или RDC Manger.
ээ… не имею на чем опробовать (комп с семеркой рендерит видео, не хочу трогать), это в таскманажоре на сессию другого юзера ткнуть просто? И переключит, или откроет в отдельном окне вторую?

e.m.> требуется установить апдейты из KB2830477,
Так всё это было по ссылке, что ты дал, и по ссылкам из неё же. я всё это сделал, написал вчера.
Единственное, что порты 445 не проверил, проверю в понедельник.

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, но я не смог увидеть разницы на виртуалках.

e.m.> а) У нас домен, User доменный пользователь
открыл 445 порт — в итоге qwinsta session id сразу отдаёт, но при попытке shadow — ругается, что version of windows, running on this server, does not support user shadowing.
При этом wrapper поставлен, то есть, теоретически мультисеансы не должны вызывать проблем.

зы. А на вин10 в той же ситуации — unspecified error

Bredonosec> при попытке shadow — ругается
Это ругается терминальный клиент с ключом /shadow, или консольная команда shadow? Если первое, то для ОС ниже 8.1 теневой режим только через консольную команду работает.

Bredonosec> на вин10 в той же ситуации — unspecified error
У меня под рукой нет шаблона с 10-кой, поставлю и отпишу по результату.

e.m.> Это ругается терминальный клиент с ключом /shadow, или консольная команда shadow? Если первое, то для ОС ниже 8.1 теневой режим только через консольную команду работает.
я только через консоль вводом с руки делал

Хотя еще на той неделе видел в тексте файла .rdp параметр shadow, но не допетрил, что оно то, что мне нужно копать.

e.m.> У меня под рукой нет шаблона с 10-кой, поставлю и отпишу по результату.
мне беглый гугл на эту ошибку ничего вменяемого не дал — всё про 2012 и 16 сервера или вообще что-то несвязанное… или безответное..

Bredonosec> я только через консоль вводом с руки делал
Поставил последнюю 10-ку LTSC 1809 (RS5/October 2018 Update, билд 10.0.17763.107). Пробовал под SMBv1, возможно это повлияло на результаты, но разворачивать контроллер домена под актуальные версии времени сейчас нет.

В домене нормально работают консольные qwinsta/query и RDP с ключом /shadow. Консольный shadow не работает, выдавая ошибку удаленного управления с кодом 87 «Параметр задан неверно».

В рабочей группе консольный shadow не может найти указанный сеанс, а qwinsta/query ругаются на отсутствие прав доступа при удаленном подключении — финт с предварительной авторизацией по SMB с указанием логина/пароля уже не срабатывает. RDP с ключом /shadow работает, но что бы удаленно узнать ID нужного сеанса придется использовать psexec (запустив qwinsta/query на удаленном компьютере) или PowerShell.

Похоже, что в 10-ке (в целом или только в данном релизе — ХЗ) усилили фильтрацию прав. В принципе, отключение фильтрации ведет к снижению безопасности, поэтому с консольным shadow имеет смысл заморачиваться только для старых версий ОС, а при возможности лучше использовать теневое подключение с авторизацией через RDP.

решил потихоньку собрать себе компьютер. а то обидно — монитор есть, а всего остального ещё нет.
начал с самого доступного. купил себе винчестер

пс. хотя странно это фитюльку называть «винчестером». я ещё помню те олдскульные добрые времена, когда с винчестером было не страшно заходить ночью в темную подворотню

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

мне вот что крайне не нравится. я у всех этих коробейников спрашиваю — а как мы сможем убедиться, что вы не оставили незакрытых дверей, через которые вы сами и будете сливать всю нашу информацию?
а они такие — «а никак. Можете только полагаться на честное слово».

Это действительно так, и мы никак не можем защититься?
мне единственное, что приходит на ум, так это заказать потом аудит работы у сторонней организации.
но, черт побери, потом придётся учинять ещё одну проверку для проверки предыдущей проверки

как-то можно разорвать этот порочный круг, не разорив предприятие проверками?

Bredonosec> В общем, перед покупкой надо бы прочесть. (ток на работе линка осталась, дома в яндексе что-то не находит)

поздно. я уже купил этот винт