JBoss Windows service.bat password encryption

[glyph5]

Good morning,

For our configuration we use port offset of +100 (8180, 1199, etc) as well as the JBoss Native Windows service that utilizes service.bat to shutdown the server.

Trying to use the -s switch when calling the shutdown.bat (using "shutdown.bat -s localhost:1199") results in the error: Exception in thread "main" java.lang.SecurityException: Failed to authenticate principal=null, securityDomain=jmx-console

This error implies that we need to use a jmx-console login/password. When I provide the default login/password (shutdown.bat -s localhost:1199 -u username -p password), this works. Normally this would be good, except for two things:

1) The login and password is stored in plaintext in the jmx-console-users.properties file. (I am certain there is a way to encrypt this I just need to keep searching).

2) The modification to the service.bat file would require passing those parameters in plaintext as well.

We have a password encryption requirement for our environment that is not met in these conditions. Is there any way to easily encrypt these two sections to get this to work?

[peterj]

1) Don't use the UsersRolesLoginModule, use one of the other login modules such as DatabaseServerLoginModule (though you actually have to extend this if your passwords are encrypted in the database) or the LdapExtLoginModule (handy is you already have LDAP, which I assume you proibably do based on your security requirements).

2) I checked the source (in the source download at server/src/main/org/jboss/Shutdown.java). The code does not appear to handle an encrypted password - the most it does is prompt for a password is a user id is given but a password is not. You could, of course, modify that file to enable an encrypted password to be passed.

[glyph5]

Thanks Peter for your reply.

Do you know if there is any other way to accomplish shutdown without requiring these parameters? Previously we used the Java Service Wrapper but since the free version is not supported for 64-Bit we have reverted to the supplied native methods.

I'm trying not to stray too far from the standard configuration (we are using the EAP version) for support reasons, but if modifying the source is the only way we can make it work I'll have to consider it.

[peterj]

The issue is that the JMX invoker is locked down, which means that any JMX client (and shutdown is just another JMX client) needs to supply the username and password. You can unlock the JMX invoker, but then any JMX client can do anything that the MBeans registered with JMX allow.

If you were running on Linux, you could send a SIGQUIT signal to the java process - the app server registers a hook for this signal and shuts down normally when it gets the signal. This is the same thing that happens when you CTRL-C the app server. On Windows that is more difficult - I found some code that could do this but it worked for 32-bit XP only. I think that there are commercial Windows apps that will send a SIGQUIT to a process, but I have not tried any of them. Also, you then have to somehow capture the process id (which is easy on Linux).

[glyph5]

Thank you for your reply Peter.

Unlocking the jmx invoker might be feasible for our environment. I was wondering if you had any insight on how to achieve this?

I was trying to undo the steps provided in the following link: http://community.jboss.org/wiki/securethejmxconsole but I have not yet achieved success.

Any help would be greatly appreciated.

[peterj]

I have never tried to unsecure the jmx invoker in EAP, so the most I could do is point you to the wiki page that you mentioned. You might try comparing with GA to see what the differences are in the config files. You might also have to debug the shutdown code (if that is what you are using as a test case) to see exactly where the hangup is. Anyway, that is what I would do if I were there helping you.