required or requisite jaas LDAPLoginModule not throwing FailedLoginException when user fails authentication - ldap

TL;DR: Why does the LDAPLoginModule (apparently) not throw a FailedLoginException when a user fails to be authenticated?
I have overridden the default "karaf" jaas realm in jboss fuse 6.2.[0|1]. My configuration has 2 modules:
an instance of org.apache.karaf.jaas.modules.ldap.LDAPLoginModule to authenticate the user via an LDAP-to-Active-Directory link
MyCustomLoginModule extends AbstractKarafLoginModule - a second module to check for locally-defined roles for an authentic user.
The latter works fine. However, when the LDAPLoginModule fails to authenticate a user, they are still allowed to pass. This is the case no matter what combination of required/requisite and ordering I use for the 2 modules.
An example of the behavior:
I define my modules like:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd" >
. . .
<jaas:config . . . >
. . .
<jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule"
flags="requisite">
. . .
properties herein as commonly seen for ldap-ad
. . .
</jaas:module>
<jaas:module className="com.abc.xyz.MyCustomLoginModule"
flags="requisite">
. . . nothing shocking in here either . . .
</jaas:module>
</jaas:config>
</blueprint>
This blueprint file and the MyCustomLoginModule are within a bundle that has been added to a feature that, itself, has been added to the etc/org.apache.karaf.features.cfg along with the associated remote mvn repo
I put "userX=admin" into the flat-file that MyCustomLoginModule uses to assign roles.
I try to login (via hawtio web console) as userX, but enter the wrong password.
Logged output is like:
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Get the user DN.
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Bind user (authentication).
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Setting up SSL
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Set the security principal for CN=...
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Binding the user.
WARN | LDAPLoginModule | org.apache.karaf.jaas.modules | User userX authentication failed.
javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr:
DSID-0C0903D9, comment: AcceptSecurityContext error, data 52e, v2580]
^^ as expected, LDAP Authentication fails--as per the WARN message and the "52e" error code ^^
HOWEVER, execution continues and I am successfully logged into the hawtio web console as userX!
Alternatively, I can define a user=role mapping in my custom, local file, where the user does not even exist in our Active Directory.... something simple, like: admin=admin. I then go through the same process. This time the LDAP module throws no Exceptions, but logs:
WARN | LDAPLoginModule | org.apache.karaf.jaas.modules | User admin not found in LDAP.
but yet again, execution continues and I am successfully logged into the hawtio web console, this time as "admin."
Lastly... Using a valid Active Directory user, but not one defined in my custom, local file, produces expected logging like:
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Get the user DN.
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Setting up SSL
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Looking for the user in LDAP with
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | base DN:XXXXXXXXXX
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | filter: (&(|(samAccountName=<valid-username>)(userPrincipalName=<valid-username>)(cn=<valid-username>))(objectClass=user))
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Found the user DN.
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Bind user (authentication).
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Setting up SSL
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Set the security principal for CN=<valid-username>,...
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Binding the user.
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | User <valid-username> successfully bound.
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Setting up SSL
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | Looking for the user roles in LDAP with
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | base DN:XXXXXXXX
DEBUG | LDAPLoginModule | org.apache.karaf.jaas.modules | filter: (uniqueMember=CN=<valid-username>)
WARN | Authenticator | io.hawt.hawtio-web | Login failed due User <valid-username> has no local roles defined
where that last line is because my module throws a FailedLoginException if the user has no roles defined in the aforementioned custom file
I also noted that if the LDAPLoginModule's configuration is bad--e.g., a bad password is given for the system account that searches ldap for the user--then it DOES halt the login process, by throwing a FailedLoginExcpetion like:
WARN | Authenticator | io.hawt.hawtio-web | Login failed due Can't connect to
the LDAP server: [LDAP: error code 49 - 80090308: LdapErr:
DSID-0C0903D9, comment: AcceptSecurityContext error, data 52e, v2580]
note that this is logged by the Authenticator (not the LDAPLoginModule as above
...so at length, the question is -- why does the LDAPLoginModule (apparently) not throw a FailedLoginException when a user fails to be authenticated? I'd think that this is what's needed--does anyone disagree? Is there some additional bit of configuration that the LDAPLoginModule needs in order to be effective?
Has anyone else had this issue with JBoss FUSE v6.2.1 or karaf v2.4? Were you able to resolve within that version? If not, was it resolved by up-leveling to a newer version of either?
Thanks,
Hans

Though not an exact answer to the question asked, the following is an effective workaround.
Instead of using LDAPLoginModule directly, create a class that extends it and #Override the login() method--which returns a boolean... This boolean is set to false if the user being searched for does not exist, or has provided an incorrect password. Thus, simply call super.login() and if the result is false, then throw a FailedLoginException.

Related

cannot change properties of db-32.log

I am getting below Error in Fuse log. In order to solve it I thought I will give permission to db-32.log file but it doesn't allow me to change permission of this file. Instead I get a warning
"cannot change properties of db-32.log"
Please find below the error log
07:17:20,163 | INFO | AMQ-1-thread-1 | ActiveMQServiceFactory | 197 -
io.fabric8.mq.mq-fabric - 1.2.0.redhat-621084 | Broker amq failed to start.
Will try again in 10 seconds
07:17:20,163 | ERROR | AMQ-1-thread-1 | ActiveMQServiceFactory | 197 -
io.fabric8.mq.mq-fabric - 1.2.0.redhat-621084 | Exception on start:
/opt/install/jboss/jboss-fuse-6.2.1.redhat-084/data/amq/kahadb/db-32.log
(Permission denied)
java.io.FileNotFoundException: /opt/install/jboss/jboss-fuse-6.2.1.redhat-
084/data/amq/kahadb/db-32.log (Permission denied)
at java.io.RandomAccessFile.open0(Native Method)[:1.8.0_91]
at java.io.RandomAccessFile.open(RandomAccessFile.java:316)[:1.8.0_91]
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:243)[:1.8.0_91]
Do you restart the broker under a different user than was previously used to run the broker?
Make sure the OS level user that runs the broker has full access to the configured KahaDB folder on the file system.

