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.
Related
I already installed Cloudera manager. After that, I add Zeppelin service and I start it.
I want to launch the Zeppelin Server Web UI and to authenticate with user=admin and password=admin but I didn't succeed. Error message: "The username and password that you entered don't match."
have you any idea please to unblock the situation?
Thanks.
After installation of openfire version 4.6 I was able to access console in browse http://domain:9090
and database also imported in mysql but when come to profile set up I am facing this error:
url: http://domain:9090/setup/setup-profile-settings.jsp
A failure occurred while fetching your session from the server. This is typically a cookie issue. Please either clear all cookies for this domain or try this URL again from an incognito browser session.
That was nothing but restart openfire and follow again. There will be no error.
I want to configured Jenkins with selenium webdriver on my local machine. I have downloaded the jenkins.war file and successfully ran from CMD. But now it is asking me for username and password. Which username and password I need to provide?
Jenkins is initially configured to be secure on first launch. During the initial run of Jenkins a security token is generated and printed in the console log.
You can use admin as username and the token as a password, if you skipped the user-creation.
Go through the documents for more detail.
Jenkins Installation Document
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.
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.