Назад | Перейти на главную страницу

Синхронизация Active Directory и OpenLDAP

Я копал дыры в Google, чтобы найти лучший способ синхронизировать базу данных пользователей между AD и OpenLDAP. Я хочу получить базу данных пользователей в AD, а затем распространить этих пользователей на OpenLDAP, чтобы эти пользователи могли получить доступ ко всем моим приложениям (электронная почта, vpn, файловый сервер, сервер печати, почти все приложения с открытым исходным кодом). Я хочу создать базу данных единого входа, чтобы все пользователи могли иметь одинаковые пароли для приложений на базе Windows и Linux. Я также хочу убедиться, что пароли обновляются двунаправленно. Буду признателен, если кто-нибудь поделится своим опытом о том, как это можно сделать. Спасибо!!

Я сделал это однажды для проекта - удачи! У вас есть административный доступ к серверу AD? вам это может понадобиться. Подружитесь со своим админом AD :-)

Не могли бы вы подробнее рассказать, о чем ваш проект?

Вопрос в том, нужны ли вам просто ваши пользователи / приложения для аутентификации в ActiveDirectory или LDAP, или вам нужно, чтобы ваши приложения получали доступ к данным, хранящимся в ActiveDirectory, и, возможно, дополняли или изменяли записи.

Если вам просто нужно пройти аутентификацию, то, как указал Джастин, вам нужна либо анонимная, либо защищенная паролем (не так много дополнительного значения, IMHO) учетная запись привязки на сервере ActiveDirectory. Поговорите со своим администратором ActiveDirectory.

Если вы хотите использовать содержимое ActiveDirectory в качестве основы для ваших собственных пользовательских записей и, возможно, дополнить или изменить данные, вам может потребоваться настроить собственный сервер LDAP (потому что ваш ИТ-отдел может быть не в восторге от идеи, что вы изменять "свои" записи ...)

ActiveDirectory похож на LDAP и похож, но есть различия в основном в схеме.

Вы столкнетесь с парой проблем:

  • Схема и атрибуты AD немного отличаются от стандарта LDAP.
  • в частности, насколько я понимаю, схема AD в некоторой степени предопределена и фиксирована, потому что для всех приложений Micro $ oft требуется определенная схема ...
  • анонимный доступ может быть не настроен по умолчанию для AD, как для LDAP (что затрудняет выполнение запроса LDAP в командной строке для проверки) .Вы можете попросить администратора AD установить его для тебя
  • Ваш аутентифицированный пользователь, осуществляющий доступ к AD, может не иметь разрешения на просмотр всех записей AD и / или схемы.

  • Я помню, что нашел в AD тонны несовместимых записей, например неправильная организационная структура, записи людей перемешаны с записями о машинах, устройствах, программном обеспечении - тьфу !! и записи людей разбросаны по схеме (не все записи людей находятся только в одном поддереве, как можно было бы ожидать в схеме LDAP)

  • ... быть законченным ...

Если вам просто нужны люди или приложения для аутентификации в каталоге, то, возможно, не стоит проделывать все эти хлопоты - лучше просто использовать AD напрямую через привязанную учетную запись.

Используйте инструменты командной строки openldap, чтобы попытаться аутентифицироваться в ActiveDirectory в командной строке UNIX. Это поможет вам понять процесс и возвращаемые данные.

позвольте мне взглянуть на мои старые заметки по проекту, и я обновлю это

Я надеюсь, это поможет вам

для аутентификации с помощью OpenLDAP вам необходимо знать значения «отличительного имени» (dn) вашей организации, «организационной единицы» (ou), «общего имени» (cn) лица, выполняющего аутентификацию, и т. д. но я не могу дать вам здесь полное вступление ...

Лучше всего прочитать документацию по OpenLDAP здесь: http://www.openldap.org/doc/admin24/

лучше всего запустить "ldapsearch" в командной строке, чтобы проверить и проверить, можете ли вы связать / получить доступ к LDAP. http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.0-Release&format=html

или на сайте IBM: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahy%2Frzahyunderdn.htm

Пришлось решить ту же проблему для моей компании.

Будучи ориентированными на Linux, пароль необходимо было синхронизировать между:

  • OpenLDAP shadowAccount userPassword (устаревшая аутентификация PAM / LDAP)
  • OpenLDAP sambaSamAccount sambaLMPassword и sambaNTPassword (устаревшая аутентификация NTLM / Samba)
  • OpenLDAP krbPrincipalAux krbPrincipalKey (фактическая аутентификация PAM / MIT-Kerberos-V)
  • Microsoft Active Directory (вспомогательный домен Windows)