Karaf w/ LDAP Auth

I'm trying to setup karaf (4.0.9) to authenticate/authorize users via ldap/active directory.
I've copied the following ldap-module.xml to the deploy directory per https://karaf.apache.org/manual/latest/#_available_realm_and_login_modules:
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">
<jaas:config name="karaf" rank="1">
<jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule" flags="sufficient">
initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
connection.username=cn=ldapsearch,cn=users,dc=eng,dc=net
connection.password=****
connection.protocol=
connection.url=ldap://server:389
user.base.dn=dc=eng,dc=net
user.filter=(samaccountname=%u)
user.search.subtree=true
user.debug=true
role.base.dn=dc=eng,dc=net
role.name.attribute=cn
role.filter=(member=%fqdn)
role.search.subtree=true
role.mapping=jtAdmins=admin,user,operator
authentication=simple
debug=true
</jaas:module>
</jaas:config>
</blueprint>
I see the logs, and I can see the LDAP login on the realm, so I'm confident the config is at least being used
karaf#root(jaas)> jaas:realm-list
Index | Realm Name | Login Module Class Name
-----------------------------------------------------------------------
1 | karaf | org.apache.karaf.jaas.modules.ldap.LDAPLoginModule
When I try to ssh in, I get the following logs (truncated), and I can see shark the LDAP communications:
2017-07-31 16:50:39,229 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Get the user DN.
2017-07-31 16:50:39,238 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Looking for the user in LDAP with
2017-07-31 16:50:39,238 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | base DN: dc=eng,dc=net
2017-07-31 16:50:39,238 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | filter: (samaccountname=jtAdmin)
2017-07-31 16:50:39,244 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Found the user DN.
2017-07-31 16:50:39,245 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Bind user (authentication).
2017-07-31 16:50:39,245 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Set the security principal for CN=jtAdmin,CN=Users,dc=eng,dc=net
2017-07-31 16:50:39,245 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Binding the user.
2017-07-31 16:50:39,254 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | User jtAdmin successfully bound.
2017-07-31 16:50:39,256 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Looking for the user roles in LDAP with
2017-07-31 16:50:39,256 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | base DN: dc=eng,dc=net
2017-07-31 16:50:39,256 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | filter: (member=CN=jtAdmin,CN=Users,DC=eng,DC=net)
2017-07-31 16:50:39,359 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | User jtAdmin is a member of role Domain Computers
2017-07-31 16:50:39,359 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Parse role mapping jtAdmin=admin,user,operator
2017-07-31 16:50:39,359 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Parse role mapping jtAdmin=admin,user,operator
2017-07-31 16:50:39,359 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | User jtAdmin is a member of role Domain Controllers
...
2017-07-31 16:50:39,364 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Parse role mapping jtAdmins=admin,user,operator
2017-07-31 16:50:39,364 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | Parse role mapping jtAdmins=admin,user,operator
2017-07-31 16:50:39,364 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | LDAP role jtAdmins is mapped to Karaf role admin
2017-07-31 16:50:39,364 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | LDAP role jtAdmins is mapped to Karaf role user
2017-07-31 16:50:39,365 | DEBUG | 8]-nio2-thread-9 | LDAPLoginModule | 35 - org.apache.karaf.jaas.modules - 4.0.9 | LDAP role jtAdmins is mapped to Karaf role operator
I can see LDAP authorize my user, but it seems I don't have permission to login. I thought the role.mapping would handle mapping my LDAP/AD membership to Karaf roles, but that doesn't seem to allow me access. Webconsole also attempts to allow access, but ultimately fails.
What config am I missing to map the LDAP/AD user roles to enable ssh karaf/console for my user? Do I need another login module? And how might I do this dynamically (not using hard-coded role.mapping in the ldap-module.xml bundle)?
Ideally, I'd also like to be able to give ldap OR local users access simultaneously, but I realize that might not be possible.
As luck would have it, I managed to track down the root cause. Thanks to the folks on the karaf IRC channel that let me think out loud.
Ultimately, I believe the root cause is this exception:
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ...
I only actually see this exception in the webconsole handler, and NOT in the ssh/shell handler (but ssh doesn't work either, so...)
The exception is coming from LDAPCache.java (namingEnumeration.hasMore(), ~line 259) and ultimately from
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2914)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
This exception is propagated to the caller. Since I can't very well change the JVM, I'm borrowing a suggestions/solution of adding a config option to ignorePartialNameResult regarding this exception. I don't quite understand why there is a partial name result, but I saw one comment implying that the error was due to role.base.dn being the same level as the user.base.dn which is true in my case. After catching the exception, and returning the existing roleList, I am able to successfully login w/ ldap users.

