web-dev-qa-db-fra.com

L’authentification LDAP SonarQube semble se charger mais ne permet pas la connexion via un utilisateur de domaine

J'ai essayé de configurer SonarQube (v4.1) avec le plug-in d'authentification LDAP (v1.4) et je ne parviens pas à le faire authentifier auprès de mon utilisateur de domaine. Ma configuration est configurée comme suit:

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

et le journal génère les messages suivants qui semblent indiquer que la connexion LDAP fonctionne correctement:

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

Mais cela ne semble pas fonctionner pour mon utilisateur, sauf si j'utilise un utilisateur local. Lorsque vous activez la journalisation sur le wrapper en définissant:

wrapper.console.loglevel=DEBUG

Je reçois l'erreur suivante dans les journaux, ce qui n'aide pas beaucoup! :)

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

Merci à @aaron qui a réussi à me diriger dans la bonne direction! Pour mon problème, il s'agissait d'un problème de découverte automatique et de forêt à laquelle je me connectais. Selon http://technet.Microsoft.com/en-us/library/cc978012.aspx , vous devez utiliser un port différent lors de la connexion à une forêt pour pouvoir ensuite effectuer une recherche dans toute la forêt plutôt que dans le domaine de votre choix. se connecter à (ce qui, je suppose, pourrait ne pas être le bon en mode de découverte automatique). En fin de compte, la configuration qui a fonctionné pour moi était la suivante:

# 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

Ce qui est en fait assez simple et ne nécessite pas de compte utilisateur pour se connecter. Cela signifie qu'il est en mode d'authentification SIMPLE (je n'arrive pas à le faire fonctionner avec quoi que ce soit d'autre), mais cela me convient car c'est un système interne uniquement.

9
caveman_dick

Je viens de travailler pour que le plug-in SonarQube LDAP fonctionne avec Active Directory moi-même. Étant donné que le réseau de chacun est configuré différemment, vous ne pouvez souvent pas simplement copier et coller une configuration. Voici le processus que j'ai utilisé pour déterminer la configuration correcte dans mon entreprise:

Comme indiqué dans la documentation , cette configuration est enregistrée dans le fichier:

SONARQUBE_HOME/conf/sonar.properties

La ligne suivante est requise en l'état: sonar.security.realm=LDAP. Les autres lignes seront différentes par entreprise.

