Java GSS client talking to SSPI C++ Server

[Michael B Allen]

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/