Connecting to Kerberized solr on cloudera from karaf

I'm trying to connect to Solr (non cloud) which has Kerberos enabled from my SolrJ application running in Karaf container.
With Kerberos disabled, I'm able to connect fine.
With Kerberos enabled, I'm able to connect outside of Karaf by running a simple SolrClient class.
But its not working from within karaf.
Code:
System.setProperty("java.security.auth.login.config", "<path to jaas.conf file>");
String urlString = "http://<IP>:8983/solr/test";
SolrServer server = new HttpSolrServer(urlString);
QueryResponse sresponse = server.query( squery );
Exception in Karaf on trying to query:
2016-12-15 15:02:17,969 | WARN | l Console Thread | RequestTargetAuthentication | ? ? | 271 - wrap_mvn_org.apache.httpcomponents_httpclient_4.3.2 - 0.0.0 | NEGOTIATE authentication error: No valid credentials p
rovided (Mechanism level: No valid credentials provided (Mechanism level: Invalid option setting in ticket request. (101)))
2016-12-15 15:03:10,731 | ERROR | l Console Thread | Error:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSol
rException: Expected mime type application/octet-stream but got text/html. Apache Tomcat/6.0.44 - Error report HTTP Status 401 - Authentication requiredtype Status reportmessage Authentication requireddescription This request requires HTTP authentication.Apache Tomcat/6.0.44

Removing an unnecessary login module in Apache Karaf