Cela m'a été utile de tester la configuration avec un outil graphique. J'ai utilisé le navigateur LDAP Softerra (version gratuite en lecture seule de l'administrateur LDAP). Dans ce navigateur LDAP,

  1. Créez un nouveau profil.
  2. Le bouton Lookup Servers vous aidera à déterminer le fichier ldap.url. Vous devrez vous retrouver avec quelque chose du type ldap.url=ldap://dc01.mycompany.local:3268. REMARQUE: comme indiqué dans une autre réponse, il peut être nécessaire d'utiliser un port différent de celui indiqué dans cet écran.
  3. La zone DN de base peut être laissée en blanc pour le moment.
  4. Pour l'authentification, je viens de choisir l'utilisateur actuellement connecté.
  5. Le filtre peut également être laissé vide pour l'instant.
  6. Cliquez sur Terminer. Les éléments situés au plus haut niveau de votre AD devraient s'afficher.
  7. F3 bascule la barre de recherche rapide.
  8. Étant donné que vous ne pouvez pas connecter SonarQube à AD avec une authentification anonyme, vous devrez sélectionner un utilisateur pour le service SonarQube. Recherchez cet utilisateur dans la recherche rapide.
  9. Vous devriez trouver une entrée CN (Common Name). Double-cliquez dessus pour l'ouvrir.
  10. Recherchez le champ distinguNom et copiez sa valeur à utiliser comme votre ldap.bindDn
  11. ldap.bindPassword devrait être le mot de passe de cet utilisateur.
  12. Cela devrait être suffisant pour permettre à SonarQube de démarrer correctement, mais il NE suffit PAS de lui permettre de rechercher l'utilisateur qui tente de se connecter à votre portail Web SonarQube. Pour cela, commencez par choisir un exemple de personne (comme vous-même).
  13. Effectuez une autre recherche rapide pour la personne de l'échantillon et ouvrez son entrée CN.
  14. Prenez la valeur de leur distinctionName, supprimez la pièce "CN = {Leur nom}" et mettez-la dans ldap.user.baseDn
  15. Le dernier morceau que vous devez déterminer avec le ldap.user.request. La suggestion de la documentation SonarQube à utiliser avec AD a fonctionné pour moi: (&(objectClass=user)(sAMAccountName={login})). Laissez-moi vous expliquer pourquoi, au cas où cela ne fonctionnerait pas pour vous. Le "{login}" sera remplacé par ce que le SonarQube entre pour son nom d'utilisateur. La chaîne de requête (appelée "Filtre" dans le navigateur LDAP) indique donc qu'il faut rechercher toutes les entrées avec un objectClass égal à "utilisateur" et sAMAccountName égal à ce qui est saisi dans la zone de texte du nom d'utilisateur de votre portail Web SonarQube. Dans les informations sur la personne exemple, il devrait y avoir au moins un champ appelé "objectClass". Un de ceux-ci devrait avoir la valeur "utilisateur". Il devrait également y avoir un champ pour sAMAccountName. Utilisez cette valeur pour la zone de texte du nom d'utilisateur dans votre portail Web SonarQube.
  16. Pour vérifier si cette chaîne de requête doit fonctionner pour vous, effectuez une recherche dans le navigateur LDAP (Ctrl + F3). Placez votre valeur ldap.user.baseDn dans le texbox "Search DN" et insérez votre valeur ldap.user.request dans le texbox Filter (veillez à remplacer manuellement "{login}" par votre nom d'utilisateur exemple). Il devrait renvoyer l'entrée CN pour la personne de l'échantillon.
15
kevinpo

J'utilise SonarQube 3.7.3 et j'ai connecté ma configuration qui fonctionne. J'espère que cela serait utile.

# 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

Ma solution

J'avais minutieusement vérifié mes paramètres, allant même jusqu'à utiliser la ligne de sortie "Mappage utilisateur" du fichier journal pour configurer une commande manuelle ldapsearch et vérifier que mon utilisateur était correctement extrait.

Pour une raison quelconque, spécifier ce paramètre le corrige pour moi:

ldap.user.realNameAttribute=cn

Pourquoi?

Cet attribut est supposé être facultatif et cn par défaut quand même, mais il ne fonctionne que si je le spécifie manuellement. Cela pourrait être un bug.

Débogage avec ldapsearch

ldapsearch peut vous permettre d’ignorer directement la requête d’application LDAP.

J'ai regardé dans le fichier journal pour cette ligne:

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}

Et puis construit une commande ldapsearch comme:

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 spécifie le DN de liaison, essentiellement le nom d'utilisateur de connexion pour LDAP
  • -W signifie que ldapsearch vous demandera le mot de passe
  • -h spécifie l'URL LDAP
  • -b doit être baseDN à partir de la ligne du fichier journal
  • Le dernier paramètre de position est la valeur de la demande de la ligne du fichier journal, après avoir remplacé {0} par un nom d'utilisateur réel.

Si vous obtenez de vraies informations utilisateur, cela signifie que vos paramètres de base sont corrects. Ceci est un indice que quelque chose ne va pas.

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

Avec la nouvelle version 1.5, une seule ligne est requise:

Configuration LDAP

sonar.security.realm = LDAP

2
Jirong Hu

Utiliser le port 3268 a fait l'affaire pour moi. Voici ma configuration qui fonctionne avec SonarQube 5.0.1 et 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
0
Nathan

Aucune solution auparavant ne fonctionnait pour moi, mais ceci:

# 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

Mon serveur LDAP a besoin d'une authentification, je ne peux donc pas l'éviter. Si cela ne fonctionne pas pour vous, essayez de ne pas spécifier le ldap.user.request: tout dépend de la configuration du serveur LDAP de votre réseau.

0
EliuX