NTLM Basic authentication fails behind http apache only when load balancing

Question

I set up an apache http reverse proxy and load balance.

I already know that Reverse Proxying will break NTLM dialog, and leads to something like Basic Auth against Active Directory, which is sufficient for me.

NTLM is supported by jCIFS on my JBoss, and is working fine when:

• I use my JBoss address directly (10.1.2.12:8080/myapp)
• I use my apache RP address (myapp-homintranet.myorg.com/myapp) without a 2nd member

But since adding second member to load balancing, it don't work at all !

<VirtualHost *:80>

  ServerName myapp-homintranet.myorg.com
  ServerAlias myapp-homintranet

  ProxyRequests Off
  ProxyPass /myapp balancer://jbosscluster/myapp stickysession=JSESSIONID nofailover=On
  ProxyPassReverse /myapp http://server01.myorg.com:8080/myapp

  #Conf load-balancing Jboss
  <Proxy balancer://jbosscluster>
    BalancerMember http://server01.myorg.com:8080
    BalancerMember http://server02.myorg.com:8080
    ProxySet lbmethod=byrequests
  </Proxy>

</VirtualHost>

If I remove the second member (server 02), it works again.

I don't know how to solve this. Can someone help me ?

PS : If there is a way to highlight apache/conf syntax, tell me !

---

My workers conf, in case ...

# Define list of workers that will be used
# for mapping requests
worker.list=loadbalancer,status

# Define Node1 = server01
# modify the host as your host IP or DNS name.
worker.node1.port=8009
worker.node1.host=10.1.2.11
worker.node1.type=ajp13
worker.node1.lbfactor=1
#worker.node1.cachesize=10

# Define Node2 = server02
# modify the host as your host IP or DNS name.
worker.node2.port=8009
worker.node2.host=10.1.2.12
worker.node2.type=ajp13
worker.node2.lbfactor=1
#worker.node1.cachesize=10


# Load-balancing behaviour
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=SERVER1_node1,SERVER2_node1
worker.loadbalancer.sticky_session=1

# Status worker for managing load balancer
worker.status.type=status

Answer 1

I didn't find any real solution to this issue. We just changed our auth method (using Kerberos and mod_auth_kerb, which were painful to configure).

I think there was an issue between the virtual IP and the Windows realm. We also encountered this problem with Kerberos. But we have not tested it again.

I hope this will help someone.