SSO Adventures in Luxembourg

by dimikagi

I spent the better part of a week in October in Luxembourg, and most of this post was written on October 21st, 2009.  However, its been sitting in my Drafts queue this whole time.

In any case, it was about what I expected.  It was a cute little city/country nestled inside of Europe with a good mix of people from various other countries.  The one thing that did truly surprise me was a Greek developer name Michael P.  What surprised me most was that he was able to take Quest VSJ and get it running in about 30 minutes, with minimal instructions, and having a machine on a different domain, with no DNS resolution to the AD domain where VSJ was installed.

Now, I should point out that Barry G and I have gone out of our way to make VSJ accessible to customers trying it out the first time, but its still a hard product for developers to truly ‘grok.’  And the product itself is not difficult but the whole notion of ‘Java using Microsoft for authentication and authorisation’ seems to really trouble some people.  Even though its really a code library, like many others, and is often used as a servlet filter, like many others, developers get really hung up with the fact that its working with Active Directory.  Its some sort of stumbling block for them, even though it behaves like any other piece of Java code.

But Mike just nodded when I told him it was a servlet filter, and grabbed the USB stick from me with the binaries.  One of a few developers I’ve met in a long time that didn’t subscribe to any sort of ‘religion.’

Within 10 minutes, he came back saying he was getting licensing errors!  Perfect – it was ‘as expected’ as I forgot to give him a file called vsj-license.jar and he disappeared when I did.  About 5 minutes after that, he came back with ‘access denied’ error messages, which meant that he installed it, and it was behaving ‘as expected.’

Some things Mike saw when he first tried to log in turn into good tips to keep in mind if you’re actually deploying or testing VSJ:

  • Kerberos didn’t work, which was expected, so he failed to login.  This was not a surprise, as VSJ defaults to leaving NTLM and Basic Auth turned off.  Good settings for a production environment, but one that trips people up when they first using VSJ in a development and test environment.  So he checked the vsj.properties file and turned both options on for testing.
  • Internet Explorer is an abysmal browser.  Once it starts doing something (like NTLM) there is no way to get it to stop.  Even turning NTLM off in the servlet filter doesn’t stop it from trying.  Nothing short of a reboot stops it from behaving this way.  So we enabled SP-NEGO in Firefox and continued on.  We also turned off NTLM, but left Basic Auth on, which then has the servlet filter requesting the Kerberos ticket on the user’s behalf.
  • Mike P was not in the test domain, so Kerberos would never work for him off his machine.  Unless . . . he used the “runas” command.  But even runas doesn’t work well off machines that are on another domain.  However, we used the “runas /netonly” command which gets past that.
  • Finally, we did reconfigure Mike’s machine to use the test domain’s DNS.  There is no way to do proper Kerberos without good name resolution, and we needed to get host and SRV records to get a ticket onto Mike’s machine.

There are definitely a lot more things to keep in mind when working with VSJ.  If you do need help, check out these forums or call your Quest rep to get you in touch with some knowledgable people.

Comments on this entry are closed.

Previous post:

Next post: