» Ограничение одним терминальным сеансом (не баян)

ЗНАЮ ЧТО МИЛИОН РАЗ ПИСАЛОСЬ! НО!
Дело такое:
Есть офис с терминальным сервером и удалённые пользователи, которые работают через RDP в 1с. Пользователи в офисе тоже работают в 1с через RDP.
Задача:
Можно ли ограничить одних пользователей одним удаленным сеансом, а другим пользователям позволить создавать несколько подключений к серверу. Точнее пользователям подключающимся из удалённого офиса - ограничение одним сеансом. А офисным пользователям - неограниченное количество сеансов.

Решения:
1) ограничение всех одним сеансом понятно не подходит, потому как в терминале окно 1с на весь экран и соответственно один сеанс - одна база, а бухгалтерам надо одновременно 3-4 базы.
2) GroupPolicy - ограничение одним сеансом находится в "Конфигурации компьютера", а не в "Конфигурации пользователя", соответственно не применяется к серверу.
3) GroupPolicy - разрешать переподключение от исходного клиента - не выход можно 10 раз подключаться/отключаться пока не наткнешься на прежний сеанс.
4) Связка ограничение всех пользователей одним сеансом в оснастке "настройка служб терминалов" + GroupPolicy - ограничение несколькими сеансами в "Конфигурации компьютера" для офисных работников тоже не работает.
5) Завершение отключенного сеанса через 1 мин это конечно хорошо, но не всегда помогает - бывает что при разрыве связи сеанс не помечается как отключенный (ну не чует его сервер), а остается висеть как подключенный, причём так бывает чаще всего с удалёнными пользователями, с офисными всё более менее либо сброс, либо переподключаются.
6) Сидеть постоянно в офисе и сбрасывать сеансы я не могу, удалённо тоже не всегда. Но самая Ж это если это происходит в выходные...
7) В голове только одно - был недавно на Microsoft Technet 2007 там раздавали ШАМАНСКИЕ БУБНЫ ОТ MICROSOFT (вот те крест!!!) мне не достался - ОЧЕНЬ жалею...шаманы говорят помогает...а уж если бубен c печатью самого главного демона...

P.S. суть проблемы в том, что при переподключении удалённые пользователи не могут войти в 1с - каталог пользователя занят. Естественно удалённые пользователи подключаются через инет.

Цитата:

1) ограничение всех одним сеансом понятно не подходит, потому как в терминале окно 1с на весь экран и соответственно один сеанс - одна база, а бухгалтерам надо одновременно 3-4 базы.

Где такое написано? не ставить в environment в качесте среды 1с и запускать сколько угодно баз в 1 сеансе

Цитата:

Где такое написано? не ставить в environment в качесте среды 1с и запускать сколько угодно баз в 1 сеансе

Ну так нада. А то им волю дай они полезут куда не надо. Были прецеденты. А так нет кнопки "Пуск" или "Мой Компьютер" они и спокойны.
Они в своём то рабочем столе теряются, а уж в терминальном...только недавно отучил сохранять на рабочий стол в терминале. "А кде мой отчёт я его на рабочий стол сохраняла!"
Этот вариант я тоже рассматривал, но как крайнюю меру.

Цитата:

А то им волю дай они полезут куда не надо

как я понял бухгалтера только 1С юзают?
что мешает их добавить в локальную группу Very-very-very restricted users?
и пусть себе лезут куда хотят (читай - куда смогут, а это уже на совести того кто безопасность будет развешивать на права и файловую систему)

они даже на рабочий стол не смогут писать тогда, если грамотно разграничить их

На рабочий стол писать у меня удалённые пользователи не могут и вообще ничего не могут. Опять же если добавлю в Very-very-very restricted users бухгалтеров, то у них и на локальных машинах тоже самое будет Следовательно отдельную учётку заводить придётся.
Об этом тоже уже думал, даже уже в AD новый OU создал Офис_TS и GP начал настраивать.
Но может как-нибудь красиво можно всё сделать?

Цитата:

Опять же если добавлю в Very-very-very restricted users бухгалтеров, то у них и на локальных машинах тоже самое будет

господь с вами )))))))))))))))))
я не имел в виду GPO "Restricted Groups"
я имел в виду "идём на терминальном сервере в local users and groups, там в local groups создаём группу и вносим в неё всех юзеров"

