Права доступа MS с пользователями Active Directory

Question

Можно ли настроить разрешения доступа с помощью пользователей Active Directory?
Редактировать : общая цель - разрешить некоторым пользователям просматривать определенные таблицы и запретить это разрешение для других пользователей. Мне интересно, если это можно сделать с помощью активных пользователей каталога.

Answer 1

Зависит от того, что вы подразумеваете под правами доступа. Доступ на уровне безопасности пользователя никоим образом не взаимодействует с Active Directory. ACC: часто задаваемые вопросы по безопасности Microsoft Access, доступные в Центре загрузок Рекомендуется перечитать этот FAQ несколько раз. Я должен признать, что никогда не понимал этого. Также см. ACC2000: обзор защиты базы данных Microsoft Access

Теперь, что вы можете сделать, это прочитать данные Active Directory для зарегистрированных пользователей и групп и тому подобное. Затем с помощью некоторых локальных таблиц, отображающих различные группы AD вместе с идентификатором имени входа для различных объектов и пунктов меню в Access, вы можете управлять доступом таким способом. Обратите внимание, что локальные таблицы могут быть взломаны опытным пользователем и т. Д. И т. П.

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

Answer 2

Я согласен с тем, что опубликовали Тони и Филипп. Я просто хочу добавить немного:

Если вам действительно нужна безопасность, то сервер Jet / ACE не собирается выполнять какое-либо существенное определение слова «безопасность». Jet ULS легко взломать, и это довольно легко для любого, даже с базовыми навыками программирования. Таким образом, если вы ищете форму БЕЗОПАСНОСТЬ ДАННЫХ, Филипп прав, что вам следует выбрать другой механизм базы данных.

Но если вы только хотите контролировать ACCESS в своем приложении, у вас есть три варианта:

1. поддерживает пару таблиц в вашей базе данных ваших пользователей и разрешения для каждого из объектов.

2. внедрить систему безопасности уровня пользователя Jet.

3. использовать пользователей / группы AD вместо Jet ULS.

Ни один из этих вариантов не является бесшовным.

И все они означают, что ваш интерфейс должен быть запрограммирован для решения проблем.

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

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

Я использовал Jet ULS для этой последней цели в течение многих лет, но никогда не был полностью доволен этим, поскольку сделать его управляемым пользователем не так просто. Интеграция с AD была бы хорошим выбором, но это означает, что любой, кто администрирует ваше приложение, должен иметь разрешение на управление пользователями AD. Возможно, это не то, на что ваш дружелюбный соседский системный администратор согласен.

С другой стороны, если вам в конечном итоге понадобится как внутренняя защита, так и управление внешним доступом, вы не сможете превзойти серверную часть SQL Server, используя безопасность Windows, для универсальных покупок через AD.

Answer 3

Судя по нескольким вопросам, которые вы опубликовали в последние дни в Access, для меня очевидно, что вам следует подумать о переключении ваших таблиц (не форм) с файла Access / mdb на сервер SQLExpress, где все эти проблемы безопасности могут быть легко управляемым. Увеличьте размер вашей базы данных, добавьте строку подключения в качестве общедоступной переменной в ваше клиентское приложение (или в XML-файл, локальную таблицу или что-либо еще, что может содержать строку, даже дополнительное свойство вашего файла доступа может справиться с задачей currentDb .createProperty) и перейти к реальной конфигурации клиент-сервер.