[Delirium]

Скорее всего никак. Ведь пользователь имеет право работать с сетью, даже зайдя локально. Он сможет ввести доменные имя-пароль и продолжать работать. Встречный вопрос: а как это пользователи заходят локально? У них есть админские права при входе локально? И что, на каждой машине созданы учетки для локального входа? Мне кажется, проблему надо по другому как то решать.

[amel27]

Vi-P

Для этого приложение должно поддерживать Windows-авторизацию, при этом все права на SQL назначаются через доменные учетки. Соответственно, никого кроме явно назначенных пользователей на SQL не пустит.

Если приложение поддерживает только SQL-авторизацию (учетки заводятся на самом SQL) или у приложения своя система допуска, то мутить придется на станциях, варианты:

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

[Vi-P]

Встречный вопрос: а как это пользователи заходят локально? »

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

или у приложения своя система допуска »

Именно. Своя система аутентификации. А через сервис "доступ к компьютеру по сети" ничего не добиться?

запуск клиента БД через враппер (скриптовую оболочку), который проверяет режим входа и запускает само приложение »

Долгая песня. Надо выставлять техзадание разработчику на доработку.

[Delirium]

Долгая песня. Надо выставлять техзадание разработчику на доработку. »

Что то я не пойму, если приложение SQL-ное, то почему нельзя сделать SQL авторизацию и снять проблему? или необходимо использовать доменную авторизацию?

[wertyg]

что то непонятный вопрос! какая разница от имени какой учётки работатет удалённый пользователь если к серверу он подключаеться от имени или виндовой учётки(это я так понял не в нашем случае) или серверной учётки? немогу понять вопрос! например:

у нас в SQL(смешаная авторизация) есть несколько учёток\групп для отделов, каждый отдел подкл к серверу со своей учёткой и только туда куда ей можно. на сервере крутиться 1С. в ней дополнительная авторизация уже по персональному логину\паролю. чтобы пользователь не сделал он это сделает от своего имени(1С) и только там где можно данной учётке\группе(SQL) в не зависимости от прав на локальной машине.

не имеет значения какие права на локальной машине у пользователя, на сервере он получит лишь те права которые предусмотрены той или иной учёткой\группой. вот и фсё.)

з.ы. так что вопрос мне лично непонятен. какую цель преследует автор? зависимость локальных прав от возможности на СУБД ненаблюдаю.

з.з.ы. решение вопроса терминал - тут без вариантов.)

з.з.з.ы.

А через сервис "доступ к компьютеру по сети" ничего не добиться? »

- возможно это только к шарам, SQL может и пустить. и это не сервис а параметр безопасности. попробуй - отпишись.)

[amel27]

Долгая песня. Надо выставлять техзадание разработчику на доработку »

как раз наоборот - это несложно сделать самим если разработчики не идут навстречу, вот простой пример враппера на CMD:

Код:

If %UserDomain%==MyDomain Start "MyApp" /D"%ProgramFiles%\MyApp" "MyApp.exe"

Аналогичное можно сделать на WSH, AutoIT и любых других скриптовых языках... Другое дело, что это не является полноценным решением и его легко обойти, запустив приложение напрямую, но для рядовых пользователей этого часто хватает.

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