PAC Sucess!

[tridge at samba.org]

 > As the months have gone by, we have got closer and closer, and last
 > Friday we finally cracked it:  I arranged to spend a Thursday with
 > Tridge, to show him the ropes, and to see what progress we could make,
 > and we continued to work on the problem on Friday.  Tridge made the
 > first real headway by narrowing the problem to just kerberos (by using
 > proxies and an account database obtained from Win2k3 with samsync).  

I thought it might be useful to describe the specifics of this
technique, as others working on similar problems may find it useful.

Andrew and I setup a vmware network like this:

      ------- w2k3 PDC
      |
 Samba4
      |
      ------- w2k3 member server

the linux box had 2 virtual network interfaces, on 192.168.114.1 and
192.168.115.1. 

We first joined the w2k3 member server to the w2k3 PDCs domain. Then
we used the samsync code to replicate the account information from
that PDC onto the Samba box, so the Samba4 box was using exactly the
same keys and account information as the w2k3 box for the same domain
name.

Then we used a combination of 'sockspy' and 'udpproxy' which are two
little hackish C progs from junkcode (junkcode.samba.org) to proxy
different combinations of the various protcols, alternately allowing
the Samba4 box to serve the protocols or the w2k3 PDC to serve them to
the w2k3 member server. The various protocols we needed are:

 - udp 88  - kerberos
 - udp 53  - dns
 - udp 389 - cldap
 - tcp 135 - rpc portmapper
 - tcp 139 - SMB/CIFS
 - tcp 389 - ldap
 - tcp 445 - SMB/CIFS
 - tcp 1024, 1025, 1026 - RPC 

So we did things like this:

  UDP="88 389"
  for p in $UDP; do
    ./udpproxy $p 192.168.114.5 $p &
  done

  TCP="135 139 389 445 1024 1025 1026"
  for p in $TCP; do
    while ./sockspy $p 192.168.114.5 $p; do date; done &
  done

and in that way we proxied whatever selection of protocols we wanted
to.

The first test was to proxy all protocols, except for DNS which we
setup on the Linux box to always point all the PDC names at the Linux
box IP. This was the 'null' test, and showed that logins work via the
proxies.

Next, we proxied all protocols except kerberos, and setup smbd to only
server kerberos. This showed the "PAC bug", as expected. That proved
that the bug is definately kerberos related, and not an artifact of
some RPC or LDAP problem.

Next, we proxied all only kerberos, serving everying else from
smbd. In this case the login worked, again showing the bug is kerberos
related.

Finally, we hacked udpproxy.c to only proxy packets smaller than 400
bytes. This was a really nasty hack, but had the effect of only
proxying the AS-REQ packet, and not the TS-REQ. This meant the client
gave us back the PAC from the AS-REP from the real PDC in the TS-REQ,
which meant that the Samba4 kdc received the real PAC from the w2k3
box. We could then re-sign this PAC using the clients keys and send it
out in the TS-REP from smbd. This worked, giving us a successful
login.

That last test proved the problem lay in the PAC itself, and not in
any other part of the krb5 packets. From there we did a byte by byte
comparison of our generated PAC to the one that w2k3 gave, and tested
'fixing' each field by replacing it with the field from the w2k3
PAC. The field that turned out to be critcal was
LOGON_NAME->logon_time, which must exactly equal the time from the
AS-REP authtime field.  That solved the puzzle.

Cheers, Tridge