Проверка подлинности LDAP для SonarQube, похоже, загружается, но не разрешает вход через пользователя домена

Я пытаюсь настроить SonarQube (v4.1) с помощью модуля проверки подлинности LDAP (v1.4), и я просто не могу его аутентифицировать против пользователя моего домена. Моя конфигурация настроена следующим образом:

#########################
# LDAP configuration
#########################
# General Configuration
sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.downcase=true
sonar.authenticator.createUsers=true

ldap.authentication=simple
ldap.realm=mydomain.co.uk
ldap.bindDn=CN=USERNAME,OU=developers,DC=mydomain,DC=co,DC=uk
ldap.bindPassword=PASSWORD

# User Configuration
#ldap.user.baseDn=OU=developers,DC=mydomain,DC=co,DC=uk
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

# Group Configuration
ldap.group.baseDn=CN=Domain Users,CN=Users,DC=adastra,DC=co,DC=uk
ldap.group.request=(&(objectClass=group)(member={dn}))

и журнал выводит следующие сообщения, которые, похоже, говорят, что соединение LDAP работает нормально:

2014.01.20 16:12:32 INFO  [org.sonar.INFO]  Security realm: LDAP
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  Auto discovery mode
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  Detected server: ldap://dc02.mydomain.co.uk:389
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  User mapping: LdapUserMapping{baseDn=dc=mydomain,dc=co,dc=uk, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapSettingsManager]  Group mapping: LdapGroupMapping{baseDn=CN=Domain Users,CN=Users,DC=mydomain,DC=co,DC=uk, idAttribute=cn, requiredUserAttributes=[dn], request=(&(objectClass=group)(member={0}))}
2014.01.20 16:12:32 INFO  [o.s.p.l.LdapContextFactory]  Test LDAP connection on ldap://dc02.mydomain.co.uk:389: OK
2014.01.20 16:12:32 INFO  [org.sonar.INFO]  Security realm started

Но он просто не работает для моего пользователя, если я не пользуюсь локальным пользователем. При включении регистрации на обертке установите:

wrapper.console.loglevel=DEBUG

Я получаю следующую ошибку в журналах, которая на самом деле не очень помогает!:)

2014.01.20 17:07:10 ERROR [rails]  Error from external users provider: 

Ответ 1

Спасибо @aaron, который сумел указать мне в правильном направлении! Для моей проблемы это было проблемой с автоматическим открытием и с лесом, к которому я подключался. Согласно http://technet.microsoft.com/en-us/library/cc978012.aspx, вы должны использовать другой порт при подключении к лесу, чтобы затем он мог искать весь лес, а не тот домен, который вы для подключения (который, я полагаю, может оказаться неправильным в режиме автоматического обнаружения). В итоге конфигурация, которая работала для меня, была:

# General Configuration
ldap.realm=mydomain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://dc.mydomain.com:3268 

# User Configuration
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

На самом деле это довольно просто и не требует подключения учетной записи пользователя. Это означает, что он находится в режиме аутентификации SIMPLE (я не могу заставить его работать ни на что другое), но это нормально со мной, поскольку это внутренняя единственная система.

Ответ 2

Я просто работал над подключением плагина SonarQube LDAP к самому Active Directory. Поскольку каждая сеть настроена по-разному, вы часто не можете просто копировать и вставлять конфигурацию. Вот процесс, который я использовал для определения правильной конфигурации в моей компании:

Как указано в документации , эта конфигурация находится в файле:

SONARQUBE_HOME/CONF/sonar.properties

Следующая строка требуется как есть: sonar.security.realm=LDAP. Другие линии будут разными для каждой компании.

