Java GSS client talking to SSPI C++ Server

[Ali Akhavan]

Hi Mike, 
  Thanks! It helps a lot to know someone has done it at least. I was actually able to send a token given to me by Java GSS (although as you said generated by the AD) and establish a context with it to an SSPI C++ server.
Other than the AD configuration (setspn, enabling delegation, etc), I had to change the MIT SSPI port of GSS slightly to make it work with the Java GSS sample provided by SUN: The server was sending the flags over the wire to the client, however, the Java client was just expecting the binary (and its length). 

SO all is good now. Hope other people who are going to do this will hit our post here. 

Cheers,
Ali

-----Original Message-----
From: Michael B Allen [mailto:ioplex at gmail.com] 
Sent: February-25-11 11:44 AM
To: Ali Akhavan
Cc: kerberos at mit.edu
Subject: Re: Java GSS client talking to SSPI C++ Server

On Wed, Feb 23, 2011 at 6:01 PM, Ali Akhavan <alia at simba.com> wrote:
> Hello Kerberosians J
>
>
>
>  My intention is to delegate impersonation from a Java client to  a C++
> server. The Java client uses JAAS to authenticate and impersonate using
> doAsPriviledged() and finally starts establishing  a security context
> with the server. The server is C++ and is supposed to use SSPI library
> to accept this context. Is there any sample code close to my setup that
> someone has ?
>
>
>
> My concern is the compatibility of the tokens generated by JAVA GSS-API
> and that of SSPI. I know that at the wire-level they should be
> compatible, but a working example would greatly help me.

Hi Ali,

Strangely there are not a lot of good JGSS examples on the web. But
just google for "JGSS initSecContext" and that should get you started.

The tokens are fully compatible. Java is just going to take the token
supplied by AD and pass it up to the acceptor / server. It doesn't
even decode it (it can't because it's encrypted with the server key).
So the delegated token should even have group SIDs in it and so on. AD
is actually is a pretty good KDC for non-Windows clients (although the
tools provided by Microsoft for using it with non-Windows clients
borderline on useless of course - e.g. ktpass).

Now getting it to all work properly and see delegation work
consistently is another matter. The builtin Java GSSAPI and Kerberos
implementation has always been a bit of a turd. It requires a
krb5.conf so it's not as stateless as libraries should be. It uses
local DNS so you might not have the right SRV records (certainly not
for AD Sites and Services support which can sometimes be a
show-stopper) and AFAIK it won't gracefully failover to other
nameservers. The Windows and non-Windows implementations are different
because the Windows implementation needs to tap into the local
credential cache so you should write it on the platform you're going
to use it with and test it on the others when you're done. Also, I
don't think Java's Kerberos library supports the "enterprise"
principal name type (10) so you can't use userPrincipalName as the
client principal (Windows people call this the eUPN or "explicit
UPN"), you have to use sAMAccountName at dns.domain.name (iUPN or
"implicit UPN"). Anyway these are just the warts that come to mind at
this moment.

But if you pound your face into the keyboard long enough you should be
able to get Java's Kerberos implementation to work.

Mike

-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/