I am trying to get Sonar to use LDAP authentication against Active Directory
I have the following settings
# LDAP Authentication
sonar.security.realm: LDAP
sonar.authenticator.class: org.sonar.plugins.ldap.LdapAuthenticator
sonar.authenticator.createUsers: true
ldap.url: ldap://172.20.16.15:389
ldap.baseDn: DC=mycompany,DC=com
ldap.bindDn: CN=myuser,OU=serviceaccounts,OU=My Group,DC=mycompany,DC=com
ldap.bindPassword: password
ldap.loginAttribute: sAMAccountName
ldap.userObjectClass: user
# ldap.user.request: sAMAccountName={0}
However, I keep getting
ERROR rails Error from external users provider: java.lang.NullPointerException: null
I tried changing ldap.loginAttribute/ ldap.userObjectClass with ldap.user.request but that still does not work.
The sonar ldap plugin I have is 1.2.1. Please help me identify what is wrong with the config
I have used the same entries with ADExplorer to ensure that I can browse the AD and the same/similar settings work with Artifactory
Ok, looks like I was using some deprecated properties. Once I enabled debug on the plugin I was able to get useful info
Here is what worked for me with LDAP plugin 1.2.1 and sonar 3.4
sonar.security.realm: LDAP
#sonar.authenticator.class: org.sonar.plugins.ldap.LdapAuthenticator -- use above
sonar.authenticator.createUsers: true
ldap.url: ldap://server:389
ldap.user.baseDn: DC=mycompany,DC=com
ldap.bindDn: CN=myuser,OU=serviceaccounts,OU=MyGroup,DC=mycompany,DC=com
ldap.bindPassword: password
#ldap.user.objectClass: user -- use the ones below
#ldap.group.objectClass: group -- use the ones below
#ldap.group.memberAttribute: member --use the ones below
#ldap.user.loginAttribute: sAMAccountName -- use the ones below
ldap.group.request: (&(objectClass=group)(member={dn}))
ldap.user.request: (&(objectClass=user)(sAMAccountName={login}))
Related
SQ 5.6, LDAP plugin 2.0.
I've successfully installed the LDAP plugin and restarted the SQ server. In the log (/opt/sonar/logs/sonar.log) the plugin is apparently deployed, but seemingly no attempt is made to initialize/enable it or connect to the LDAP server.
INFO web[o.s.s.p.ServerPluginRepository] Deploy plugin LDAP / 2.0 / 2910f3981167a70a201ccfae01471dfd26c794b7
.
.
INFO web[o.s.s.p.RailsAppsDeployer] Deploying app: ldap
These are the only mentions of ldap/LDAP in the log.
Relevant part of the conf/sonar.properties file:
sonar.security.realm=LDAP
ldap.url=ldap://myldap:389
ldap.user.baseDn=ou=mycompany,ou=People,dc=myurl,dc=com
I believe I've verified ldap.url and ldap.user.baseDn via JXplorer (an LDAP browser).
What really puzzles me is that I don't see anything like the following in the logs, which is what I'd expect from the SQ docs:
INFO org.sonar.INFO Security realm: LDAP ...
INFO o.s.p.l.LdapContextFactory Test LDAP connection: OK
No errors of any kind are noted in the log.
Any idea why SQ is not even apparently trying to kick off LDAP authentication on a restart?
I had the same problem. I'm running Sonarqube using docker. It did not pick up on changes when I restart the server from the Sonarqube UI. Only after restarting the docker image it could pick up the changed file.
Well, now it just started working. I don't have an answer as to why though. Maybe something changed with my LDAP server, or there was some latency that needed to be overcome. I didn't change anything on my end that I'm aware of. In any case, thanks to those that responded.
I am testing an upgrade to sonarqube 5.6 and have installed the ldap 2.0 plugin & copied the relevant configuration forward to my test 5.6 setup.
The relevant config is
sonar.security.realm=LDAP
ldap.url=ldaps://xxxx:636
ldap.bindDn=uid=xxxx,ou=xxxx,dc=xxxx,dc=xxxx
ldap.bindPassword=xxxx
ldap.user.baseDn=dc=xxxx,dc=com
ldap.user.request=(&(objectClass=person)(mail={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
I have the following set in conf/sonar.properties
sonar.log.level=DEBUG
On startup I see
2016.07.26 23:57:29 INFO web[o.s.p.l.LdapContextFactory] Test LDAP connection on ldaps://xxxx:636: OK
2016.07.26 23:57:29 INFO web[org.sonar.INFO] Security realm started
If I attempt to login, I get "Authentication failed" on the login screen.
The log file says nothing other than
2016.07.26 23:57:47 DEBUG web[http] GET / | time=67ms
2016.07.26 23:57:47 DEBUG web[http] GET / | time=187ms
2016.07.26 23:57:47 DEBUG web[http] GET /sessions/new | time=89ms
2016.07.26 23:57:53 DEBUG web[http] POST /sessions/login | time=71ms
The same configuration works fine with sonarqube 4.5.7 and ldap 1.4
Ideas welcome on how to investigate further.
You're most likely hitting known issue SONAR-7770 - Authentication fails if LDAP configuration has been forgotten during the upgrade . Note that an Upgrade Note was issued for this problem:
Most specifically, don't forget to copy the related SonarQube plugin and its related configuration in "conf/sonar.properties" (including "sonar.security.realm" and "sonar.security.localUsers" if present) into the new SonarQube instance otherwise you will be locked out after migration.
So it's important that this LDAP configuration is there even during the upgrade. If you did miss that then the easiest way forward here is to replay the upgrade with the LDAP-related configuration correctly set.
Context
Keep in mind that during an upgrade SonarQube updates the dataset and also stores new information in database (based on new features). The problem in your case would be that the upgrade was done with a partial config (which didn't set sonar.security.realm and sonar.security.localUsers) , and SonarQube couldn't figure out whether users were local or not, hence treating them as local by default. Local users are not authenticated against external authentication providers but locally, which is indeed what we're seeing in your logs (and it's obviously failing because the password lives in LDAP server, not in SonarQube database).
I fixed it by manually updating the users database table of SonarQube, asumming that all other users are managed by LDAP and just the admin is a local user:
UPDATE sonarqube_production.users SET user_local = 0, external_identity_provider = 'ldap' WHERE id != 'admin';
Little fix to Schakko query above, it should be with login not with id:
UPDATE users SET user_local = 0, external_identity_provider = 'ldap' WHERE login != 'admin';
I installed WSO2 AM(API Manager) 1.10.0 and used the user-mgt.xml from working AM 1.9.0, but now I cannot login to carbon admin UI.
API Manager is configured with LDAP read only primary user store.
Additionally API Manager is configured to work with default H2. But I think this is not a reason.
If I configure API Manager with a standard user store (without any changes to user-mgt.xml, i.e. without adding readOnlyLdap config and removing default JDBC UserStoreManager), login to admin-dashboard works OK.
I got the warning message from wso2carbon.log:
TID: [-1234] [] [2016-07-03 05:55:54,731] WARN {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil} - Failed Administrator login attempt 'admin[-1234]' at [2016-07-03 05:55:54,730+0000] {org.wso2.carbon.core.services.util.CarbonAuthenticationUtil}
I made the changes as suggested per I am unable to login to admin-dashboard application in WSO2 API manager , unfortunately that solution did not work for me.
Basically I installed brand new WSO2 am 1.10.0, with default settings, all works fine, until I changed user-mtg.xml to enable LDAP, I cannot login to carbon/admin UI anymore. So LDAP does not work out of the box with wso2 am 1.10.0? I followed the instructions related to LDAP set up, but it just did not work.
The strange thing is, LDAP works with am 1.9.0. So any difference in setting up LDAP between version 1.10.0 and 1.9.0?
UPDATE:
For the moment, I gave up integarting LDAP with wso2 am 1.10.0. I moved to SAML2. But keep the question open in case someone has worked out of this with a solution, or this might help others. Thanks.
What is the value of the GetAllRolesOfUserEnabled property under AuthorizationManager in user-mgt.xml?
<AuthorizationManager class="org.wso2.carbon.user.core.authorization.JDBCAuthorizationManager">
<Property name="AdminRoleManagementPermissions">/permission</Property>
<Property name="AuthorizationCacheEnabled">true</Property>
<Property name="GetAllRolesOfUserEnabled">false</Property>
</AuthorizationManager>
That property is not part of the 1.9 config and in 1.10 the default config has this set to false and we were seeing similar login issues. Setting this to true resolved this issue for us.
Joe
I can provide following hints.
Since you haven't mentioned about the master-datasources.xml, I doubt the following. Do you have a external userstore database used in 1.9.0? If so, have you pointed 1.10.0 to the same database?
Log doesn't clearly say whether it failed due to authentication or authorization error. To find this out, you need to enable debug logs for the package org.wso2.carbon.user.core. This can be done in the repository/conf/log4j.properties file and needs a restart. Then, when your next login attemp fails, it will show you more details.
I'm trying to set up the user mapping on SonarQube (Latest) so it can fetch the organizational structure from LDAP.
I already installed the LDAP plugin on Sonar (1.5.1), and created a minimal configuration to connect the two:
# General Configuration
sonar.security.realm=LDAP
ldap.url=ldap://ldap:389
# User Mapping
ldap.user.baseDn=ou=users,ou=udd,dc=example,dc=com
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={uid}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
All my users are under the example.com domain:
But then, as I try to login to Sonar using the LDAP entries I get the following error on the logs:
Error from external users provider: exception Java::OrgSonarApiUtils::SonarException: Unable to retrieve details for user dev1 in <default>
Which is pretty frustrating, since all those properties are configured on the configuration file above.
Any ideas about the source of this issue?
EDIT:
I found this when I increased the log depth to DEBUG:
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapContextFactory] Initializing LDAP context {java.naming.provider.url=ldap://ldap:389, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, com.sun.jndi.ld
ap.connect.pool=true, java.naming.security.authentication=simple, java.naming.referral=follow}
2016.01.25 05:54:27 DEBUG web[o.s.p.l.LdapUsersProvider] integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
javax.naming.directory.InvalidSearchFilterException: integer expected inside {}: (&(objectClass=inetOrgPerson)(uid={uid}))
at com.sun.jndi.toolkit.dir.SearchFilter.format(SearchFilter.java:602) ~[na:1.7.0_95]
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1785) ~[na:1.7.0_95]
...
I don't see why is an integer supposed to be expected between the {}'s, and that doesn't make much sense compared to my LDAP structure.
Try to set ldap.user.request to (&(objectClass=inetOrgPerson)(uid={login}) (instead of using (uid={uid})).
Details:
The LDAP Plugin does not recognise {uid} and therefore doesn't know what to do with it. It then passes it to the LDAP javax.naming API, which chokes on this. This behaviour is made explicit at SonarQube startup (logs in my case):
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={uid})), realNameAttribute=cn, emailAttribute=mail}
Using {login} instead (keyword shown in the documented default values) will let the LDAP Plugin build a well-formed request with a {0}:
INFO web[o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=employees,dc=example,dc=org, request=(&(objectClass=inetOrgPerson)(uid={0})), realNameAttribute=cn, emailAttribute=mail}
The javax.naming API will then replace this {0} by a parameter which SonarQube will set to the actual username value you fill in the login form.
I would like to enable the export of the users from Liferay into my OpenLDAP server.
So I enabled the ceckbox on the configuration page and I set the parameters in the LDAP export.
Now, when I try to create a user in Liferay I get:
Login is temporarily unavailable.
any suggestions?
this is the bt in java console:
Caused by: javax.naming.directory.InvalidAttributeValueException: [LDAP: error code 21 - object
class: value #1 invalid per syntax]; remaining name 'cn=myname,dc=myTest,dc=com'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3054)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2794)
at com.sun.jndi.ldap.LdapCtx.c_bind(LdapCtx.java:397)
at com.sun.jndi.ldap.LdapCtx.c_bind(LdapCtx.java:354)
at com.sun.jndi.toolkit.ctx.ComponentContext.p_bind(ComponentContext.java:596)
at com.sun.jndi.toolkit.ctx.PartialCompositeContext.bind(PartialCompositeContext.java:1
83)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at com.liferay.portal.security.ldap.PortalLDAPExporterImpl.addUser(PortalLDAPExporterIm
pl.java:360)
at com.liferay.portal.security.ldap.PortalLDAPExporterImpl.exportToLDAP(PortalLDAPExpor
terImpl.java:252)
at com.liferay.portal.security.ldap.PortalLDAPExporterUtil.exportToLDAP(PortalLDAPExpor
terUtil.java:62)
at com.liferay.portal.model.UserListener.exportToLDAP(UserListener.java:96)
at com.liferay.portal.model.UserListener.onAfterUpdate(UserListener.java:72)
... 91 more
Either you have wrong configuration, or you're stuck on a Liferay - LDAP bug.
Here's the list of unresolved issues.
Please provide us an English error message next time, because all I see in your screenshot is... an error message.
If you're using Liferay 6.1 Community there are a few unresolved LDAP related bugs in that version. I faced a number of problems and ultimately it worked by
Disbaling LDAP export in the LDAP wizard.
Creating a custom hook which is triggered at user login, creation or any other change to the user object. The hook problematically through Java JNDI look up library exports users into the external AD through LDAP. You can find the hook related code here: http://abhirampal.com/2014/12/20/liferay-ldap-export-to-active-directory-disabled-user-bug/
Feel free to ask if anyone's got any questions.