и тогда членство в группе будет действовать ТОЛЬКО в пределах сервера, ибо группа локальная для TS, и AD о ней знать не знает.
равно как можно любого не-доменадмина сделать на сервере локальным администратором

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

Дело в том что народу то не много и контроллер AD он же и терминальный сервер

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

я рискую показаться грубым, но вы вообще представляете себе как домен устроен? ничего личного )))

Вы не поняли у меня один сервер выполняет функцию Контроллера AD и Сервера Терминала
1 сервер
12-15 рабочих станций
8 удалённых пользователей
Одного за глаза хватает - куплен месяц назад. А на контроллере AD нет локальных групп

Цитата:

Ну так нада. А то им волю дай они полезут куда не надо. Были прецеденты. А так нет кнопки "Пуск" или "Мой Компьютер" они и спокойны.

А если написать батник, в котором будет простое меню типа


Код: 1. База1
2. База2
3. БазаN
4. Выход

Введите нужный пункт меню и нажмите Enter:

а, да, сорри ночью не проникся ситуацией

Простите за некропостинг, тем не менее это решение может быть полезно другим гуглящим. Гуглите, да найдете то что искали.

Итак, столкнулся с такой же проблемой как и у ТС. Имеем:

а) сервер терминалов, в настройках которого снята галочка "Ограничить пользователя единственным сеансом" (или "Ограничить всех пользователей одиночными сеансами" как оно выглядит если зайти собственно в эти свойства узла сеансов удаленных рабочих столов)
б) сотрудники из офиса открывают несколько сеансов, будь то полноценные рабочие столы или запуск программ с помощью свойства "запускать программу при запуске" RDP-файла (актуально для пользователей под линуксом)
в) удаленные сотрудники должны работать только в одном сеансе. Продиктовано это может быть разными факторами. Например, ограниченное количество лицензий 1С 8 версии, или занятый каталог в 1С 7.7, мало ли зачем это может понадобиться.

В таком случае, если у удаленного пользователя тупо отсоединить сетевой шнурок (и закрыть RemoteApp/перезагрузить компьютер) - на сервере остается висеть сеанс этого пользователя.


Идея проста - при запуске конкретных пользователей запускать батник, который делает logoff всех пользователей с таким же именем.

Делаем вот такой простой батник:

Цитата:

@echo off
for /f "tokens=4 delims= " %%G in ('tasklist /FI "IMAGENAME eq tasklist.exe" /NH') do (SET RDP_SESSION=%%G)
for /f "tokens=3 delims= " %%G in ('query user %username%') do (IF NOT %%G == ID (IF NOT %%G == %RDP_SESSION% (logoff %%G)))

первая строка определяет ID текущей сессии на сервере терминалов, вторая строка получает выборку IDшников пользователей с таким же именем как и у текущего пользователя из-под которого грузится этот батник и делает logoff всем, кроме своего ID. При чем этот батник срабатывает из-под обычного пользователя.

Далее если у нас не RemoteApp - тупо кидаем батник в автозапуск в HKLM/Microsoft/Windows/CurrentVersion/Run и ограничиваем просто доступ к файлу, а нужным пользователям даем право на запуск. Группе администраторов, если нужно, можно выставить доп. правило с запретом на запуск, оно имеет как известно больший приоритет.

Если удаленные пользователи работают с RemoteApp, то тут чуть сложнее. Батник нужно кинуть в групповые политики в скрипты запускающиеся при входе в систему, и тут два варианта:

если у нас не поднят домен:
открываем mmc, добавляем оснастку "Редактор объектов групповой политики", и тут либо выбираем каждого пользователя по отдельности и добавляем батник в скрипты входа в систему, либо выбираем группу "Не администраторы" и так же добавляем в скрипты входа в систему, но ограничиваем доступ к батнику на уровне файловой системы

если поднят домен, то не нужно ограничивать доступ на уровне файловой системы, достаточно воспользоваться данной статьей http://www.windowsnetworking.com/articles-tutorials/windows-2003/Group-Policy-Security-Filtering.html, актуально и для Server 2008/2012

в принципе, если поднят домен, но RemoteApp не используется, также применяем Group Policy Security Filtering

вот статейка про скрипты автозапуска, которые отрабатывают даже в случае использования RemoteApp: https://technet.microsoft.com/en-us/library/cc731758.aspx?f=255&MSPPError=-2147217396


вот такой своеобразный костыль, но:
а) простой, делающийся за 15 минут которые сэкономят кучу времени на звонках от пользователей
б) 100% рабочий