Возможно ли для 389 Directory Server выполнять синхронизацию AD только для чтения?
Цель: сделать так, чтобы 389DirectoryServer (AKA Redhat/Centos/Fedora DS) извлекал информацию об учетной записи из AD, позволяя аутентифицировать как учетные записи AD, так и учетные записи 389-native с помощью 389DS, но синхронизировать их можно только в одном направлении, AD->389. Мы не хотим, чтобы случайные / злонамеренные изменения, сделанные на сервере 389, реплицировались обратно в AD. В идеале нам также не пришлось бы использовать эквивалентного пользователя DomainAdmin.
Вся существующая документация (большинство ссылок на http://www.centos.org/docs/5/html/CDS/ag/8.0/Windows_Sync-Configuring_Windows_Sync.html) делает его двусторонней синхронизацией. Я лаю не на том дереве?
** Изменить:** Я собирался не объяснять цель более высокого уровня, чтобы сохранить ее целенаправленность, фактический конечный результат для наших студентов (будет подготовлен в 389) и наших сотрудников (в AD), чтобы иметь возможность аутентификации против CAS для наших различных систем, в основном на основе Интернета.( http://www.jasig.org/cas). Не спрашивайте, почему мы так поступаем, это то, что мне было предложено поддержать. У меня есть ощущение, что есть более простой / более очевидный / более часто документированный способ, но я, конечно, не эксперт по межплатформенной аутентификации / авторизации (такие слова, как kerberos, RADIUS и / или PAM, приходят на ум, но я не точно знаю, что все это на самом деле, плюсы / минусы и т. д.... но так как мы уже используем RADIUS против нашей AD для Wireless 802.1x...)
3 ответа
Да, это возможно. Обновите свой 389 DS до версии 1.2.7 или выше
Он поставляется с подключаемым модулем синхронизации AD, который позволяет синхронизировать Windows только с AD на DS или только с DS на AD, а не только по умолчанию для двунаправленной синхронизации
См. http://directory.fedoraproject.org/docs/389ds/howto/howto-one-way-active-directory-sync.html
Мы укусили пулю и поместили все наши (20 тысяч плюс) учетные записи студентов в AD. Это сделало некоторые вещи намного проще. Служба "один каталог-правило-их-все" намного проще в поддержке клиентских сервисов. Мы должны были создать однонаправленную синхронизацию из нашего мастера идентификации (Banner) и создать совершенно отдельную страницу смены пароля для всех пользователей.
Это дало нам единый источник LDAP для всей аутентификации. Мы также используем CAS для SSO, и это, безусловно, облегчает задачу. Кроме того, на нашей странице аутентификации WLAN есть только один каталог для запроса, а также все бесчисленные веб-приложения, не относящиеся к CAS, которые мы открываем на веб-серверах департаментов.
Что произойдет, если вы настроите соглашение о синхронизации, используя учетную запись, которая имеет доступ только для чтения к AD?
Если это не сработает (в лучшем случае, это, вероятно, будет что-то вроде хака), то можете ли вы вместо этого использовать ссылки на базы данных 389DS или функцию рефералов?