Запретить подключение к серверу локальных пользователей

[Vi-P]

Есть домен под 2000. В нём сервер (2003) с SQL и прикладным ПО (клиент-серверная архитектура). На пользовательских машинах, соответственно, клиентская часть приложения. Как сделать что бы пользователи не могли работать с СУБД-ным сервером если на своих машинах они вошли локально? Т.е. вошёл под доменной учёткой - можешь работать с прикладным ПО, вошёл локально - подключиться к серверу с ПО не сможешь.

[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, но не очень красиво с точки зрения пользователя и не для любых приложений (нужно тестировать).