Мне было полезно проверить конфигурацию с помощью инструмента GUI. Я использовал Браузер Softerra LDAP (бесплатная версия LDAP-администратора только для чтения). В этом браузере LDAP

  • Создайте новый профиль. Кнопка
  • Lookup Servers поможет определить ldap.url. Вам нужно будет что-то сделать в строках ldap.url=ldap://dc01.mycompany.local:3268. ПРИМЕЧАНИЕ. Как указано в другом ответе, это может быть другой порт, чем тот, который указан на этом экране.
  • Базовый блок DN теперь можно оставить пустым.
  • Для проверки подлинности я просто выбрал текущего пользователя.
  • Фильтр также можно оставить пустым.
  • Нажмите "Готово" и отобразите элементы на верхнем уровне вашего AD.
  • F3 переключает панель быстрого поиска.
  • Поскольку вы не можете подключить SonarQube к AD с анонимной аутентификацией, вам нужно будет выбрать пользователя для службы SonarQube для подключения. Найдите этого пользователя в разделе "Быстрый поиск".
  • Вы должны найти запись CN (Common Name). Дважды щелкните это, чтобы открыть его.
  • Найдите поле differName и скопируйте его значение для использования в качестве ldap.bindDn
  • ldap.bindPassword должен быть этот пароль пользователя.
  • Этого должно быть достаточно, чтобы запустить SonarQube, но этого недостаточно, чтобы он мог искать пользователя, который пытается войти в ваш веб-портал SonarQube. Для этого сначала выберите образец человека (например, вы сами).
  • Сделайте еще один быстрый поиск для образца человека и откройте свою запись CN
  • Возьмите значение своего выдающегося имени, удалите "CN = {Их имя}" и произведите его в ldap.user.baseDn
  • Последний фрагмент, который вам нужно определить с помощью ldap.user.request. Предложение от документов SonarQube для использования с AD работало для меня: (&(objectClass=user)(sAMAccountName={login})). Позвольте мне объяснить, почему, если это не сработает для вас. "{Login}" будет заменен тем, что входит в состав SonarQube для имени пользователя, так что строка запроса (которая называется "Фильтр" в браузере LDAP) говорит, что поиск всех записей с любым объектным классом равен "пользователю" и их имя sAMAccountName равно тому, что напечатано в текстовом поле имени пользователя на вашем веб-портале SonarQube. Внутри информации об образце человека должно быть хотя бы одно поле, называемое "objectClass". Один из них должен иметь значение "пользователь". Также должно быть поле для имени sAMAccountName. Используйте это значение для текстового поля username на веб-портале SonarQube.
  • Чтобы проверить, должна ли эта строка запроса работать на вас, выполните поиск по каталогам в браузере LDAP (Ctrl + F3). Поместите свое значение ldap.user.baseDn в texbox "Поиск DN" и поместите свое значение ldap.user.request в фильтр texbox (обязательно замените "{login" вручную своим примерным именем пользователя). Он должен вернуть запись CN для образца.

Ответ 3

Я использую SonarQube 3.7.3, и я приложил свою конфигурацию, которая работает. Надеюсь, это было бы полезно.

# General Configuration
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://...
ldap.bindDn=user
ldap.bindPassword=password

# User Configuration
ldap.user.baseDn=ou=People,dc=company,dc=local
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

Ответ 4

Мой фикс

Я тщательно проанализировал свои настройки, даже до того, как использовал выходную строку файла журнала "Пользовательский сопоставление", чтобы настроить ручную команду ldapsearch и убедиться, что мой пользователь был правильно восстановлен.

По какой-то причине, задав этот параметр, я установил его для меня:

ldap.user.realNameAttribute=cn

Почему?

Этот атрибут должен быть факультативным и по умолчанию использоваться как cn, но он работает только для меня, если я укажу его вручную. Это может быть ошибка.

Отладка с помощью ldapsearch

ldapsearch позволяет вам напрямую обходить запрос LDAP приложения.

Я просмотрел файл журнала для этой строки:

INFO  web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=DC=my-ad,DC=example,DC=com, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}

И затем построили команду ldapsearch, например:

ldapsearch -D CN=myldapuser,CN=Users,DC=my-ad,DC=example,DC=com -W -h my-ad.example.com -b "DC=my-ad,DC=example,DC=com" "(&(objectClass=user)(sAMAccountName=myuser))"
  • -D указывает DN связывания, в основном имя пользователя входа для LDAP
  • -W означает, что ldapsearch предложит вам пароль
  • -h указывает URL-адрес LDAP
  • -b должен быть baseDN из строки журнала
  • Последний позиционный параметр - это значение запроса из строки файла журнала после замены {0} на реальное имя пользователя.

Если вы получите реальную информацию о пользователе, это означает, что ваши основные настройки правильные. Это намек на то, что что-то еще не так.

Ответ 6

Ни один из решений не работал у меня, но это:

# Configuration
sonar.realm=myreal.domain.com
sonar.security.realm=LDAP
sonar.authenticator.createUsers=true
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
ldap.url=ldap://myreal.domain.com:389

ldap.bindDn=cn=CNUser,dc=domain,dc=com
ldap.bindPassword=password

# User Configuration
ldap.user.baseDn=ou=people,dc=domain,dc=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

#logeo lo que pasa
wrapper.console.loglevel=DEBUG

Мой сервер Ldap нуждается в аутентификации, поэтому я не могу этого избежать. Если он не работает для вас, попробуйте не указывать ldap.user.request: все зависит от конфигурации LDAP-сервера вашей сети.

Ответ 7

Использование порта 3268 сделало трюк для меня. Вот моя конфигурация, которая работает с SonarQube 5.0.1 и Active Directory:

sonar.security.realm=LDAP
sonar.security.savePassword=true
sonar.security.updateUserAttributes=true
sonar.authenticator.createUsers=true

ldap.url=ldap://dc101.office.company.com:3268
ldap.bindDn=CN=Service Account,OU=Windows Service,OU=Accounts,OU=Resources,DC=office,DC=company,DC=com
ldap.bindPassword=PASSWORD

ldap.user.baseDn=DC=office,DC=company,DC=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail