[devel] Fw: PAC Sucess!
Alexander Bokovoy
=?iso-8859-1?q?ab_=CE=C1_altlinux=2Eorg?=
Вт Авг 30 16:22:38 MSD 2005
Greetings!
Рекомендовано к прочтению: принципы сетевого реинжиниринга на примере
анализа PAC.
(PAC -- это закрытое расширение Kerberos, добавленное Microsoft при
реализации Active Directory).
Ниже приведены два письма -- Эндрю Бартлетта и Эндрю Триджелла. В первом
описана история проблемы и процесс ее решения, а во втором -- технологии,
применявшиеся для решения.
Крайне поучительное чтение.
----- Forwarded message from Andrew Bartlett <abartlet на samba.org> -----
Date: Tue, 30 Aug 2005 21:02:22 +1000
From: Andrew Bartlett <abartlet на samba.org>
To: samba-technical на samba.org
Subject: PAC Sucess!
While a few of you have already noticed, I realised that I had not yet
announced our success with the PAC.
As many of you know, Samba4 has an implementation of the Active
Directory logon protocols, and we demonstrated WinXP performing a domain
join, and domain logon many months ago.
Until recenly, we were in a situation of 'one step forward, two steps
back', as we have enabled a KDC in Samba4, and are using it quite
successfully. However, the KDC we are operating is still unable to
generate a PAC acceptable to the windows client, which causes the
windows domain logon to fail. That's a real pity, because that login
was the pride of the SambaXP show - it really demonstrates how far we
have come.
As we moved on, we have added kerberos to our collection of implemented
protocols, incorporating modified snapshots of Heimdal kerberos into the
source. However, this was one of those 'two steps forward, one step
back' moments, as we were forced to implement the PAC, to satisfy the
domain logon.
Anyway, Micrsoft's proprietary extension to Kerberos, the PAC is a
signed and validated data structure that includes information on the
user and their group membership. As such, it is mandatory for the
domain logon sequence.
For the last 12 months, I have been working on and off, along with
Stefan Metzmacher and others on the Samba and Heimdal teams, to built a
KDC that a Windows client will respect as one of it's own. Slowly, we
have built backends, hacks, and patches for the KDC we derived from the
Heimdal Kerberos.
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).
As the day progressed tridge and I attacked just the kerberos
differences. We even had Samba4 issue a service ticket from an AS-REQ
issued by Win2k3. This allowed us to use a 'real PAC' in a Samba4
ticket (and allowed us to narrow the differences further).
Anyway, the long and short of it is that we can now generate a PAC fully
acceptable to the windows workstation!
In going so far, I do have to thank Stefan Metzmacher, Andrew Tridgell
and Love H??rnquist ??strand, because without their efforts, this simply
would not have been possible!
To try this yourselves, set:
gensec:gssapi_krb5=yes
in your Samba4 smb.conf, follow the HOWTO in Samba4 checkout.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc. http://suse.de
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
----- End forwarded message -----
----- Forwarded message from tridge на samba.org -----
Date: Tue, 30 Aug 2005 21:37:34 +1000
From: tridge на samba.org
To: Andrew Bartlett <abartlet на samba.org>
Cc: samba-technical на samba.org
Subject: Re: PAC Sucess!
X-Original-To: ab на fordclub.org
X-Original-To: samba-technical на samba.org
In-Reply-To: <1125399742.4159.216.camel на localhost.localdomain>
X-Mailer: VM 7.19 under Emacs 21.4.1
Reply-To: tridge на samba.org
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on
boids.moscow.ru.ibm.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=3.3 tests=BAYES_00,NO_REAL_NAME
autolearn=no version=3.0.4
> 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
----- End forwarded message -----
--
/ Alexander Bokovoy
Samba Team http://www.samba.org/
ALT Linux Team http://www.altlinux.org/
Midgard Project Ry http://www.midgard-project.org/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: Digital signature
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20050830/7f4e2c4f/attachment-0001.bin>
Подробная информация о списке рассылки Devel