Как узнать, какие пути AD пользователь AD сможет запрашивать через LDAP?
Как я могу узнать, какие пути AD пользователь сможет запрашивать через LDAP? .когда я подключаюсь к нашему серверу фиктивного контроллера AD в качестве тестового пользователя через Microsoft ADExplorer , я замечаю, что могу смотреть (как кажется) на всю структуру AD и иметь возможность редактировать любой другой объект в любой путь.
Есть ли где-нибудь в атрибутах этого тестового пользователя, где я могу увидеть, где указан этот доступ? Где-то в свойствах пользователя в пользовательском интерфейсе центра администрирования AD? По сути, я хочу ограничить его, чтобы они могли запрашивать только свою собственную базу (или несколько выбранных) OU s / каталогов при выполнении запросов LDAP или подключении через ADExplorer.
Когда я подключаюсь к контроллеру AD через ADExplorer, я могу просматривать все, включая пути, членом которых не является подключающийся пользователь (они являются только членами myorg.local / Users ) или включены в дочерний путь.
Базовая структура AD выглядит так ...
myorg.local (DC,DC)
...
testing (OU)
groups (OU)
...
users (OU)
testuser (CN)
...
Users (CN)
other1.local (DC,DC)
...
other2.local (DC,DC)
...
... но тестовый пользователь может читать все
Кроме того, есть ли способ запретить им подключение через ADEXplorer и аналогичные приложения?
Вот некоторые ответы, которые я видел примерно ...
По умолчанию - это доступ для чтения ко всему домену. Вы не можете запретить чтение OU, в котором находится пользователь, OU для любых других ресурсов, которые пользователь использует (скажем, компьютеров в отдельном OU), или любого из их родительских контейнеров.
Блокировать трафик AD, как известно, сложно. Лучше всего предотвратить запуск несанкционированных пользователей мошеннических приложений на устройствах, присоединенных к домену, а затем вернуться к {{ 1}}, чтобы гарантировать, что только авторизованные администраторы / опытные пользователи могут редактировать объекты AD - обычно путем делегирования.
Вот шаги, чтобы лишить их возможности читать конфиденциальные OU .
Я рекомендую создать тестовый домен. поиграться с этим перед реализацией в продукте, поскольку это может иметь серьезные последствия, если сделано неправильно.
Active Directory - это всего лишь каталог. LDAP ... буква D означает Dieectory. Он был разработан таким образом, многие службы и компоненты в AD, Windows или других решениях полагаются на это.
Несколько вариантов есть!
Самым простым может быть поддержание другого источника имени проекта для карты project-access-granting-group-name или использование сокращений для группы проектов, что было бы бессмысленно для всех, кто не входит в группу .
Другой вариант - использовать определенные атрибуты в этих группах, чтобы отслеживать их настоящее имя (аналогично первому варианту выше.Атрибуты, не используемые различными системами, гораздо проще заблокировать, чем целые аккаунты / группы / т. Д., Но это может повлечь за собой расширение схемы.
Ведение карты ваших групп для конкретных вещей организации, таких как проекты , предоставляет полезный набор данных, поэтому я бы предпочел первый вариант (еще один источник для сопоставления имен) согласен, но я не был в среде с этим ограничением, поэтому кто-то, кто может иметь больше информации об альтернативах
, уточнит этот ответ, когда вернется к этой проблеме и поработайте над этим