можно ли сделать авторизацию пользователя 1с срествами 1с, уже после входа в1с ?
(Простите за тафтологию)
и как?

А зачем все это?

Можно, а зачем?

Гена, авторизация - есть процесс получения доступа к системе. То есть ты предлагаешь получить доступ после получения доступа?

(3) да!

(3) Мы получаем доступ во время получения доступа, чтобы вы могли получить доступ, когда получаете доступ! ))

т.е. скажем нужно сменить пользователя , не завершая сеанс 1с

(2) а как?

(6) нельзя.
Только перезапустить сеанс

Объясню: 1-ый человек заходит с терминала(ТСД) по RDP и работает под своим интерфейсом и правами, потом другой чел, не завершая имеющийся сеанс RDP с этого же терминала, завершает работу первого пользователя и начинает работать со своими интерфейсом и правами.

но доступ на рабочий стол давать нельзя!

как вариант я думал может написать некий bat`ник, который запускает 1с при входе, но при закрытии 1с, надо чтобы сеанс RDP не заканчивался,а снова открывалась 1с со списком баз.
Может как то так сделать мона??

(9) А если не завершит, и потрет важные данные, а обвинят первого пользователя? Короче, задача дурацкая.

(9) проверни в винде такое потом от 1с требуй

Что тебе мешает завершить сеанс RDP при завершении сеанса 1с?

так задача  в том то и заключается, что ненадо(!) завершать сеанс RDP, но надо сменить пользователя 1с!

(13) так вот как?? ))

(9) Сервис - Временная блокировка и Alt+Shift+Tab
(13) runas?

для ТСД "Сервис - Временная блокировка и Alt+Shift+Tab" - не лучший вариант, тем более что рабочий стол там по факту загружается

*не загружается

(15) (16) Сначала объясни зачем.

(18) Переключение задач работает и при отключенном рабочем столе - нужны только две и более запущенных программы.

Механизм вторичной авторизации есть во всяких ресторанных прогах.

Самый простой способ - сделать самому в 1С модальное окно "Авторизация" и менять параметр сеанса ТекущийПользователь.
Интерфейс тоже можно установить программно, а RLS завязаны на параметр сеанса.

(9) Вход под общим пользователем/паролем. + дополнительная идентификация, которая будет менять ТекущегоПользователя (или как он там называется в данной конфигурации) - элемент справочника пользователь
+ доп протоколирование, т.к. журнал регистрации не поможет при разборе.
Но оно так сильно надо?

Сгенерируй сервером Ярлык запуска 1С через RDP и поставь всем пользователям на локальные машины (рабочего стола у них не будет, только окошко 1с)

(0) ну, теоретически, ты можешь:
1. В работающем сеансе 1С запустить еще одну 1С с определенным параметром, говорящем, от какого сеанса запущен новый + некий уникальный код. При этом можно вызывать диалог аутентификации, нарисованный вручную, со списком пользователей, взятым из текущей базы.
2. Во вновь открытой базе, когда авторизация произойдет, в некий регистр сведений записать информацию, что база от имени первого сеанса благополучно открыта и этот первый уникальный код
3. В первой базе проверять, что в регистре появилась нужная запись и убивать сеанс

Возможные проблемы:
В первой базе будут несохраненные данные и они будут похерены

(21, 22) да думал менять ПараметрыСеанса, Конфа у меня УТ 10.3, попробую пожалуй (24)....

запрашивать пароль при входе рдп