Теперь основная проблема заключается в следующем:

  • пароли (не должны быть!) криптографически хешируются; исходный пароль в открытом виде НЕ может быть восстановлен из того, что хранится в OpenLDAP или Microsoft Active Directory
  • это означает, что вы не можете синхронизироваться от одного бэкэнда хранилища к другому (EDIT: и каждый бэкэнд имеет свои собственные хэш-функции, ни одна из которых не совместима с другими бэкэндами)
  • это означает, что вы должны изменить все пароли синхронно на всех бэкэндах в то время, когда пользователь меняет свой пароль, это единственный раз, когда у вас есть пароль в открытом виде
  • зная, что у каждого бэкэнда есть свои непредвиденные обстоятельства и сложности, связанные с изменением пароля
  • это означает, что вы действительно должны позволить каждому бэкэнду иметь дело с изменением пароля «изначально»: пусть Kerberos создает соответствующие ключи (многие из них, в зависимости от того, какие алгоритмы поддерживает ваша область Kerberos), пусть Active Directory изменяет пароль своим собственным способом (что является не с открытым исходным кодом и непрозрачно изменяется, когда Microsoft считает это необходимым) и т. д.

Итак, я придумал это: https://github.com/cedric-dufour/upwdchg ; коротко поставил:

  • небезопасный доступный для пользователей интерфейс (клиент), позволяющий пользователям запрос Смена пароля
  • безопасный обработка бэкэнд (сервер) - с соответствующими административными привилегиями - который выполняет смену пароля на всех бэкэндах, используя свой собственный «родной» метод

Под «родным» методом я имею в виду:

  • Операция изменения пароля OpenLDAP (RFC 3062) для shadowAccount userPassword
  • Наложение OpenLDAP 'smbk5pwd' для sambaSamAccount sambaLMPassword и sambaNTPassword (НЕ для Kerberos; 'smbk5pwd' поддерживает только Heimdal Kerberos)
  • Сервер администрирования MIT Kerberos V и его операции "kadmin" и "password_change"
  • Microsoft задокументировал способ изменения AD "unicodePwd" в соответствии с http://support.microsoft.com/kb/263991

Стоит изучить вариант использования Active Directory для аутентификации и существующего OpenLDAP для авторизации:

http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication

Как указано в приведенной выше документации, вы можете делегировать проверку имени пользователя и пароля Kerberos. Фактически, приведенные примеры (см. 14.5.2) показывают, как настроить это для аутентификации в домене AD. Вам нужно будет настроить учетную запись пользователя в Active Directory, которая может связываться с контроллером домена, чтобы выполнять запрос LDAP. У этой учетной записи пользователя не должно быть разрешений на доступ к серверам Windows, а также она не должна входить в какие-либо конфиденциальные группы безопасности.

Надеюсь, это поможет.

Я делал аналогичный проект 2 года назад, и я был в аналогичном положении, не зная, с чего начать и как связать концы вместе.

Шаг 1. Определите, чего вы хотите достичь, и запишите это. Шаг 2: Посмотрите, реалистичны ли требования и могут ли быть выполнены в целом. Если нет, то чем вы готовы пожертвовать. (На это уходит много времени). Шаг 3: Выберите платформу для LDAP. в вашем случае у вас уже есть существующий. Шаг 4: Документирование и тестирование. Шаг 5: План перехода наиболее важен, поскольку не имеет значения, выполнили ли вы все, что хотели, но также и чтобы обеспечить плавный переход. В моем случае приходилось делать поэтапно.

Из ваших комментариев выше похоже, что у вас уже есть Openldap в производстве. Ваши требования выглядят так:

а) Разрешение пользователям использовать ту же политику паролей в AD.

б) Учетные записи пользователей для автоматического распространения на LDAP.

Ответ на а) Вы можете настроить модуль сквозной передачи PAM в LDAP для делегирования парольной аутентификации контроллеру домена через Kerberos. Таким образом, у вас не будет головной боли с сохранением пароля в двух местах. Я сделал это на 389-DS LDAP, и ссылки на документацию должно быть достаточно. Когда пользователь аутентифицируется, модуль PAM проверяет, существует ли учетная запись пользователя в LDAP, и если да, передает passwd в стек PAM с krb5.so для аутентификации. Ознакомьтесь с документацией 389-DS, которая также должна применяться здесь.

Ответ на б) Я нажал на все цилиндры, чтобы найти способ использовать готовый раствор, но ничего не подошло. Это потому, что вам нужно массировать схему для учетных записей и групп. Поэтому я с помощью коллеги написал сценарий на Perl для синхронизации пользователей и групп из AD в LDAP. Фрагмент кода f Вот.