Блокировка Chrome в next screen

[ITTOKU]

Добрый день, столкнулся с таким вопросом.
Настроил 1 экран на подключение к удаленному терминальному серверу, второй экран настроен на запуск хрома с загрузкой страницы корпоративного портала.
Возможно ли блокировать экран с Хромом при блокировке основного соединения? Вопрос не прихоти ради тк на корпоративном портале оформляются тикеты в ИТ, отпуска, заявления на увольнения и тд.
Буду рад если подскажете вариант решения)

[aka]

Что такое "блокировать экран"?

[Barvinok]

Я вот тоже об этом думаю.
К примеру, я делаю пользователю профиль хрома, где по умолчанию загружается его почта, закладки и прочие личные страницы.
Значит каждый, кто включит компьютер, получит доступ к этим сведениям.
Вырисовывается необходимость блокировать целиком терминал, а не отдельные экраны.
Но как? Ещё один пароль? Или сразу заморочиться с ключём/токеном?

Но я поймал твою мысль с основным соединением.
Положим, пользователь уходя на обед заблокировал терминал сам, либо это случилось по таймауту.
Мы же можем для разблокировки использовать вход в некую основную терминальную сессию?
Пользователь пришёл с обеда, пошевелил мышкой. Экран включился, появилось окно приветствия терминально сервера.
И пока он не вошёл в эту сессию, переключение между экранами не работает.

С другой стороны, если на терминале вдруг приспичит поработать другому человеку - он либо не сможет войти под своим именем, либо не будет иметь доступ к браузеру...
Что ж теперь, привязывать профиль хрома к имени входа в RDP..?
Не выходит каменный цветок...

Я вижу одно решение - авторизация по единому паролю или аппаратному ключу/карте/RFID на сервере WTWare.
Т.е. загрузка будет происходить в два этапа:

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

В этом случае получается настоящий энтерпрайз, очень похожий на ActiveDirectory.
Вот.
В целом, мне эта мысль кажется привлекательной, поскольку люди зачастую одновременно работают на нескольких терминальных серверах - имеют на разных экранах опубликованные приложения через "shell=". Если ещё добавить LinPhone, Skype и 1С - получится внушительный набор учёток...

С RFID будет особенно круто. Как бесключевой доступ в хороших машинах. Ключ просто лежит в кармане. Пока ты рядом - всё включается/заводится.
Отошёл на три шага? Терминал заблокировался.

[aka]

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

[Гость]

Barvinok правильно описал что нужно, хоть мне и не нужны изыски в виде рфид.
Суть в том что в кроме запущен сервис в котором тоже есть авторизация. И было бы неплохо чтобы сеанс с хромом тоже блокировался.
Как пример, если на терминале нет активной сессии то хром заблокирован.

[aka]

Почему вы не хотите просто выключить питание? Экономия электроэнергии, "Час Земли", сохраним энергоресурсы для потомков и всё такое. Заодно ничего делать не надо.

[Гость]

Хех, вы предлагаете бухгалтерам ставить пилоты на стол? Или постоянно дергать микроюсб на малине?
Ни то ни другое к добру не доведет)

[aka]

Что плохого в пилоте на столе?

[Barvinok]

Дело в том, что при включении автоматически происходит вход в личный кабинет (если Хрому указан соответствующий профиль).
А не указывать профиль тоже нельзя, поскольку люди не хотят каждый раз вводить учётку.
Т.е. нужна блокировка и единый пароль на все экраны. Сиречь, блокировка терминала, а не отдельного сеанса.
Но привязка должна быть именно к пользователю, а не к терминалу, поскольку любой человек может сесть за любой компьютер.

[aka]

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

[Barvinok]

По условиям задачи мы используем локальный Хром WTWare.

[aka]

Логин с выбором из меню и пароль при загрузке терминала, кнопка "заблокировать" на всплывающем окошке рядом со свежедобавленным шатдауном, дополнительный флаг в параметр sleep=, указывающий блокировать, потом захочется снимать блокировку не тем юзером, который входил изначально, и мы придём к нескольким одновременным сеансам на втвари. И профили локального Хрома должны автомагически заливаться на сервер, чтоб на другом компьютере юзер увидел свою добавленную закладку

Не интересно. Лучше я h264 к RDP покопаю, вдруг поедет.

[Barvinok]

Ну да, я согласен - это далёкое светлое будущее.
А сейчас нам h264 как воздух...

Но, кстати.
Авторизация по ключу на сервере WTWare - это выход на очень привлекательный рынок: корпорации и госсектор.
WTWare имеет два очень важных преимущества - способна работать без локального носителя и (с некоторой доработкой) - без винды.
А значит - без соболей и прочего...

Я сейчас разрабатываю решение для медицинских учреждений.
С 1 января 2019 начнётся настоящее веселье (могу рассказать очень подробно).
Но если коротко и в сухом остатке - работать им придётся в браузере на очень защищённом компьютере.
Защищённый компьютер с виндой выкатывается под сотку.
Если WTWare сделать сертификат ФСБ - я готов заложить по 10 т.р. за лицензию.

[aka]

Но если коротко и в сухом остатке - работать им придётся в браузере на очень защищённом компьютере.

Не понимаю, при чем здесь втварь. Доверенная загрузка по сети без железки не реализуется. Да и не по сети тоже.

[Barvinok]

Я полагал, что железкой в данном случае будет USB-токен. Гораздо удобнее и дешевле.
Разве нет..?
У меня товарищ в управлении архива ЗАГС с моей подачи внедрял подобное решение на WTWare. Там пришлось AD поднимать, что бы сделать авторизацию по токену. Он с вами общался, может помните...

[aka]

Токен не помешает загрузить другое ПО на терминал. Смысл доверенной загрузки же в том, чтоб не позволять загружать другие операционные системы, кроме единственно верной.

[Barvinok]

Не интересно. Лучше я h264 к RDP покопаю, вдруг поедет.

Взлетает..?

[aka]

Нет В RDP оно едет, но куда потом это h264 сунуть малине чтоб аппаратно раскрыло пока не понял

[akaplenko]

Нет В RDP оно едет, но куда потом это h264 сунуть малине чтоб аппаратно раскрыло пока не понял

OpenMAX библиотека вроде какдля малины 264 аппаратно делает

[akaplenko]

https://github.com/jean343/RPI-GPU-rdpClient

Вот тут вроде как даже пример есть

[Barvinok]

aka, получается с H.264?
Всё же на малинке туповато работает. Люди жалуются...

[aka]

Не получается. Отложили пока H.264. Второй экран на zero делаем. Тормозить будет ещё сильнее