sonarqube 5.6 и LDAP 2.0 не проходят аутентификацию

Я тестирую обновление до sonarqube 5.6, установил плагин ldap 2.0 и скопировал соответствующую конфигурацию в мою тестовую настройку 5.6.

Соответствующая конфигурация

sonar.security.realm=LDAP
ldap.url=ldaps://xxxx:636
ldap.bindDn=uid=xxxx,ou=xxxx,dc=xxxx,dc=xxxx
ldap.bindPassword=xxxx
ldap.user.baseDn=dc=xxxx,dc=com
ldap.user.request=(&(objectClass=person)(mail={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

У меня есть следующий набор в conf/sonar.properties

sonar.log.level=DEBUG

При запуске я вижу

2016.07.26 23:57:29 INFO  web[o.s.p.l.LdapContextFactory] Test LDAP connection on ldaps://xxxx:636: OK
2016.07.26 23:57:29 INFO  web[org.sonar.INFO] Security realm started

Если я пытаюсь войти в систему, я получаю сообщение «Аутентификация не удалась» на экране входа в систему. Файл журнала не говорит ничего, кроме

2016.07.26 23:57:47 DEBUG web[http] GET / | time=67ms
2016.07.26 23:57:47 DEBUG web[http] GET / | time=187ms
2016.07.26 23:57:47 DEBUG web[http] GET /sessions/new | time=89ms
2016.07.26 23:57:53 DEBUG web[http] POST /sessions/login | time=71ms

Та же конфигурация отлично работает с sonarqube 4.5.7 и ldap 1.4.

Приветствуются идеи о том, как исследовать дальше.


sonarqube ldap sonarqube-ops sonarqube5.6
person Matt    schedule 26.07.2016    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Скорее всего, вы столкнулись с известной проблемой SONAR-7770 — Аутентификация не удалась, если LDAP конфигурация была забыта во время обновления . Обратите внимание, что для этой проблемы было выпущено примечание об обновлении:

В частности, не забудьте скопировать связанный плагин SonarQube и связанную с ним конфигурацию в conf/sonar.properties (включая sonar.security.realm и sonar.security.localUsers, если они есть) в новый экземпляр SonarQube, иначе вы будете заблокированы. после миграции.

Поэтому важно, чтобы эта конфигурация LDAP сохранялась даже во время обновления. Если вы пропустили это, то самый простой путь вперед — повторить обновление с правильно настроенной конфигурацией, связанной с LDAP.

Контекст

Имейте в виду, что во время обновления SonarQube обновляет набор данных, а также сохраняет новую информацию в базе данных (на основе новых функций). Проблема в вашем случае заключалась бы в том, что обновление было выполнено с частичной конфигурацией (которая не устанавливала sonar.security.realm и sonar.security.localUsers), и SonarQube не мог определить, были ли пользователи локальными или нет, поэтому по умолчанию они рассматривались как локальные. Локальные пользователи аутентифицируются не внешними провайдерами аутентификации, а локально, что мы и видим в ваших журналах (и это явно не работает, потому что пароль находится на сервере LDAP, а не в базе данных SonarQube).

person Nicolas B. - SonarSource Team    schedule 27.07.2016
comment
Мне не приходило в голову, что это также применимо к новой установке, то есть что 5.6 позволяет вам использовать LDAP только с самого первого запуска, вы не можете добавить его позже. - person Matt; 27.07.2016
comment
@ Мэтт, я не совсем так сказал. Плагин LDAP должен быть там с самого первого раза, если вы используете существующую базу данных (уже используемую в предыдущей версии). В противном случае вы можете установить подключаемый модуль LDAP в любое время, но в этом случае пользователи, созданные до этого, будут аутентифицироваться локально. - person Nicolas B. - SonarSource Team; 27.07.2016
comment
Правильно я вижу. Однако этот переход от того, как объявляются локальные пользователи, кажется немного ненадежным. Я обнаружил, что пользователи, которые ранее были созданы локально, считаются пользователями LDAP при обновлении, поэтому их необходимо воссоздать после обновления. К счастью, у меня всего несколько таких пользователей. - person Matt; 28.07.2016
comment
Если вы хотите, чтобы некоторые пользователи сохранялись как локальные во время обновления, убедитесь, что их идентификатор пользователя установлен в sonar.security.localUsers во время обновления. Все эти вещи улучшены в серии 6.x с понятием «поставщик аутентификации», который должен быть прозрачным со страницы администрирования пользователей. - person Nicolas B. - SonarSource Team; 28.07.2016
comment
Я скопировал конфигурацию LDAP в 5.6.6, установил плагин LDAP и все равно столкнулся с этой проблемой. Я думаю, что моя ошибка заключалась в том, что наш старый экземпляр (5.1.2) использовал 1.4 плагина, и я скопировал 2.1 плагина в новую установку перед запуском сервера? В противном случае, не уверен, что я сделал неправильно. - person user944849; 31.03.2017

arrow_upward
3
arrow_downward

Я исправил это, вручную обновив таблицу базы данных users SonarQube, предполагая, что все остальные пользователи управляются LDAP и только admin является локальным пользователем:

UPDATE sonarqube_production.users SET user_local = 0, external_identity_provider = 'ldap' WHERE id != 'admin';
person Schakko    schedule 22.12.2016
comment
блин, использовал разработчика plsql и ругался за то, что он не работает. наконец переключился на sqlplus и выдал заявление о коммите. тупой я - person Shiva; 13.03.2018

arrow_upward
2
arrow_downward

Небольшое исправление запроса Шакко выше, он должен быть с login, а не с id:

UPDATE users SET user_local = 0, external_identity_provider = 'ldap' WHERE login != 'admin';
person Viacheslav    schedule 04.10.2017