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';
Related
I am trying to setup Forge rock(OpenAM13.0) with OpenDJ 3.0,
deployed Open Am in tomcat and Installed opendj successfully. setup where I end up with an error .
Environment:
- OpenAM(V 13.0).war with Tomcat (8.5.27)
- OpenDJ 3.0.0 for External Identity perupose.
-AS part of the process deployed the OpenAM war and on tomcat and could
able to login in with amadmin.
-Created policy set and policy and reqeust patterns as well.(followed
the forgerock getting started guide:https://backstage.forgerock.com/docs/openam/13/getting-started/).
-Here I installed apache 2.4 webserver could able to see the home page.
Error: when i try to configure the WEb agent I endup with below
error,could not able to proceed further.
But I could able to login from the openam login screen but end up with some session invalid exception in session.log and no session in access.csv log file.I could not able to understand and go further.help on this regard is greatly appreciated.
Attached the screen shot of different logs i got .
[WEbagent_insall_Log][1] - Log during web agent installation
[Session-Log][2] - Log at the server openam side
[OpenaM_access.csv_log][3] log for open am side about the access
[WEbagent Installation][1] screen when I try to install webagent
[1]: https://i.stack.imgur.com/HmCFZ.jpg
[2]: https://i.stack.imgur.com/KX1Tb.jpg
[3]: https://i.stack.imgur.com/jQYUX.jpg
Please help on this.
Thanks
Venkat
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 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.
This is expanded version of another login module problem I had. I diagnosed some more important details which encouraged me to start new thread. It occurres that after Glassfish reboot all login modules stopped working. What is even funnier, Glassfish reports that modules where loaded correctly.
[#|2012-09-05T16:40:59.698+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmsManager;MethodName=createRealms;|Initializing configured realms from SecurityService in Domain.xml....|#]
[#|2012-09-05T16:40:59.710+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : file={glass_home}/glassfish/domains/domain1/config/admin-keyfile|#]
[#|2012-09-05T16:40:59.710+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : jaas-context=fileRealm|#]
[#|2012-09-05T16:40:59.711+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=loadKeyFile;|Reading file realm: {glass_home}/glassfish/domains/domain1/config/admin-keyfile|#]
[#|2012-09-05T16:40:59.713+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]
[#|2012-09-05T16:40:59.713+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: admin-realm|#]
[#|2012-09-05T16:40:59.714+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : file={glass_home}/glassfish/domains/domain1/config/keyfile|#]
[#|2012-09-05T16:40:59.714+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=init;|FileRealm : jaas-context=fileRealm|#]
[#|2012-09-05T16:40:59.715+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.file.FileRealm;MethodName=loadKeyFile;|Reading file realm: {glass_home}/glassfish/domains/domain1/config/keyfile|#]
[#|2012-09-05T16:40:59.715+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]
[#|2012-09-05T16:40:59.715+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: file|#]
[#|2012-09-05T16:40:59.717+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.|#]
[#|2012-09-05T16:40:59.718+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: certificate|#]
[#|2012-09-05T16:40:59.757+0200|FINEST|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm;MethodName=init;|JDBCRealm : jaas-context= jdbcRealm, datasource-jndi = jdbc/mysql-zus, db-user = null, digest-algorithm = MD5, encoding = Hex, charset = UTF-8|#]
[#|2012-09-05T16:40:59.758+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;|SEC1115: Realm [ShibUserPassAuth] of classtype [com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm] successfully created.|#]
[#|2012-09-05T16:40:59.758+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Configured realm: ShibUserPassAuth|#]
[#|2012-09-05T16:40:59.758+0200|FINE|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=1;_ThreadName=Thread-2;ClassName=com.sun.enterprise.security.auth.realm.RealmConfig;MethodName=createRealms;|Default realm is set to: ShibUserPassAuth|#]
[#|2012-09-05T16:40:59.762+0200|INFO|glassfish3.1.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=1;_ThreadName=Thread-2;|SEC1011: Security Service(s) Started Successfully|#]
But I am unable to use any of secure realms, during basic authentication.
I tried both custom jdbcRealm and preconfigured fileRealm with new user
It ends up with this:
javax.security.auth.login.LoginException: No LoginModules configured for jdbcRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
and this
javax.security.auth.login.LoginException: No LoginModules configured for fileRealm
at javax.security.auth.login.LoginContext.init(LoginContext.java:273)
More over I can't even use more sophisticated asadmin commands, because I received "unauthorised wrong login or password" and in server.log
No LoginModule configured for fileRealm
I checked LoginContext implementation and it looks like that
AppConfigurationEntry[] entries = config.getAppConfigurationEntry (name);
is constantly going wrong way, and null is returned.
I don't manipulate config files by hand. Can I somehow corrupt on of them in a way that block LoginModules?
Which configuration file is being read by ConfigurationEntry above?
Before this unfortunate reboot problem with the MySQL database occurred. There were more available for the Glassfish connection pool, than database permits. After killing connections from database, changing connection numbers for appropriate I rebooted container and everything collapsed.
login.conf exist in domain dir and looks ok.
Hope for help
Paraphrasing Catherine Zeta Jones and Liza Minnelli before her i will say
"and All that JAAS...".
It occurs that one of third party aplications was loading it's own login.conf file for JAAS module, which destroyed all Glassfish login modules. This situation occurs after container reboot when secondary configuration file was being loaded. Funny thing, Glassfish was able to load it's own file properly, show off in logs... and then overwrite it malicious configuration. Watch your configuration files!