Suspected bug in WindowsSecurityContextImpl

Dec 15, 2010 at 2:41 PM


I am trying to write a client that connects to a server using SSPI and I think I have encountered a bug in WindowsSecurityContextImpl.

In the initialize function on line 90, it calls InitializeSecurityContext and sends WindowsAccountImpl.getCurrentUsername() to the parameter pszTargetName.

This means that in order to authenticate with a server, the server needs to be running under the same user as the client. Am I missing something here?




Dec 15, 2010 at 4:51 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Dec 15, 2010 at 4:53 PM

I think you're right. This was always an obscure parameter to me and frankly it always confused me too. MSDN says that this is the SPN or the security context of the destination server. So it really depends on which side you are and what you're trying to do. Waffle had little concern about being the client side except for unit tests (in which the current username works fine since we're both client and server side).

I think it needs some refactoring, exposing the spn as a parameter to initialize (and either defaulting to the current user in the null initialize or killing the null initialize altogether). Copied this to a workitem. Would love a patch!

Jul 21, 2011 at 7:21 PM

Just to help anyone out there that might have run into the same issues as we did.  We were getting the followng exeception:

com.sun.jna.platform.win32.Win32Exception: The target principal name is incorrect.

This seems to be related to running the server as a service.  The solution was to pass in the SPN to the targetName parameter, this seems to be the name of the service.  It doesn't seem to matter what is passed to it when running from the console as a regular user account. 

Jul 27, 2012 at 3:03 PM

I have the same error and I run the server as service. What do you mean the solution is to put SPN to the targetName, I am running it with SPN which is

<service class>/<host>. And I am still getting the same error, how did you manage to solve that ?
Jul 27, 2012 at 3:44 PM

The targetName parameter depends on whether you want to use NTLM or Kerberos.  I think we've determined that NTLM you need to pass in the service name (which I think is what is registered automatically in AD)

Jul 27, 2012 at 3:59 PM

Thanks for reply. I use Kerberos and Registered Service Principal name, but still getting error. Have no idea why. I get the service name by running this command where Kerberos is set up. 

setspn -l mackerberos

Registered ServicePrincipalNames for CN=mackerberos,CN=Users,DC=example,DC=com:    EXAMPLESSO/EXAMPLE.COM

So I use this name as a string targetName="EXAMPLESSO/EXAMPLE.COM"

Any ideas what can be wrong?

Thanks again.


Jul 27, 2012 at 4:25 PM

Unfortunately I don't know off hand.  The issues we were having with Kerberos was resolved by our network guy and I never did get the rundown on what he did.  I'll ask him the next time I see him.

Looking at your SPN shouldn't there be a hostname in there?

Jul 30, 2012 at 9:15 AM

Thanks for reply, it would be great if you could ask your network guy about that issue. In my SPN the host name is EXAMPLE.COM and service name is EXAMPLESSO. What is the structure of your SPN ?

Thank you in advance.

Aug 3, 2012 at 3:37 PM

Just talked to my network guy, it looks as though the key was having the fully qualified hostname.  So in your case:




The spn would have to be registered as that as well.  The other thing he did to debug it was use Wireshark to look at the packets.  The KRB packets should have a name type of 2.

Hope this helps.