-
1. Re: Basic Negotiation (in toolkit) not using SPNEGO
jar349 Apr 30, 2010 9:59 AM (in response to sridhar18)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/jboss.example.com@EXAMPLE.COM). As soon as I used uppercase HTTP in the SPN and re-exported the keytab, everything worked (HTTP/jboss.example.com@EXAMPLE.COM).
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
-
2. Re: Basic Negotiation (in toolkit) not using SPNEGO
sridhar18 Apr 30, 2010 10:20 AM (in response to jar349)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.
-
3. Re: Basic Negotiation (in toolkit) not using SPNEGO
jar349 Apr 30, 2010 11:05 AM (in response to sridhar18)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?
-
4. Re: Basic Negotiation (in toolkit) not using SPNEGO
sridhar18 Apr 30, 2010 11:43 AM (in response to jar349)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.localHTTP/devhost01.company.abc.localhost/devhost01The generated keytab file has
host/devhost01@COMPANY.ABC.LOCAL
So I'm using this name as my principal.
Do you see anything I'm missing? Thanks.
-
5. Re: Basic Negotiation (in toolkit) not using SPNEGO
jar349 Apr 30, 2010 12:23 PM (in response to sridhar18)1 of 1 people found this helpfulBased 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...
-
6. Re: Basic Negotiation (in toolkit) not using SPNEGO
sridhar18 Apr 30, 2010 2:47 PM (in response to jar349)That's interesting. Thanks for passing that key information John. I'll give that a shot and see what happens.
-
7. Re: Basic Negotiation (in toolkit) not using SPNEGO
sridhar18 Apr 30, 2010 3:51 PM (in response to 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.localThe generated keytab file has
HTTP/devhost01@COMPANY.ABC.LOCAL
Still can't get the Basic Negotiation Test successful.
-
8. Re: Basic Negotiation (in toolkit) not using SPNEGO
jar349 May 3, 2010 10:41 AM (in response to sridhar18)1 of 1 people found this helpfulThe SPN on the account is HTTP/devhost01.company.abc.local@COMPANY.ABC.LOCAL but your generated keytab has HTTP/devhost01@COMPANY.ABC.LOCAL
Instead, generate a keytab file that contains the exact SPN on the account - HTTP/devhost01.company.abc.local@COMPANY.ABC.LOCAL
-
9. Re: Basic Negotiation (in toolkit) not using SPNEGO
sridhar18 May 3, 2010 10:44 AM (in response to jar349)Thanks John. Let me give that a shot.
-
10. Re: Basic Negotiation (in toolkit) not using SPNEGO
sridhar18 May 3, 2010 11:40 AM (in response to 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.localHTTP/devhost01The generated keytab file has
HTTP/devhost01@COMPANY.ABC.LOCAL
This looks fine now right?
-
11. Re: Basic Negotiation (in toolkit) not using SPNEGO
jar349 May 3, 2010 3:34 PM (in response to sridhar18)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/devhost01.company.abc.local@COMPANY.ABC.LOCAL.
-
12. Re: Basic Negotiation (in toolkit) not using SPNEGO
sridhar18 May 13, 2010 2:35 PM (in response to jar349)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.
-
13. Re: Basic Negotiation (in toolkit) not using SPNEGO
mauljucken Jul 29, 2010 7:36 AM (in response to sridhar18)Hi Sridhar, may I ask what you finally did to solve it? Thx!
-
14. Re: Basic Negotiation (in toolkit) not using SPNEGO
mauljucken Aug 3, 2010 9:16 AM (in response to sridhar18)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