Логин Gitlabs ldap на сервере FreeIPA застрял в заданном цикле электронной почты

Я установил Gitlabs Community Edition v7.6.2 и пытаюсь использовать сервер FreeIPA в качестве решения ldap для управления пользователями. В принципе, похоже, что он работает нормально, и мне удается войти в систему с учетной записью, предоставленной моим сервером ldap. Однако, когда я вхожу в систему, я застреваю на странице редактирования пользователя. На этой странице я не могу изменить адрес электронной почты, но похоже, что Gitlabs ожидает достойную замену своему автоматически сгенерированному электронному письму.

Я создал пользователя bob на FreeIPA с почтовым адресом [email protected].

ldapsearch -x -h локальный хост uid=bob

dn: uid=bob,cn=users,cn=accounts,dc=testdomain,dc=com
displayName: bob bob
cn: bob bob
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: mepOriginEntry
loginShell: /bin/sh
sn: bob
gecos: bob bob
homeDirectory: /home/bob
krbPwdPolicyReference: cn=global_policy,cn=TESTDOMAIN.COM,cn=kerberos,dc=testdomain,dc=com
mail: [email protected] 
krbPrincipalName: [email protected]
givenName: bob
uid: bob
initials: bb
ipaUniqueID: d7c3d5bc-abb3-11e4-a1d6-080027079e3d
uidNumber: 497600001
gidNumber: 497600001
krbPasswordExpiration: 20150203144923Z
krbLastPwdChange: 20150203144923Z
krbExtraData:: AALz39BUcm9vdC9hZG1pbkBBTUJBUkkuQVBBQ0hFLk9SRwA=
mepManagedEntry: cn=bob,cn=groups,cn=accounts,dc=testdomain,dc=com

И отредактировал /etc/gitlab/gitlab.rb, чтобы обращаться к моему каталогу ldap без привязки пользователя:

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_host'] = 'ldap.testdomain.com'
gitlab_rails['ldap_port'] = 389
gitlab_rails['ldap_uid'] = 'uid'
gitlab_rails['ldap_method'] = 'plain'
gitlab_rails['ldap_allow_username_or_email_login'] = true
gitlab_rails['ldap_base'] = 'dc=testdomain,dc=com'

Если я попытаюсь войти в систему в этот момент, это вроде как сработает. Он принимает пароль для bob. Однако вместо обычной целевой страницы отображается страница настроек профиля с очень двусмысленным сообщением.

неоднозначный диалог электронной почты

Так что я должен изменить адрес электронной почты, единственное поле, полностью неизменяемое в этом диалоговом окне. Я предполагаю, что это связано с тем, что Gitlab полагается на ldap для предоставления почтового адреса. Мой ldap предоставляет это поле в соответствии с командой ldapsearch, однако Gitlab, похоже, не может это понять. Каждая ссылка, по которой я перехожу на этой странице, будет перенаправлять на эту страницу. По сути, я создал кирпич.

Чтобы быть полным, это в моем /var/log/gitlab/gitlab-rails/application.log:

# Logfile created on 2015-02-03 10:53:07 +0000 by logger.rb/44203
February 03, 2015 10:53: User "Administrator" ([email protected]) was created
February 03, 2015 15:22: User "bob bob" ([email protected]) was created
February 03, 2015 15:22: (OAuth) saving user [email protected] from login with extern_uid => uid=bob,cn=users,cn=compat,dc=testdomain,dc=com

Кто-нибудь знает, как это исправить? Очень признателен!


person Maarten Hoekstra    schedule 03.02.2015    source источник


Ответы (1)


Измените свой базовый dn («ldap_base» на языке gitlab) на «cn=accounts,dc=testdomain,dc=com»

Я думаю, что gitlab сбит с толку записью, возвращаемой по дереву совместимости - FreeIPA поддерживает предоставление пользователей и групп через схему RFC2307. Если вы используете $SUFFIX ('dc=testdomain,dc=com'), будут совпадать как основная, так и сравнительная записи, и gitlab выберет ту, которая будет возвращена первой, обычно это запись дерева совместимости. Запись Compat предназначена для сопоставления идентификаторов для старых клиентов UNIX (nss_ldap, Solaris и т.п.), поэтому она имеет только атрибуты RFC2307 и не имеет атрибута почты.

Кроме того, убедитесь, что вы используете аутентифицированную привязку. Поскольку FreeIPA 4.x предотвращает раскрытие информации через анонимные привязки для большинства атрибутов, «почта» является одним из атрибутов, доступных только для аутентифицированных привязок.

person abbra    schedule 16.02.2015
comment
Отлично. Это исправило мою проблему!! - person Trefex; 16.02.2015
comment
Да это вообще решение! Спасибо! - person Maarten Hoekstra; 18.02.2015
comment
Окончательно ! Огромное спасибо. - person Karl Forner; 30.06.2015
comment
Этот ответ привел меня на правильный путь, но теперь я застрял в поиске метода аутентификации, который работает с GitLab. Есть ли шанс, что этот ответ можно обновить, чтобы показать, как FreeIPA 4.x можно перенастроить, чтобы разрешить аутентификацию TLS или PLAIN? Кажется, что он хочет принять GSSAPI (Kerberos) только при тестировании с Apache Directory Studio, и кажется, что Gitlab не может выполнить привязку и просто возвращается к анонимному, который извлекает compat. - person Routhinator; 03.08.2015
comment
Ну, у меня это работает с cn=Directory Manager, но это плохо по очевидным причинам. Вопрос в том, почему все остальные пользователи получают ошибку = 32, такого объекта нет; всякий раз, когда они используются в качестве связующего DN. - person Routhinator; 04.08.2015
comment
PLAIN аутентификация требует LDAP STARTTLS или LDAPS. Возможно, у вас нет доверенного сертификата CA на вашей стороне gitlab? - person abbra; 04.08.2015