[jcifs] SPNEGO and Kerberos

Kimberlin, Michael Michael.Kimberlin at savvis.net
Fri Apr 29 15:25:07 GMT 2005

So everything was working great...I had success authenticating via both
NTLM and SPNEGO/Kerberos using the servlet filter in jcifs-ext...  Then
it all went sour.  I was working with a test app in Tomcat initially
(when everything was fine).  Then I tried to copy my war file over to
jboss/tomcat...and all hell broke lose.

I started getting errors related to the users.properties and
roles.properties that are utilized by the standard
org.jboss.security.auth.spi.UsersRolesLoginModule in jboss...

I thought...no big deal...I'll just replace that module with:
com.sun.security.auth.module.Krb5LoginModule required storeKey=true

But that said it couldn't locate a Kerberos key...

Now, I'm pretty sure that tomcat 4 by itself doesn't use jaas unless you
configure it for the jaasrealm.  So, what does that mean will happen in
this servlet filter?  And since jboss uses jaas always, how can I get
the servlet filter to believe it doesn't and go about this in the
default way?

My gut is that the correct approach would be to use the
Krb5LoginModule...but I'm clueless as to why it isn't finding my service
principal and password...

A good swift kick in the pants on this would be greatly appreciated...


-----Original Message-----
From: Michael B Allen [mailto:mba2000 at ioplex.com] 
Sent: Tuesday, April 19, 2005 12:44 PM
To: Kimberlin, Michael
Cc: jcifs at samba.org
Subject: Re: [jcifs] SPNEGO and Kerberos

On Tue, 19 Apr 2005 12:04:30 -0500
"Kimberlin, Michael" <Michael.Kimberlin at savvis.net> wrote:

> Ahh, yes...excellent.  Thanks for the direction.
> It looks like quite a lot of functionality is there.  I'll have to
> some time to weed through it.  Any idea (off the top of your head)
> whether these classes have PAC support?  If not, maybe I'll add that
> in...

The PAC is encrypted with the Domain Controller's secret key so jCIFS
will never have direct "PAC support". We do need the ticket with the
PAC but it's passed to the target (the DC) for it to decrypt and use
the group membership information inside to make access control

I suspect what you mean is, can jcifs-ext do group membership lookups?
answer is "yeah, but ...". It uses RAP calls to get group information to
implement isInRole however it is limited to 64K transactions which means
large group lists will fail. Full RAP also will never be integrated into
jCIFS as it is a deprecated technology.

To properly implement group membership functionality it will be
to implement RPC. We have RPC support via Jarapac but I want to
Extended Security with Kerberos so that I get a new "proper" security
context model working before I implement all sorts of security related
APIs. However once I do that it's not crystal clear that the builtin
Java 1.4 Kerberos client will support the mechanism necessary to get
the Kerberos ticket with the PAC.

So it's in the works but it's been slow going and there are some
remaining about the implementation. If you really want full RPC based
group membership lookups you could peice together the jcifs-ext filter
with the jarapac examples that lookup sids and make a new package but
you would have to use NTLM [1].


[1] To do RPCs against the DC you must authenticate with it and to
authenticate with it using Kerberos you need Extended Security which we
do not support. Currently the jcifs-ext filter just communicates with
the KDC directly and not using SMB (thus it has nothing to do with

IRC - where men are men, women are men, and the boys are FBI agents.

More information about the jcifs mailing list