This question was originally posted on the karaf users mailing list, but I didn't get an answer:
http://karaf.922171.n3.nabble.com/Deleting-an-unnecessary-login-module-td4033321.html
I would like to remove a login module (PublicKeyLoginModule) from the default jaas karaf realm.
According to the docs:
http://karaf.apache.org/manual/latest/developers-guide/security-framework.html
“So if you want to override the default security configuration in Karaf (which is used by the ssh shell, web console and
JMX layer), you need to deploy a JAAS configuration with the name name="karaf" and rank="1".”
However, when I do this new modules are added rather than replacing the existing ones.
When the blueprint below is loaded via either the deploy dir or via inclusion in a bundle (created using Maven by including the blueprint from the following path)
src\main\resources\OSGI-INF\blueprint\context.xml
I get the following:
karaf#root()> jaas:realm-list
Index | Realm Name | Login Module Class Name
-----------------------------------------------------------------------------------
1 | karaf | org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
2 | karaf | org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
3 | karaf | org.apache.karaf.jaas.modules.ldap.LDAPLoginModule
What I would like to see is either
karaf#root()> jaas:realm-list
Index | Realm Name | Login Module Class Name
-----------------------------------------------------------------------------------
1 | karaf | org.apache.karaf.jaas.modules.ldap.LDAPLoginModule
Or, if there were a way to explicitly delete a module:
karaf#root()> jaas:realm-list
Index | Realm Name | Login Module Class Name
-----------------------------------------------------------------------------------
1 | karaf | org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
2 | karaf | org.apache.karaf.jaas.modules.ldap.LDAPLoginModule
This is the blueprint:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">
<type-converters>
<bean class="org.apache.karaf.jaas.modules.properties.PropertiesConverter"/>
</type-converters>
<!-- Allow usage of System properties, especially the karaf.base property -->
<ext:property-placeholder placeholder-prefix="$[" placeholder-suffix="]"/>
<!-- AdminConfig property place holder for the org.apache.karaf.jaas -->
<cm:property-placeholder persistent-id="org.apache.karaf.jaas" update-strategy="none">
<cm:default-properties>
<cm:property name="example.group" value="example-group-value"/>
</cm:default-properties>
</cm:property-placeholder>
<jaas:config name="karaf" rank="1">
<jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule" flags="required">
connection.url = ldap://ldap.example.com:389
user.base.dn = o= example.com
user.filter = (uid=%u)
user.search.subtree = true
role.base.dn = ou=applications,l=global,o= example.com
role.filter = (&(objectClass=groupOfUniqueNames)(uniqueMember=*uid=%u*)(cn=${ example.group}))
role.name.attribute = cn
role.search.subtree = true
authentication = simple
</jaas:module>
</jaas:config>
</blueprint>
karaf#root()> shell:info
Karaf
Karaf version 3.0.0
Karaf home ***
Karaf base ***
OSGi Framework org.apache.felix.framework - 4.2.1
Same issue on Karaf 3.0.1
I'd welcome any suggestions. Creating a whole new realm is a possibility, but for policy reasons I'd prefer not to have the PublicKeyLoginModule visible in the runtime at all.
As a workaround you can try this:
Default karaf realm is registered in org.apache.karaf.jaas.module bundle with blueprint.
Find the original JaasRealm service named karaf from the service registry and unregister it; then register your own realm using the above blueprint.

Red Hat 7 with JBoss A-MQ 6.1: management console is not accessible

