it-swarm.com.de

Die SonarQube LDAP-Authentifizierung scheint geladen zu sein, die Anmeldung über einen Domänenbenutzer ist jedoch nicht möglich

Ich habe versucht, SonarQube (v4.1) mit dem LDAP-Authentifizierungs-Plugin (v1.4) einzurichten, und ich kann es einfach nicht dazu bringen, sich bei meinem Domänenbenutzer zu authentifizieren. Meine Konfiguration ist wie folgt eingerichtet:

#########################
# 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}))

und das Protokoll gibt die folgenden Meldungen aus, die zu besagen scheinen, dass die LDAP-Verbindung einwandfrei funktioniert:

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

Es scheint jedoch nur dann für meinen Benutzer zu funktionieren, wenn ich einen lokalen Benutzer verwende. Wenn Sie die Protokollierung für den Wrapper aktivieren, indem Sie Folgendes festlegen:

wrapper.console.loglevel=DEBUG

Ich bekomme die folgende Fehlermeldung in den Protokollen, die nicht wirklich viel hilft! :)

2014.01.20 17:07:10 ERROR [Rails]  Error from external users provider: 
11
caveman_dick

Vielen Dank an @aaron, der es geschafft hat, mich in die richtige Richtung zu lenken! Für mein Problem war es ein Problem mit der automatischen Erkennung und der Gesamtstruktur, zu der ich eine Verbindung herstellte. Laut http://technet.Microsoft.com/en-us/library/cc978012.aspx sollten Sie beim Herstellen einer Verbindung mit einer Gesamtstruktur einen anderen Port verwenden, damit diese dann die gesamte Gesamtstruktur und nicht die Domäne durchsuchen kann, die Sie haben zufällig eine Verbindung herstellen (was vermutlich im Auto-Discovery-Modus nicht der richtige ist). Am Ende war die Konfiguration, die für mich funktionierte:

# 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

Das ist eigentlich ganz einfach und erfordert kein Benutzerkonto, um eine Verbindung herzustellen. Dies bedeutet, dass es sich im EINFACHEN Authentifizierungsmodus befindet (ich kann es anscheinend in keinem anderen Modus zum Funktionieren bringen), aber das ist für mich in Ordnung, da es sich um ein internes System handelt.

9
caveman_dick

Ich habe gerade versucht, das SonarQube-LDAP-Plugin für die Zusammenarbeit mit Active Directory selbst zu entwickeln. Da jedes Netzwerk anders eingerichtet ist, können Sie eine Konfiguration häufig nicht einfach kopieren und einfügen. So habe ich die richtige Konfiguration in meinem Unternehmen ermittelt:

Wie in der Dokumentation angegeben, befindet sich diese Konfiguration in der Datei:

SONARQUBE_HOME/conf/sonar.properties

Die folgende Zeile ist wie besehen erforderlich: sonar.security.realm=LDAP. Andere Zeilen sind je nach Unternehmen unterschiedlich.

