We are running Glassfish 3.1.2.2 authenticating against an Active Directory realm. Authentication works correctly the vast majority of the time, but occasionally, authentication will suddenly start failing for all users, and we'll see errors like this in the server log:
[#|2014-03-19T21:37:32.331+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.web.security|_ThreadID=1098;_ThreadName=Thread-2;|WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Failed file login for jeff.|#]
Note that the error message is failed file login. It appears as if Glassfish is occasionally reverting back to the file realm rather than the active directory realm.
When this problem happens, after a short time without any intervention on our part, authentication will suddenly start hitting Active Directory again and users will be able to login again.
Any ideas why Glassfish would occasionally revert to authentication against the file realm when we've configured it to use Active Directory? Should I delete the file realm altogether?
I finally determined the trigger for this. We had been connecting JVisualVM to our Glassfish instance to monitor performance. Everytime I connect JVisualVM (over JMX connection using Glassfish admin credentials), Glassfish immediately reverts to using the file realm instead of the LDAP realm. I have no idea why JVisualVM would cause this behavior in Glassfish, but it is consistently reproducible. The only workaround I have discovered is:
Disconnect JVisualVM.
In Glassfish admin console go to -> Configurations -> server-config -> Security
Change default realm (to anything other than LDAP realm), Save.
Change default realm back to LDAP realm, Save.
Clients should now again be able to authenticate against LDAP.
Related
After installing patch 10.3.6.0.200114, Weblogic console could not log in, indicating "WebLogic Server has rejected this user name or password. Please try again. " However, the service can be accessed normally
There is a bug in this PSU which prevent web app like the admin console to authenticate users. Oracle published a patch to correct this issue : SU Patch [EIL8]: 10.3.6.0.200114WLSPSU Overlay: CANNOT LOGIN TO CONSOLE, BUT CAN LOGIN TO EM WITH THE SAME USER
Download it from MOS and patch your WebLogic server installation.
I looked at the config files everything is fine, made environment variables PATH's, started and restarted the service put in the right password, searched for someone with similar problems(not found).
Every time i go to the default location via browser I get the login screen but when i put in 'root' and the password I get an error message 'Login Failed'.
When I set athenticate=false in the conf file i can access the web manager.
Anybody know how to solve this or at least what might be wrong?
During the installation, the ArangoDB Installer will ask you the password for the administrator user.
Use root as user name with your password to gain access to the database.
Open a CMD-Window in your ArangoDB installation directory.
To re-gain access to the database, stop the ArangoDB database service using
sc stop ArangoDB
after the database was stopped, invoke
.\usr\bin\arango-secure-installation
which will ask you for a new password.
After that, start the service again using:
sc start ArangoDB
I'm using sonar 5.6 LTS with LDAP plugin 2.1.0.
The basic LDAP configuation is working fine. Sonar can connect to LDAP (in my case active directory). sonar.log:
Test LDAP connection on ldaps://ldap.mycompany:636: OK
My user mapping is
ldap.user.baseDn=OU=Users,OU=Accounts,DC=mycompany
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
When I try to login with mycompany\tobi sonar logs:
DEBUG web[o.s.p.l.LdapUsersProvider] Requesting details for user mycompany\tobi
...
DEBUG web[o.s.p.l.LdapUsersProvider] User mycompany\tobi not found in <default>
This makes sense as sAMAccountName contains the value tobi and not mycompany\tobi. But when using just tobi as login, sonarqube does not connect to LDAP for authentication. I just get "Authentication failed" and the log file contains only
DEBUG web[http] POST /sonar/sessions/login | time=235ms
Any ideas why sonarqube does not always use LDAP? Thanks, Tobi
Thanks to Godin, I've finally found the answer:
The root cause is that I had a local account with the same login credentials before using LDAP. When removing users using the web interface, they are not removed permanently from the database. Instead, they are just deactivated.
I connected to the (postgresql) database and in the users table there were still all old local accounts. So I just changed the login column of all deprecated local accounts with
UPDATE users SET login='username_local' WHERE login='username'
As those accounts are deactivated, they cannot be used to login into sonarqube but should not be removed as some other tables might still have references to them.
Environment:
MFP 6.3 Studio Windows 7
MFP 6.3 Server (WAS LC)
Downloaded the form-based sample from the IBM MobileFirst Platform Developer Center.
In MFP 6.3 Studio, the sample runs fine.
I then change my build settings and Build All Environment -> get the new wlapp file.
I get my war file from the MFP 6.3 Server. Open up and put in the modified authenticationConfig.xml
Basically it's just transferring the one snippet from the studio authenticationConfig.xml to the xml file within the WAR file.
<customSecurityTest name="DummyAdapter-securityTest">
<test isInternalUserID="true" realm="SampleAppRealm"/>
</customSecurityTest>
I restart the server and deploy the .wlapp and .adapter files.
In the standalone server, I run the preview mode. I Enter the username and password and login. It didn't login and I see these errors on the server console.log.
[ERROR ] SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo.
[ERROR ] SRVE0232E: Internal Server Error. Exception Message: [com.ibm.ws.webcontainer.webapp.WebAppErrorReport: com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo.
at com.ibm.ws.webcontainer.session.impl.HttpSessionContextImpl.checkSecurity(HttpSessionContextImpl.java:686)
at [internal classes]
at com.worklight.core.auth.impl.AuthenticationFilter.associateAuthContextWithThread(AuthenticationFilter.java:426)
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:145)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
Caused by: com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo.
... 7 more
]
[ERROR ] SRVE0777E: Exception thrown by application class 'com.worklight.core.auth.impl.AuthenticationContext.checkAuthentication:604'
com.worklight.server.auth.api.WorkLightAuthenticationException
at com.worklight.core.auth.impl.AuthenticationContext.checkAuthentication(AuthenticationContext.java:604)
at com.worklight.core.auth.impl.AuthenticationContext.processRealms(AuthenticationContext.java:469)
at com.worklight.core.auth.impl.AuthenticationContext.pushCurrentResource(AuthenticationContext.java:443)
at com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:75)
at com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedureInternal(DataAccessServiceImpl.java:430)
at com.worklight.integration.services.impl.DataAccessServiceImpl.invokeProcedure(DataAccessServiceImpl.java:139)
at com.worklight.gadgets.serving.handler.BackendQueryHandler.getContent(BackendQueryHandler.java:95)
at com.worklight.gadgets.serving.handler.BackendQueryHandler.doPost(BackendQueryHandler.java:56)
at com.worklight.gadgets.serving.GadgetAPIServlet.doGetOrPost(GadgetAPIServlet.java:148)
at com.worklight.gadgets.serving.GadgetAPIServlet.doPost(GadgetAPIServlet.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1240)
at [internal classes]
at com.worklight.core.auth.impl.AuthenticationFilter$1.execute(AuthenticationFilter.java:217)
at com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:76)
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:222)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
After studying the securityIntegrationEnabled="false workaround, I think I have figured out why things are working / not working.
The solution is actually very simple without changing the server.xml.
When the error SESN0008E occured, I was testing the FormAuth app using the common preview mode by clicking on the link from the admin console in the standalone server. Although the common preview link opened to a new browser, but the sessionID actually stays. Both browser tabs are in the same session (I checked).
It means that the sessionID that I am using is actually the one that was already authenticated by the Admin Console. And in my preview mode I tried to authenticate again in the session that was already "owned" by another user. This causes WAS to throw the error SESN0008E: A user authenticated as anonymous has attempted to access a session owned by user:BasicRegistry/demo. My app preview is in the same httpsession as the admin console, and hence the error.
So to get it to work, I copy the preview link. Close all the browser to ensure the sessions are killed. Open a new browser, paste the preview link and the FormAuthentication works now.
A maybe more convenient solution would be to create a mobile web environment and use that for preview testing.
In WAS and WAS Liberty profile, security integration is enabled by default. This also means that:
... session management facility associates the identity of users with
their HTTP sessions. This feature will mark a session as "owned" by
the first user that accesses a session that is not already marked as
owned.
If a session is already marked as owned, it will check that
the owner is the same as the current user. If not, rather than
granting access to the session, at minimum a message with identifier
SESN0008E will be logged and access to the session will not be
granted.
In some cases, an UnauthorizedSessionRequestException is
thrown, with message SESN0008E as the cause.
In the MobileFirst Development Server in Eclipse, the underlying WAS Liberty's server.xml has this disabled.
For your POC as a workaround, you can disable the feature by adding in the server.xml file the following entry: <httpSession securityIntegrationEnabled="false"/>
Note that adding this setting is global to all applications and can impact negatively on existing applications on the server, if in existance.
I am using Liferay 6.2 and I am trying to do LDAP Authentication. The LDAP Server is provided by another organization and I do not have access to any configuration, I just have credentials for a system account to look up the directory. When I try to log in Liferay with user credentials from the LDAP Server the authentication fails with the following error code:
13:54:05,738 ERROR [http-bio-8080-exec-3][LDAPAuth:341] Problem accessing LDAP server
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr:
DSID-0315270B, problem 2001 (NO_OBJECT), data 0, best match of:
'O=uni,C=de' remaining name 'ou=people,o=uni,c=de'
The same error that occurs when trying to log in with a user that does not exist in the LDAP directory. Nevertheless, the mapping still works. After trying to log in with valid user credentials there is an entry in the liferay database with the corresponding user data. Accessing Liferay is not possible though.
These are my settings in portal-ext.properties (Test LDAP connections returns success, connection settings are pseudonymised):
ldap.base.provider.url=ldaps://ldap.ldap-server
ldap.base.dn=ou=people,o=uni,c=de
ldap.security.principal=uid=prox,ou=prox,o=uni,c=de
ldap.security.credentials=secret
#auth.pipeline.enable.liferay.check=false
ldap.auth.enabled=true
ldap.auth.required=true
ldap.auth.method=bind
ldap.import.enabled=false
ldap.import.on.startup=false
ldap.import.interval=10
ldap.export.enabled=false
ldap.export.group.enabled=false
ldap.auth.search.filter=(uid=#screen_name#)
ldap.import.user.search.filter=(objectClass=inetOrgPerson)
ldap.attrs.transformer.impl=com.liferay.portal.security.ldap.DefaultAttributesTransformer
ldap.user.mappings=screenName=cn\npassword=userPassword\nfirstName=givenNam\nlastName=sn\njobTitle=title\ngroup=groupMembership
users.email.address.required=false
users.email.address.auto.suffix=#no-emailaddress.com
users.email.address.generator=com.liferay.portal.security.auth.DefaultEmailAddressGenerator
users.email.address.validator=com.liferay.portal.security.auth.DefaultEmailAddressValidator
ldap.password.policy.enabled=false
ldap.import.user.password.enabled=true
ldap.import.user.password.autogenerated=false
ldap.import.user.password.default=test
Check the FQDN on the LDAP side, including the prefixes (cn, ou, etc.), and ensure that it matches the directory configuration within Liferay.
You can try configuring it from the control panel it will be easier for you as it allows to check whether the connection is made or not. You can check the users are fetched or not and it doesnt even need a server restart.
It works now. There were two issues:
I changed ldap.base.dn=ou=people,o=uni,c=de to ldap.base.dn=o=uni,c=de and
ldap.import.user.search.filter=(objectClass=inetOrgPerson) to ldap.import.user.search.filter=(objectClass=*)