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

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

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

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

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

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

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

Вы столкнетесь с парой проблем: (что затрудняет выполнение запроса LDAP в командной строке для проверки) Возможно, вы захотите попросить администратора AD настроить его для вас

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

Используйте инструменты командной строки openldap, чтобы попытаться аутентифицироваться в ActiveDirectory в командной строке UNIX . «организационная единица» (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

Вариант, заслуживающий изучения может заключаться в использовании 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 в производстве. Ваши требования выглядят так:

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

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

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

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

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

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

• Пароль userPassword для OpenLDAP shadowAccount (наследственная 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: // поддержка. microsoft.com/kb/263991