FW: [jcifs] ASN.1

[Michael B Allen]

On Sat, 23 Apr 2005 10:37:49 -0400
Richard Caper <rcaper at gmail.com> wrote:

> See here:
> 
> 
> http://bofriis.dk/index.html?http://bofriis.dk/spnego/pac/ms_kerberos_pac.html

Neat. This guy has a lot of cool links. I'm CC-ing Enrique. I think he's
been pondering PAC support in his Kerberos implementation.

> He describes decrypting the PAC and obtaining the relative group IDs. 
> But I don't know if it would be useful to a jCIFS client; the PAC is
> encrypted with the server's key (server principal).  So for like the
> jCIFS ext filter where it is configured to have the SPN
> username/password, it could be obtained (since the filter is acting as
> the server).  But for client accessing the server you would not have
> the server's key (I think it would maybe be based on the machine
> account?).

Yeah, however the server's secret key is generated the client can't
get it or it wouldn't be a secret! JCIFS will not need to actually
decrypt any Kerberos tickets. We just get the ticket and then pass it
to the server. After authenticating we can then query our membership
list using the LsarLookupSids RPC (which we already have working in
jarapac/examples/TestLsarpc.java).

> The assumption seems to be that the server gets the client's groups
> from the DC in the PAC so it can make access decisions without having
> to bother the DC more.  For the client I think you would have to make
> some other calls to get the same information... you could get it
> through LDAP from the DC I believe.  I know the Java JNDI can do
> Kerberos authentication to AD so you could reuse the ticket to do the
> LDAP call.

That's how I understand it too. But I think we'll just use RPC to get the
group sids. Or rather we should just do whatever Windows does. If that
involves some LDAP queries then we might need to look at JNDI a little.

What I'm really not concrete on is if the JAAS Kerberos client will
negotiate with MS Kerberos in a way that the PAC is included in the
Kerberos ticket. Enrique says yes. I'm inclined to think it will too
as the authoriazation_data field is a normal field so unless JAAS does
something that give MS an opportunity to leave it out I think it will
be there in which case it's not within the power of the client to leave
it out.

Mike

> On 4/22/05, Michael B Allen <mba2000 at ioplex.com> wrote:
> > On Fri, 22 Apr 2005 12:53:03 -0400
> > Richard Caper <rcaper at gmail.com> wrote:
> > 
> > > So while you have to run 2 passes, you can encode directly to the
> > > toplevel buffer.  Since the size is cached for each object in the
> > > first pass, it doesn't have to be calculated again.
> > 
> > Right. No copying and we don't create a Java Object per DER object
> > (or create and copy byte[] arrays). In theory I think this is about as
> > good as it get's I'm afraid. For doing any serious DER code I think a
> > compiler would be in order. Fortuneately I don't think we'll reach that
> > point unless we start to do custom LDAP / Kerberos stuff.
> > 
> > Anyone know if the Java 1.4 Kerberos client can negotiate a ticket with
> > the MS PAC in it? I guess I'll find out soon enough.

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