Filter fails with Apache mod_proxy and JBoss running as a service

Dec 22, 2011 at 4:54 PM

Does anyone know why in some cases SSO consistently fails when I hit a my jboss server through a secondary apache server using mod-proxy?

What we were able to determine is:

  1. If the “filter” parameters are specified as “Negotiate NTLM” then we consistently get challenged with the Browser login window.
  2. However, if I revers the order in #1 to “NTLN Negotiate” then SSO is working. However , every authetication will not be NTLM and negotiate does not even appear to get in the picture.

To make things even more bizarre we noticed:

  1. If we run the Jboss “service” under the “Local System account” and users hit the apache forwarder then SSO FAILS when the order is “Negotiate and NTLM”. 
  2. However, if we run the Jboss service under a “local Admin Account” then things begin to magically work again.
  3. Additionally if we go directly to the Jboss server then we do not have any problems and SSO works using “Negotiate and NTLM”. 
  4. if we run Jboss under a DOS console not using “Local System Account” then things work well again using “Negotiate and NTLM”.
  5. If Jboss and apache are on the same server then we do not have any issues

Is this an issue with the AD policies or trust?

I am completely at loss things appear to be pointing to the an issue with the “local system account” but I do not understand how and why.

Thanks in advance

max

Coordinator
Dec 23, 2011 at 7:57 PM

Negotiate is choosing Kerberos, which has some obscure protections to prevent man-in-the-middle attacks, so your proxy is in the way and that's why you're getting failed auth. 

It works on the same machine, there's no man in the middle. 

Local system account is not a domain account, and probably can't talk to AD.

Local admin account is probably a domain account? Or at least has some way to talk to AD.

Going directly to the JBoss server works because there's no proxy.

On a DOS console you're running under a domain account, it works.

Proxy authentication is another beast and I really don't know what Waffle can/should do to work in that scenario. Maybe someone in building 41 in Redmond knows :) I would just use NTLM and get it over with. It's not really less secure than Kerberos. 

It's a lot to digest :)

Dec 27, 2011 at 2:03 PM

Thanks dblock for your reply this make sense now kind of :-).

Our "Local Admin Account" is not a domain account but allows us to negotiate via kerberose there must be something under the cover and as you said the guys in BLDG 41 problay know. Will fall back to NTLM

thanks again,

max

Coordinator
Dec 27, 2011 at 2:08 PM

Actually since the box is a member of the domain it has a domain account. Being an admin probably means using that account to talk to ad. I just don't know how it actually works underneath.

On Dec 27, 2011 10:03 AM, "mmirabito" <notifications@codeplex.com> wrote:

From: mmirabito

Thanks dblock for your reply this make sense now kind of :-).

Our "Local Admin Account" is not a domain account but allows us to negotiate via kerberose there must be something under the cover and as you said the guys in BLDG 41 problay know. Will fall back to NTLM

thanks again,

max

Read the full discussion online.

To add a post to this discussion, reply to this email (waffle@discussions.codeplex.com)

To start a new discussion for this project, email waffle@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com