We're having the same problem as this OP: JBoss ActiveMQ on Red Hat - Unable to access AMQ Web Console, however that post doesn't indicate how he solved the problem.
We're trying to evaluate JBoss A-MQ, and have installed RHEL 7 with A-MQ 6.1 according to their installation guide. Everything works locally, e.g. the sample producer/consumer tests succeed in the Verifying the Installation step.
However, we cannot access the management console, even after configuring the remote user. We did have to add a JAVA_OPTIONS entry to setenv to override the default IPv6 sockets, and netstat shows that the service is now listening on the tcp socket instead of tcp6:
File /opt/jboss-a-mq-6.1.0.redhat-379/bin/setenv now contains:
JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"
export JAVA_OPTS
# netstat -paunt | grep 8181
tcp 0 0 0.0.0.0:8181 0.0.0.0:* LISTEN 10698/java
We can ping the box from other systems, however attempting to open a telnet session on port 8181 times out. The management console URLs we've tried are:
http://172.16.100.110:8181/hawtio
http://172.16.100.110:8181
but neither work. What are we missing?
Here are entries from amq.log containing hawt, which seem like it is starting things up correctly:
$ grep hawt amq.log
2014-09-09 11:32:35,778 | INFO | FelixStartLevel | HttpServiceFactoryImpl | .internal.HttpServiceFactoryImpl 35 | 98 - org.ops4j.pax.web.pax-web-runtime - 3.0.6 | Binding bundle: [io.hawt.hawtio-web [146]] to http service
2014-09-09 11:32:35,860 | INFO | pool-10-thread-1 | ConfigManager | io.hawt.system.ConfigManager 32 | 146 - io.hawt.hawtio-web - 1.2.0.redhat-379 | Configuration will be discovered via system properties
2014-09-09 11:32:35,863 | INFO | pool-10-thread-1 | JmxTreeWatcher | io.hawt.jmx.JmxTreeWatcher 63 | 146 - io.hawt.hawtio-web - 1.2.0.redhat-379 | Welcome to hawtio 1.2-redhat-379 : http://hawt.io/ : Don't cha wish your console was hawt like me? ;-)
2014-09-09 11:32:35,865 | INFO | pool-10-thread-1 | UploadManager | io.hawt.jmx.UploadManager 40 | 146 - io.hawt.hawtio-web - 1.2.0.redhat-379 | Using file upload directory: /opt/jboss-a-mq-6.1.0.redhat-379/data/tmp/uploads
2014-09-09 11:32:35,868 | INFO | pool-10-thread-1 | AuthenticationFilter | io.hawt.web.AuthenticationFilter 84 | 146 - io.hawt.hawtio-web - 1.2.0.redhat-379 | Starting hawtio authentication filter, JAAS realm: "karaf" authorized role: "admin" role principal classes: ""
2014-09-09 11:32:35,965 | INFO | FelixStartLevel | HttpServiceFactoryImpl | .internal.HttpServiceFactoryImpl 35 | 98 - org.ops4j.pax.web.pax-web-runtime - 3.0.6 | Binding bundle: [io.hawt.hawtio-karaf-terminal [148]] to http service
2014-09-09 11:32:35,987 | INFO | pool-10-thread-2 | ConfigManager | io.hawt.system.ConfigManager 32 | 148 - io.hawt.hawtio-karaf-terminal - 1.2.0.redhat-379 | Configuration will be discovered via system properties
2014-09-09 11:32:35,988 | INFO | pool-10-thread-2 | AuthenticationFilter | io.hawt.web.AuthenticationFilter 84 | 148 - io.hawt.hawtio-karaf-terminal - 1.2.0.redhat-379 | Starting hawtio authentication filter, JAAS realm: "karaf" authorized role: "admin" role principal classes: ""
2014-09-09 11:32:35,996 | WARN | FelixStartLevel | ConfigFacade | io.hawt.config.ConfigFacade 23 | 149 - io.hawt.hawtio-maven-indexer - 1.2.0.redhat-379 | No ConfigFacade constructed yet so using default configuration for now
2014-09-09 11:32:36,015 | INFO | pool-10-thread-2 | LoginServlet | io.hawt.web.LoginServlet 55 | 148 - io.hawt.hawtio-karaf-terminal - 1.2.0.redhat-379 | hawtio login is using default HttpSession timeout
2014-09-09 11:32:36,128 | INFO | pool-10-thread-1 | hawtio-web - 146} | lipse.jetty.util.log.JavaUtilLog 75 | 90 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | jolokia-agent: No access restrictor found at classpath:/jolokia-access.xml, access to all MBeans is allowed
2014-09-09 11:32:36,191 | INFO | pool-10-thread-1 | LoginServlet | io.hawt.web.LoginServlet 55 | 146 - io.hawt.hawtio-web - 1.2.0.redhat-379 | hawtio login is using default HttpSession timeout
2014-09-09 11:32:39,227 | INFO | de startup timer | MavenIndexerFacade | maven.indexer.MavenIndexerFacade 98 | 149 - io.hawt.hawtio-maven-indexer - 1.2.0.redhat-379 | Storing maven index files in local directory: /opt/jboss-a-mq-6.1.0.redhat-379/data/mavenIndexer
2014-09-09 11:32:39,621 | INFO | de startup timer | MavenIndexerFacade | maven.indexer.MavenIndexerFacade 148 | 149 - io.hawt.hawtio-maven-indexer - 1.2.0.redhat-379 | Updating the maven indices. This may take a while, please be patient...
2014-09-09 11:32:39,852 | INFO | de startup timer | MavenIndexerFacade | maven.indexer.MavenIndexerFacade 185 | 149 - io.hawt.hawtio-maven-indexer - 1.2.0.redhat-379 | Completed updating 2 maven indices.
OMG, it was the firewall on the local server.
After spending the day scouring the web for ideas, trying to figure out what was wrong with my configuration, in desperation I finally thought I should try disabling the firewall and see what happens. So I shut it down with the command:
sudo service firewalld stop
and suddenly I could access the management console! I tried the default URL, and it worked:
http://172.16.100.110:8181
d'oh!