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

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.

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

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.

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

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

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.