Es war hilfreich für mich, die Konfiguration mit einem GUI-Tool zu testen. Ich habe den Softerra LDAP Browser (kostenlose Nur-Lese-Version von LDAP Administrator) verwendet. In diesem LDAP-Browser

  1. Erstelle ein neues Profil.
  2. Mithilfe der Schaltfläche "Server suchen" können Sie ldap.url ermitteln. Sie müssen mit etwas in der Art von ldap.url=ldap://dc01.mycompany.local:3268 enden. HINWEIS: Wie in einer anderen Antwort angegeben, muss dies möglicherweise ein anderer Anschluss sein als der in diesem Bildschirm aufgeführte.
  3. Das Feld Basis-DN kann vorerst leer gelassen werden.
  4. Zur Authentifizierung habe ich nur den aktuell angemeldeten Benutzer ausgewählt.
  5. Der Filter kann vorerst auch leer gelassen werden.
  6. Klicken Sie auf Fertig stellen, und es sollten Elemente auf der obersten Ebene Ihrer AD angezeigt werden.
  7. F3 schaltet die Schnellsuchleiste um.
  8. Da Sie SonarQube nicht mit anonymer Authentifizierung mit AD verbinden können, müssen Sie einen Benutzer für den SonarQube-Dienst auswählen, unter dem die Verbindung hergestellt werden soll. Suchen Sie diesen Benutzer in der Schnellsuche.
  9. Sie sollten einen CN-Eintrag (Common Name) finden. Doppelklicken Sie darauf, um es zu öffnen.
  10. Suchen Sie das Feld "distinguishedName" und kopieren Sie den Wert, der als ldap.bindDn verwendet werden soll.
  11. ldap.bindPassword sollte das Passwort des Benutzers sein.
  12. Dies sollte ausreichen, um SonarQube erfolgreich starten zu lassen. Es reicht jedoch NICHT aus, nach dem Benutzer zu suchen, der versucht, sich bei Ihrem SonarQube-Webportal anzumelden. Wählen Sie dazu zuerst eine Beispielperson (wie Sie selbst) aus.
  13. Führen Sie eine weitere Schnellsuche für die Beispielperson durch und öffnen Sie deren CN-Eintrag
  14. Nimm den Wert ihres DistinguishedName, entferne das Stück "CN = {Their Name}" und schreibe das in ldap.user.baseDn
  15. Das letzte Stück, das Sie mit dem ldap.user.request bestimmen müssen. Der Vorschlag aus den SonarQube-Dokumenten zur Verwendung mit AD hat für mich funktioniert: (&(objectClass=user)(sAMAccountName={login})). Lassen Sie mich erklären, warum, falls es bei Ihnen nicht funktioniert. Das "{login}" wird durch das ersetzt, was der SonarQube für seinen Benutzernamen eingibt, so dass die Anforderungszeichenfolge (die im LDAP-Browser als "Filter" bezeichnet wird) im Wesentlichen sagt, dass nach allen Einträgen mit einer objectClass gesucht werden soll, die "user" und "user" entspricht Ihr sAMAccountName entspricht der Eingabe in das Textfeld Benutzername in Ihrem SonarQube-Webportal. In den Informationen der Beispielperson sollte sich mindestens ein Feld mit dem Namen "objectClass" befinden. Eine davon sollte den Wert "user" haben. Es sollte auch ein Feld für sAMAccountName geben. Verwenden Sie diesen Wert für das Textfeld Benutzername in Ihrem SonarQube-Webportal.
  16. Um zu testen, ob diese Anforderungszeichenfolge für Sie geeignet ist, führen Sie eine Verzeichnissuche im LDAP-Browser durch (Strg + F3). Geben Sie Ihren Wert für "ldap.user.baseDn" in das Textfeld "Such-DN" und Ihren Wert für "ldap.user.request" in das Textfeld "Filter" ein (stellen Sie sicher, dass Sie "{login}" manuell durch Ihren Beispielbenutzernamen ersetzen). Es sollte den CN-Eintrag für die Beispielperson zurückgeben.
15
kevinpo

Ich verwende SonarQube 3.7.3 und habe meine Konfiguration angehängt, die funktioniert. Ich hoffe das wäre nützlich.

# 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
3
Eddú Meléndez

Mein Fix

Ich hatte meine Einstellungen sorgfältig überprüft, bis ich in der Ausgabezeile "User mapping" der Protokolldatei einen manuellen Befehl ldapsearch konfiguriert und sichergestellt hatte, dass mein Benutzer ordnungsgemäß abgerufen wurde.

Aus irgendeinem Grund hat die Angabe dieser Einstellung das Problem für mich behoben:

ldap.user.realNameAttribute=cn

Warum?

Dieses Attribut soll optional sein und standardmäßig ohnehin cn, funktioniert aber nur bei mir, wenn ich es manuell spezifiziere. Dies könnte ein Fehler sein.

Debuggen mit ldapsearch

mit ldapsearch können Sie die Anwendungsabfrage LDAP direkt umgehen.

Ich habe in der Protokolldatei nach folgender Zeile gesucht:

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}

Und dann baute ich einen ldapsearch Befehl wie:

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 gibt den Bind-DN ​​an, im Grunde genommen den Login-Benutzernamen für LDAP
  • -W bedeutet, dass Sie von ldapsearch zur Eingabe des Kennworts aufgefordert werden
  • -h gibt die LDAP-URL an
  • -b sollte baseDN aus der Protokolldatei sein
  • Der letzte Positionsparameter ist der Anforderungswert aus der Protokolldatei, nachdem {0} durch einen echten Benutzernamen ersetzt wurde.

Wenn Sie echte Benutzerinformationen zurückerhalten, sind Ihre Grundeinstellungen richtig. Dies ist ein Hinweis darauf, dass etwas anderes schief geht.

3
jtpereyda

http://blogs.msdn.com/b/visualstudioalm/archive/2015/11/13/support-for-active-directory-and-single-sign-on-sso-in-the-sonarqube-ldap- plugin.aspx

Mit der neuen Version 1.5 ist nur eine Zeile erforderlich:

LDAP-Konfiguration

sonar.security.realm = LDAP

2
Jirong Hu

Die Verwendung von Port 3268 hat mir geholfen. Hier ist meine Konfiguration, die mit SonarQube 5.0.1 und Active Directory funktioniert:

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
0
Nathan

Keine der Lösungen hat zuvor für mich funktioniert, aber dies:

# 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

Mein Ldap-Server muss authentifiziert werden, daher kann ich das nicht vermeiden. Wenn dies bei Ihnen nicht funktioniert, versuchen Sie, den ldap.user.request nicht anzugeben: alles hängt von der Konfiguration des LDAP-Servers Ihres Netzwerks ab.

0
EliuX