FW: [jcifs] ASN.1

[Richard Caper]

See here:


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


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?).

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.



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.
> 
> Mike
> 
> --
> IRC - where men are men, women are men, and the boys are FBI agents.
>