Red Hat Bugzilla – Bug 754849
as7: connections fail, as auth is now enabled by default
Last modified: 2015-11-01 19:42:13 EST
In current versions of as7.1, the management ports are now
a) protected by the need to authenticate
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
The plugin does already look for the (hardcoded) file mgmt.users.properties - but this needs now be determined from the above xml
b) the actual password is no longer in clear text, but hashed, as described in the mgmt-users.properties file
# By default the properties realm expects the entries to be in the format: -
# username=HEX( MD5( username ':' realm ':' password))
so it needs to be determined what to exactly send to the server.
workaround is to remove the security-realm attribute on the management port definitions above.
19097edb5d591dae5ae6fdf7565b682cd5b1506c in master
the as server resource now has an operation "installRhqUser" that installs a user with password into as7 that meets the requirements of the authentication defaults.
Of course, the user can also just enable the admin user in as7 by any other means and then go to the connection properties and and give the new credentials there.
verified on Version: 4.3.0-SNAPSHOT, Build Number: 74fe0df, EAP6 DR8. New Operation works as expected, plugin connects to both secured and non-secured EAP.
I do not know what I did (just reinstalled server and agents, having same version), but now installRHQUser does not work anymore.
This is what I get as an operation status
java.lang.Exception: / (Is a directory)
exception from comment #3 is raised only when EAP is unsecured, i. e. configuration looks like:
I know, when EAP is unsecured this way, we do not know which security realm should be used. I am not sure whether EAP team will produce more zips like it was before eap-XXX.zip and eap-XXX-noauth.zip. If they will, we should support both.
Or .. once we switch to DMR, there is no need to deal with credentials anymore. EAP server is able to detect whether client is local process and has read access to EAP6 home dir.
Did you try that in domain mode?
Please try again with the latest code base.
*** Bug 708306 has been marked as a duplicate of this bug. ***
Works for me,can not reproduce
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.