Basic Negotiation (in toolkit) not using SPNEGO

[sridhar18]

Hello,

I'm trying to setup JBoss Negotiation at my company and I'm running into an issue using while using the jboss-negotiation-toolkit to test my stuff.

I'm using JBoss 4.2.3.GA and it's running on Solaris. I'm trying to access the toolkit from a different computer.

When I test the toolkit:

Basic Negotiation test FAILS (I get the NTLM reponse header back instead of SPNEGO)

Security Domain Test SUCCEEDS

Secure test FAILS (I see a warning in the logs: Unsupported negotiation mechanism 'NTLM' )

Shouldn't the Basic Negotiation Test succeed if my Security Domain Test succeeds?

Also, I haven't done any krb5.conf file changes on the server hosting the jboss instance? Is this required?

Any help would be highly appreciated. Thanks.

[jar349]

I'm assuming that you've already joined your Solaris box to hte domain and that you've followed the security-negotiation user guide in setting up jboss.  I'm also assuming that you've configured your browser (IE or firefox) correctly.

Given that, I had a similar problem.  It turns out that I had assigned a bad SPN to the jboss service account (http/[e-mail]).  As soon as I used uppercase HTTP in the SPN and re-exported the keytab, everything worked (HTTP/[e-mail]).

Also of note, I did not use the ktab utility for anything.  Simply using ktpass to map the SPN onto the service account and export a keytab was enough.

Hope that helps,

John

[sridhar18]

Thanks for the response John.

Yes I followed the JBoss Negotiaion user guide all the way. I also configured my IE and firefox correctly.

So when you say "i assume you joined your Solaris box to the domain" do you mean configuring the krb5.conf file on the solaris box? I haven't done that. Please let me know what you mean by that if it's different.

[jar349]

All I mean by that is that you've followed section 2.2.2.A of the user guide where it says "if you are running you JBoss installation on a host which is already configured to authenticate against a Kerberos KDC then you can skip this step."

By joining your box to the domain, you'll have implicitly had to do this.

If you haven't modified your krb5.conf file, you would need to follow one of the subsections of 2.2.2 to make sure that your jboss instance knows the location of the KDC.

I assume you've done one or the other.  Does this clear it up?

[sridhar18]

Sorry for not reading between the lines there.

Yes. I changed the system properties as per section 2.2.2.2 so that my JBoss instance knows where the KDC is located. The fact that the SecurityDomainTest of the toolkit is successful proves this is setup correctly.

Looks like I got it all setup correctly. I'm not sure what I'm missing

Below are the principals generated for my service account on AD

Registered  ServicePrincipalNames for CN=sadevldaps,OU=Service Accounts,OU=Company

,DC=company,DC=abc,DC=local:

    host/devhost01.company.abc.local

     HTTP/devhost01.company.abc.local

     host/devhost01

The generated keytab file has

         host/[e-mail]

So I'm using this name as my principal.

Do you see anything I'm missing? Thanks.

[jar349]

Based solely on my own experience, I recommend that you remove the two host SPNs from your service account and that you generate the keytab for the HTTP service principal.  The reason for this -  as I understand it - is because your browser constructs the service SPN during negotiation and it uses the HTTP service, not the HOST service.  Meanwhile, the keytab you've generated back on your solaris box is for the HOST principal, so when your server gets the credentials from the client, they're encrypted in such a way that only someone holding HTTP/devhost01.f.q.d.n can decrypt it, and your HOST principal can't, so negotiation fails.

This is all just my guess since I've only been working on my own integration for about 2 weeks now.  I know that the user guide says to add the HOST service principal to your service account, but I didn't and all 3 of my tests work.  The only SPN on my service account is the HTTP one and that's the principal I generate a keytab for.

The reason that I didn't is that the HOST service principal is - according to everything I've read - for the computer account that is joined to the domain.  So since I joined my RHEL box to the domain, there's an account in AD for it and IT is the account that has the HOST SPN assigned to it.

Now. you haven't joined your computer to the domain, so I don't know whether you should or should not add HOST to your service account's list of SPNs.  I would love for someone more knowledgeable than I to clarify the issue...

[sridhar18]

That's interesting. Thanks for passing that key information John. I'll give that a shot and see what happens.

[sridhar18]

Not much luck with this either.

Below are the updated principals generated for my service account on AD

Registered   ServicePrincipalNames for CN=sadevldaps,OU=Service Accounts,OU=Company

,DC=company,DC=abc,DC=local:

    HTTP/devhost01.company.abc.local

   

The generated  keytab file has

         HTTP/[e-mail]

Still can't get the Basic Negotiation Test successful.

[jar349]

The SPN on the account is HTTP/[e-mail] but your generated keytab has HTTP/[e-mail]

Instead, generate a keytab file that contains the exact SPN on the account - HTTP/[e-mail]

[sridhar18]

Thanks John. Let me give that a shot.

[sridhar18]

We have two principals for the service account in AD

Registered   ServicePrincipalNames for  CN=sadevldaps,OU=Service Accounts,OU=Company

,DC=company,DC=abc,DC=local:

    HTTP/devhost01.company.abc.local

    HTTP/devhost01

  

The generated  keytab file has

          HTTP/[e-mail]

This looks fine now right?

[jar349]

I don't know if that will work or not - you can always give it a shot.

However, my guess is that you'd have to put http://devhost01/ into your browser instead of http://devhost01.company.abc.local - I don't know.  Maybe the browser looks up the fully-qualified DNS name when it constructs the SPN to use?

If it works for you, great.  Otherwise, I'd just try re-generating the keytab for the service account making sure to use the full SPN: HTTP/[e-mail].

[sridhar18]

Thanks John for the help. We got it working finally. Problem still is that our jboss is clustered (two nodes) and it's behind a load balancer. So the browser is acting up at times when the request goes to a different node. We are looking into other options.

[mauljucken]

Hi Sridhar, may I ask what you finally did to solve it? Thx!

[mauljucken]

Hi Sridhar, John,

I got all three tests working with one Windows Account. With a different account (same client machine; same domain) only the second test runs successfully. How is that possible?

In order to make sure the issue is not related to any Internet Explorer (I have used IE7) setting, I have also tested with Firefox Portable 3.6.8. The only property I needed to set was "network.negotiate-auth.trusted-uris". The result was the same: Basic Negotiation works on one, but not on the other account.

account working: first request results in 401, second request results in 200

account not working: first request results in 401, second request results in 400

I am using jboss-5.1.0.GA and JBossNegotiation - 2.0.3.SP2.GA running on Solaris.

Any idea?

Thanks,

Robert