5 Replies Latest reply: Dec 28, 2005 8:40 PM by Jon Coign RSS

Securing web-console => login failure

Rainer Frey Newbie

I tried to secure the web-console as described in the Wiki by uncommenting the security relevant elements in web.xml and jboss-web.xml. On my notebook, I additionally changed the password in the users.properties; on my pc I used the file as is. On both installations, I get a bad password error. And yes, I more than double checked the password.
My Notebook runs Mac OSX with Java 1.4.2, my PC Suse Linux 9.1, also with Java 1.4.2. JBoss version on both computers is 4.0.0RC1.
Web browser was Safari on Mac OS, Konqueror 3.3 on Linux.

Here is an excerpt from server.log:

[org.jboss.security.auth.spi.UsersRolesLoginModule] Bad password for username=admin
2004-08-23 17:03:12,690 DEBUG [org.jboss.security.plugins.JaasSecurityManager.web-console] Login failure
javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
 at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:160)
 at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:116)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675)
 at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
 at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
 at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
 at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:476)
 at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:430)
 at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:246)
 at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:221)
 at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.authenticate(JBossSecurityMgrRealm.java:239)
 at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:129)
 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
 at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:146)
 at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
 at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
 at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
 at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:122)
 at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
 at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
 at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
 at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
 at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
 at java.lang.Thread.run(Thread.java:534)


  • 1. Re: Securing web-console => login failure
    Scott Stark Master


    Another users.properties is most likely being picked up. Change the web-console login-config.xml entry so that that properties files are uniquely named to avoid ambiguity with which resource is picked up. You also would need to rename the web-console properties files.

     <application-policy name = "web-console">
     <authentication>
     <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
     flag = "required">
     <module-option name="usersProperties">web-console-users.properties</module-option>
     <module-option name="rolesProperties">web-console-roles.properties</module-option>
     </login-module>
     </authentication>
     </application-policy>
    



  • 2. Re: Securing web-console => login failure
    Rainer Frey Newbie

    Thanks, that did it. Is there any documentation where and in which order those files are looked up?

  • 3. Re: Securing web-console => login failure
    Robert Hook Newbie

    For what it's worth, in the 4.0.2 default server configuration, the jmx-console-roles.properties and jmx-console-users.properties files are in server\default\conf, and these are picked up before any files in the server\default\deploy\jmx-console.war\WEB-INF\classes location.

    Either move them from default\conf to WEB-INF\classes before changing the password, or leave them in place and don't put the files in WEB-INF\classes

  • 4. Re: Securing web-console => login failure
    Robert Hook Newbie

     

    "rhook" wrote:
    For what it's worth,

    the http://wiki.jboss.org/wiki/Wiki.jsp?page=SecureTheJmxConsole page has been updated

  • 5. Re: Securing web-console => login failure
    Jon Coign Newbie

    I still cannot seem to get this working. My file names are unique and I have even tried renaming them and fully qualify the path. I have read in a couple of places that there is a problem with 3.2.5 loading the Properties files if there is a space in the installation folder. Have you found this to be the case? Are there any workarounds to this without having to upgrade JBoss. Our installation is part of our quality center install and I would prefer to not have to upgrade JBoss so we can stay on a supported platform.

    Thanks,
    Jon