JBoss AD Login Module configuration

When configuring the JBOSS Ldap login module one, of the parameters is the ldap url that Jboss will use to connect to the Active Directory.

Anyway, when doing an all products in a server install (Jboss + AD + DB on same machine), I blindly enter the following URL for the LDAP connection. ldap://localhost:389 …

This is big troubles, because, using this URL the LDAP login module was always unable to authenticate users with the following error:

ldapctx javax.naming.PartialResultException: Unprocessed Continuation

It took me a while to solve the issue, and it’s quite simple.

First make sure that the domain name is able to be resolved, namely by the command ping domain.com or nslookup domain.com. The domain name must be the Active Directory configured domain name that the LDAP login module is going to connect to make user validation. If the above commands fail, just add the domain name and the AD IP to the hosts file.

Then replace the url from ldap://localhost:389 or from ldap://invalidADname:port to ldap://domain.com:389 and a follow reference configuration line.

Things must look like these now:

<application-policy name=”MyApplicationDomain”>
<login-module code=”org.jboss.security.auth.spi.LdapExtLoginModule” flag=”required” >
<module-option name=”java.naming.provider.url”>ldap://domain.com:389</module-option>
<module-option name=”java.naming.referral”>follow</module-option>
<module-option name=”java.naming.security.authentication”>simple</module-option>


Issue solved…

Jboss AS 5.0.1 multiple instances on the same machine

If doing tests with multiple Jboss instances on the same machine, for example for clustering tests, each instance must use it’s own set of binding ports.

The easiest  way to do this is to pass the port binding through command line to the run.bat/run.sh, for example:




Jboss server 4.0.2 – Enabling access logs

On Jboss AS 4.0.2 servers, the HTTP access logs, that shows requests, origin IP, time, and so on are disabled by default.

For enabling the log, we need to go to the server.xml file that is on deploy/jbossweb-tomcat55.sar. For example if we are using the default Jboss instance, we need to go to: /opt/jboss/server/default/deploy/jbossweb-tomcat55.sar

Editing the server.xml file that is on this directory we need to enable the section of the AccessLog Valve:

From this:

<!-- Access logger -->
 <Valve className="org.apache.catalina.valves.FastCommonAccessLogValve"
 prefix="localhost_access_log." suffix=".log"
 pattern="common" directory="${jboss.server.home.dir}/log"
 resolveHosts="false" />

to this:

<!-- Access logger -->
 <Valve className="org.apache.catalina.valves.FastCommonAccessLogValve"
 prefix="localhost_access_log." suffix=".log"
 pattern="common" directory="${jboss.server.home.dir}/log"
 resolveHosts="false" />

By other words, by uncomment this XML section.
Restarting Jboss will make the access log file to appear on the log directory of the instance. For the example, this would be default/log directory.

The above configuration will create a common formatted log, but we can make the log the way we like, for example:

<Valve  className="org.apache.catalina.valves.AccessLogValve"
 prefix="access_log." suffix=".log"
 pattern="'%{X-Forwarded-For}i' %h %p %l %u %t %r %s %b '%{Referer}i'  '%{User-Agent}i'"
 resolveHosts="false" />

Note that we are using a different class for the log in this example.
For more information check out this: http://tomcat.apache.org/tomcat-4.1-doc/config/valve.html

Running Jboss on port 80 on Linux

Some customers have network policies for traffic shaping that severely restrict network performance on the default port 8080 used by Jboss. This is because most internet access use proxy’s on that port.

So to avoid internal JBoss servers to be hit by traffic shaping, moving JBoss to port 80 or other is the solution.

Editing the server.xml file and changing the default 8080 port to 80 for example is easy, but on Linux brings an additional problem: ports below 1024 are privileged which means that JBoss must run as the user root… a big no no…

So how do you keep Jboss running as a non privileged user and bound to port 80?

Well after a bit of research on our friend Google it’s quite easy:

Normally I use the boot script located here: Jboss Boot Script .

Before the line su -l jboss -c .. which starts Jboss running under the user jboss, just put the following line:

iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080

(EDIT: Please note that it’s dash dash (- -) before the dport and to-port parameter, and  not a single dash (-) ).

This will just redirect any external requests on port 80 to port 8080, and all of this with jboss running securely on it’s own user… It also can be done for port HTTPS 443 so it maps to 8443.

Easy, simple and no messing around on server.xml.

On Windows, I think your out of luck, but hey, anyone can bind to port 80…

JBoss XA datasources and mbean error

When deploying an application on Jboss that used Oracle and XA datasources, the following error croped up:

org.jboss.deployment.DeploymentException: Trying to install an already registered mbean: jboss.jca:service=OracleXAExceptionFormatter

It took me a while to found out what the issue was, and the lead to the solution was that the error moved from datasource to datasource according to it’s name, namely the xml definition filename.

The issue is quite simple: XA datasources can only have one mbean definition for the OracleXAExceptionFormatter, so choose one, and only one and put the required definition:

<mbean code=”org.jboss.resource.adapter.jdbc.vendor.OracleXAExceptionFormatter”
<depends optional-attribute-name=”TransactionManagerService”>jboss:service=TransactionManager</depends>

Remove this definition from any other XA datasource and the error should disappear and all datasources can bound now without any errors.

JBoss and JAAS debug

I’m having a lot of problems debugging an application that is supposedly to be able to run on JBoss…

One of the main issues is the authentication process between the Web Container and the EJB container. For authentication the Java JAAS architecture is used. Jboss has different configuration files than BEA or WebSphere, namely the configuration file login-config.xml. In this file an application policy is defined, namely how users are validated: if they use a file with user/password, database or LDAP. In this file an application policy used by the EJB and WEB cointaner must be defined (it can be the same).

On the Web container/application side, the jboss-web.xml file on the WEB-INF folder of the Web application has the Authentication domain used for login that, of course, must match the other configuration files, in this case the login-config.xml file and the web.xml file. The web.xml file must also protect the resources that access the EJB container. This means that users must pass container authentication so a JAAS instantiation is built.

So the quick tip is:

1) Make sure that everything connects: login-config.xml<-> jboss-web.xml <-> web.xml

Content of jboss-web.xml file on the Web application WEB-INF directory:


2) Make sure that on your web.xml file the <realm-name> on the <login-config> section matches the name on the security domain, in this case APPLICATION_DOMAIN.

3) On Jboss login-config.xml file a there should be also an <application-policy name=”APPLICATION_DOMAIN”> with the configuration that you need (Database module, LDAP module.

But this might be not enough, so if you need to debug the JAAS, you can add to the log4j.xml file the following:

On the log4j.xml file add the following sections:

<category name="org.jboss.security">
    <priority value="TRACE" class="org.jboss.logging.XLevel"/>
    <appender-ref ref="SECURITY_F"/>
</category> <appender name="SECURITY_F"
    <param name="Append" value="true"/>
    <param name="DatePattern" value="'.'yyyy-MM-dd"/>
    <param name="File"
    <layout class="org.apache.log4j.PatternLayout">
        <param name="ConversionPattern"
            value="%d{ABSOLUTE} %-5p [%c] %m%n"/>

This is more or les in the middle of the file, just where the <category-name> section begins.

With this configuration a new log file named jboss.security.log will be created with the JAAS information, so you can see what’s going on.