Sonarqube 5,6 LTS и LDAP 2 плагин конфигурации Active Directory не работает

Question

Привет Я изо всех сил, чтобы получить работу Active Directory с SonarQube 5.6 LTS

Здесь Вы можете найти подробную информацию о конфигурации

sonar.security.realm = LDAP 
sonar.authenticator.downcase=false 
ldap.url=ldap://xxx.xxxxxx.com:3268 

ldap.user.baseDn=cn=users,dc=xxxxxx,dc=com 
ldap.user.request = (&(objectClass=user)(sAMAccountName={login})) 
ldap.user.realNameAttribute=cn 
ldap.user.emailAttribute=mail 

ldap.group.baseDn=cn=groups,dc=xxxxxx,dc=com 
ldap.group.request=(&(objectClass=group)(member={dn})) 
ldap.group.idAttribute = sAMAccountName 

ldap.realm = xxxxxx.com 
ldap.authentication = simple 
ldap.baseDn = dc=xxxxxx dc=com 
ldap.bindDn = xxxxxx\\xxxxxx 
ldap.bindPassword = xxxxxxx 

Я вижу Тест подключения LDAP Хорошо в sonarqube журналы

2017.01.16 19:00:30 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://xxx.xxxxxx.com:389, 
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
java.naming.security.principal=xxxxxx\xxxxxx, 
com.sun.jndi.ldap.connect.pool=true, 
java.naming.security.authentication=simple, 
java.naming.security.sasl.realm=xxxxxx.com, 
java.naming.referral=follow} 
2017.01.16 19:00:30 INFO web[o.s.p.l.LdapContextFactory] Test LDAP connection on ldap://xxx.xxxxxx.com:389: OK 

Однако, когда я пытаюсь войти в систему под своим именем и паролем LDAP, мне не позволено войти. Следующее сообщение наблюдается в журналах

2017.01.16 16:44:28 DEBUG web[o.s.p.l.LdapUsersProvider] Requesting details for user xxxxxx\xxxxx 
2017.01.16 16:44:28 DEBUG web[o.s.p.l.LdapSearch] Search: LdapSearch{baseDn=cn=users,dc=xxxxxx,dc=com, scope=subtree, 
request=(&(objectClass=user)(sAMAccountName={0})), 
parameters=[xxxxxx\xxxxxx], attributes=[mail, cn]} 
2017.01.16 16:44:28 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://xxx.xxxxxx.com:389, 
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
java.naming.security.principal=xxxxxx\xxxxxx, 
com.sun.jndi.ldap.connect.pool=true, 
java.naming.security.authentication=simple, 
java.naming.security.sasl.realm=xxxxxx.com, 
java.naming.referral=follow} 
2017.01.16 16:44:28 DEBUG web[o.s.p.l.LdapUsersProvider] User xxxxxx\xxxxxx not found in <default> 
2017.01.16 16:44:28 DEBUG web[http] POST /sessions/login | time=69ms 
2017.01.16 16:44:38 DEBUG web[o.s.p.l.LdapUsersProvider] Requesting details for user xxxxxx\xxxxxx 
2017.01.16 16:44:38 DEBUG web[o.s.p.l.LdapSearch] Search: LdapSearch{baseDn=cn=users,dc=xxxxxx,dc=com, scope=subtree, 
request=(&(objectClass=user)(sAMAccountName={0})), 
parameters=[xxxxxx\xxxxxx], attributes=[mail, cn]} 
2017.01.16 16:44:38 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://DC1.xxxxxx.com:389, 
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
java.naming.security.principal=xxxxxx\xxxxxx, 
com.sun.jndi.ldap.connect.pool=true, 
java.naming.security.authentication=simple, 
java.naming.security.sasl.realm=xxxxxx.com, 
java.naming.referral=follow} 
2017.01.16 16:44:38 DEBUG web[o.s.p.l.LdapUsersProvider] User xxxxxx\xxxxxx not found in <default> 
2017.01.16 16:44:38 DEBUG web[http] POST /sessions/login | time=55ms 

Я попытался следующие до сих пор:

1. Пробовал через порты: 3268/389
2. Пробовал ldapsearch из командной строки ldapsearch -H ldap://xxx.xxxxx.com:3268 dc=xxxxx,dc=com -D 'xxxxxx\xxxxxx' -W Но это также возвращает пусто

У меня есть только один пользователь admin, который настроен локально, и я могу войти в систему как администратор

То же имя пользователя и детали сервера работают хорошо, когда я настроил службы каталогов Active Directory на Дженкинс

Где я буду неправильно? Какие другие варианты я могу попробовать?

Answer 1

ldap.bindDn = ntdomain \ logonid - это, безусловно, плохая идея, потому что sonarqube (в соответствии с предоставленными вами трассировками) ищет запись пользователя AD с предикатом фильтра (sAMAccountName = ntdomain \ logonid). Вы должны использовать только имя sAMAccount для ldap.bindDn.

Необходимо указать различающееся имя пользователя (что-то вроде cn = ..., cn = users, dc = company, dc = tld) для привязки ldapsearch к AD, потому что нет сопоставления из sAMAccountName в dn, предоставленного с помощью инструмента ldapsearch.