2016-09-14 4 views
0

Я уже перенес Jenkins для использования входа в систему LDAP и без проблем. Но когда я попытался перенести phabricator для использования LDAP, я получил «Имя пользователя или пароль неверны». каждый раз, и я уверен, что то же имя пользователя и пароль могут войти в Jenkins. Я использовал тот же OpenLDAP-сервер, и у LDAP есть только для чтения DN: cn = readonly, dc = my-company, dc = com. список конфигураций Phabricator ниже:Как настроить phabricator login использовать ldap?

Разрешить: "Разрешить Логин"
LDAP Hostname & Порт: точно то же самое с моей Дженкинс конфигурации
Base Distinguished Name: НУ = пользователя, dc = мой-компании, DC = COM (в то время как Дженкинс корень DN был DC = моя компания-DC = COM)
Поиск Атрибуты: пусто
Всегда Поиск: непроверенный
Anonymous Имя пользователя: сп = только для чтения, DC = моя компания-DC = COM (то же самое с Дженкинс менеджер DN)
Анонимный пароль: пароль (тот же с паролем Jenkins Manager)
Имя пользователя Атрибут: UID
REALNAME Атрибуты: пусто Версия
LDAP: 3

Это преградить мне два дня, есть то, что я пропустил?

Спасибо за ваш ответ ~

+0

Вы упоминаете, что мигрируете, я беру это, чтобы иметь в виду, что у вас уже есть несколько пользователей в Phabricator. Я предполагаю, что вы использовали тот же формат для имен пользователей Phabricator, как и для LDAP. Возможно, Phabricator видит существующего пользователя и проверяет пароль для этого пользователя. Вам нужно будет пройти процесс создания нового пользовательского процесса, чтобы Phabricator запросил LDAP и установил этот Auth. – CEPA

+0

О, я настроил новый фабрикатор для тестирования LDAP. У нового Phabricator нет ожиданий администратора. Я планирую мигрировать после теста. –

ответ

0

О, я с этим разберусь. У Phabricator есть другой механизм входа LDAP с Jenkins. Фабрикатор всегда связывает LDAP с DN и паролем пользователя (для подтверждения входа в систему), а затем осуществляет поиск самого DN пользователя. Ниже приводится комментарий в коде LDAP логин:

// This is unusual (since the bind succeeded) but we've seen it at least 
    // once in the wild, where the anonymous user is allowed to search but 
    // the credentialed user is not. 

    // If we don't have anonymous credentials, raise an explicit exception 
    // here since we'll fail a typehint if we don't return an array anyway 
    // and this is a more useful error. 

    // If we do have anonymous credentials, we'll rebind and try the search 
    // again below. Doing this automatically means things work correctly more 
    // often without requiring additional configuration. 

Таким образом, пользователи LDAP должны найти ACL, например:

olcAccess: {1}to * 
    by self write 
    by dn="cn=admin,dc=my-company,dc=com" write 
    by dn="cn=readonly,dc=my-company,dc=com" read 
    by users search 
    by * none 

у меня не было «пользователей поиска» вариант, поэтому сбой входа в систему ,