Что я делаю...
Попытка внедрить единый вход для всех машин нашей организации, блогов, вики, CRM, HRM, инструментов управления проектами, SVN и т. Д. И т. Д.
У нас установлен и настроен OpenLDAP на нашем выделенном сервере под управлением CentOS. Я использовал phpLdapAdmin для добавления организационной структуры и информации о различных пользователях, клиентах, ресурсах.
Пример записи для пользователя ...
DN is :: cn = Билл Гейтс, ou = users, dc = example, dc = com
userid :: bill.gates
mail :: bill.gates@example.com
userpassword :: as2% $% 66789ds (некоторое загадочное значение md5)
Где я сейчас ...
OpenLDdap работает нормально. Тест привязки также прошел успешно.
Что я хочу сделать...
Выполните привязку с использованием пользователя с более высокими привилегиями, а затем выполните поиск пользователей по их введенному идентификатору пользователя или почте, которые немного отличаются от CN. Дело в том, что я хочу аутентифицировать пользователя по атрибуту, который не является частью RDN.
Где я застрял ...
Мои вопросы (Ну наконец то)
Меня больше всего беспокоит использование подхода, который можно легко заставить работать с большинством приложений. Есть много веб-приложений, программного обеспечения для настольных компьютеров и т. Д., Которые мы будем модифицировать во время нашей миссии единого входа!
Спасибо за чтение ... и заранее спасибо за помощь!
-Рахул
По первому вопросу:
Я работал с другой системой LDAP, которая позволяла «входить в систему» с различными пользовательскими атрибутами. Решением было сделать два подключения. Первое соединение, вероятно, анонимно связанное, запрашивает у LDAP предоставленную пользователем информацию, чтобы определить местонахождение RDN их пользовательского объекта. Второе соединение пытается выполнить привязку с паролем с обнаруженным RDN и предоставленным паролем. Это двухэтапный процесс, и он работает.
Хотя, если это приложение будет получать много логинов с предоставленными атрибутами, которые не являются самим RDN, будет хорошей идеей проиндексировать эти атрибуты. Это дело производительности.
Два:
OpenLDAP поддерживает LDAP-SSL, насколько я помню (TCP / 636), что может быть лучшим маршрутом, чем туннель HTTPS. По умолчанию привязки LDAP открыты, но есть расширения LDAP, которые позволяют использовать дополнительные методы. Active Directory позволяет, например, связывать NTLM LDAP, и я почти уверен, что LDAP в какой-то момент тоже был керберизирован. Я не знаю, какие методы поддерживает openLDAP.
Три:
У меня есть источники LDAP с атрибутами электронной почты в формате "firstname.lastname@org.edu". Что еще более рискованно, так это с атрибутами именования, и именно здесь мой опыт openLDAP терпит неудачу. Я не знаю что Это поддерживает это. Я знаю, что Active Directory допускает пробелы в атрибутах именования, а Novell eDirectory допускает и пробелы, и точки (хотя делать это не рекомендуется). Обычно атрибут именования - это идентификатор пользователя, а такие атрибуты, как givenName, surname, emailAddress, содержат специальные символы. Поскольку они не именуют атрибуты, у них нет таких же ограничений.
Боюсь, я недостаточно хорошо знаю OpenLDAP, чтобы помочь с этим конкретно, но мне интересно, есть ли в нем функция, аналогичная OpenDS функция сопоставления личности что вы могли бы использовать.
Идея состоит в том, что клиент может идентифицировать себя с помощью настраиваемого идентификатора, а затем отображение использует регулярное выражение, чтобы сопоставить его с любым другим атрибутом в записи пользователя. В OpenDS, похоже, используются параметры SASL, и поэтому, используя их инструменты, я могу предоставить такие параметры, как:
bin/ldapsearch --saslOption authid=u:dominic --saslOption mech=PLAIN [..]
Затем идентификатор аутентификации используется средством сопоставления идентификаторов, которое в данном случае соответствует атрибуту uid в моей пользовательской записи.
Надеюсь, это поможет!