[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Kerberos IF_RELEVANT/PAC structure question
Thanks for all the pointers.
I have looked even at the expired IETF draft on how it works but my problem
is this:
(i know NDR (dcerpc encoding) _really_ well and can in pre-XP
implementations spot NDR UNIQUE pointers
easily in the hexdump (XP and later changed how the non-null values for the
referrent values for UNIQUE pointers were choosen))
The drafts describe a structure that starts with 6 64bit NT filetime
structures followed by 6 unicode_string structures
(each unicode_string, as normal for MS DCERPC interfaces being 2 16bit
integers followed by a unique pointer to a conformant and varying array of
short integers (wide char))
This particular structure as described in teh draft is known in the
DCERPC/NETLOGON interface known as
VALIDATION_SAM_INFO2
and is defined, indentically to the draft as: (from ethereal source code
and verified to be correct)
/*
* IDL typedef struct {
* IDL uint64 LogonTime;
* IDL uint64 LogoffTime;
* IDL uint64 KickOffTime;
* IDL uint64 PasswdLastSet;
* IDL uint64 PasswdCanChange;
* IDL uint64 PasswdMustChange;
* IDL unicodestring effectivename;
* IDL unicodestring fullname;
* IDL unicodestring logonscript;
* IDL unicodestring profilepath;
* IDL unicodestring homedirectory;
* IDL unicodestring homedirectorydrive;
* IDL short LogonCount;
* IDL short BadPasswdCount;
* IDL long userid;
* IDL long primarygroup;
* IDL long groupcount;
* IDL [unique] GROUP_MEMBERSHIP *groupids;
* IDL long userflags;
* IDL USER_SESSION_KEY key;
* IDL unicodestring logonserver;
* IDL unicodestring domainname;
* IDL [unique] SID logondomainid;
* IDL long expansionroom[10];
* IDL long sidcount;
* IDL [unique] SID_AND_ATTRIBS;
* IDL } VALIDATION_SAM_INFO2;
*/
Thats no big worry and anyone very familiar with either MS DCERPC interfaces
and NDR encoding will find it easy to
see how it would be encoded.
Here is the problem, after decrypting the LOGON_INFO part of the PAC structu
re I do get something that is obviously
NDR encoded. BUT it is (somolar to but) not quite this structure.
My decrypted data is something that
starts with a UNIQUE pointer (which is easy to spot since the host was
pre-XP)
some junk
another UNIQUE pointer
then followed by something VERY similar to this structure but with the
difference that above there are 6 embedded unicode_string
structures following the 6 uint64 (NT_FILETIME) timestamp fields (which are
very easy to spot).
In my decrypted capture this structure only contains 4 unicode_strings here.
These unicode_strings will at this place in the packet always be encoded as
8 bytes: 2 shorts representing the real and the encoded length of the string
in characters followed by a UNIQUE (possibly NULL) pointer to the actual
string following after the struct itself in the pdu.
Everything else apart from the initial two UNIQUE pointers and the "missing"
two unicode_strings all look the same as the definition above.
Does anyone know of pointers to other documents or real implementations with
source code that can talk PAC?
I am not comfortable with implementing it in ethereal when it is (at least
right now) to me obviously not wire compatible with what i did see on the
wire.
The PAC structure Im looking at is the content of the encrypted part of a
ticket inside a SessionSetupAndX from a bog standard w2k client
mapping a share on a file server.
Has anyone implemented PAC before? I need to look more closely at it but
it just look very different to what the NDR encoding of
NETLOGON/VALIDATE_SAM_INFO2 would look like (and i know what that one looks
like since i handcoded the implementation for it in ethereal)
Is this just a "mudding the waters" atempt by those that wrote the draft?
----- Original Message -----
From: "Gémes Géza"
Cc: "Douglas E. Engert"
Sent: Wednesday, March 03, 2004 6:36 AM
Subject: Re: Kerberos IF_RELEVANT/PAC structure question
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Gémes Géza írta:
> | Douglas E. Engert írta:
> | |
> | | Ronnie Sahlberg wrote:
> | |
> | |>Hi list.
> | |>
> | |>Im continuing to fight with my enhanced ethereal kerberos dissector
with
> | |>some progress.
> | |>
> | |>I can now (even if other minor problems remain) view the decrypted
> | data of a
> | |>w2k PAC blob
> | |>passed inside a ticket from a w2k client while authenticating to a
> member
> | |>server.
> | |>
> | |>I have been told that this data is NDR encoded (I am very familiar
> | with ndr
> | |>encoding)
> | |>does anyone have a specification or any information on what data is
> | held in
> | |>these structures
> | |>to make life easier for me?
> | |
> | |
> | |
> | |
> | | A New Internet-Draft is available from the on-line Internet-Drafts
> | directories.
> | |
> | |
> | | Title : Utilizing the Windows 2000 Authorization
> | Data in
> | | Kerberos Tickets for Access Control to
> | Resources
> | | Author(s) : J. Brezak
> | | Filename : draft-brezak-win2k-krb-authz-01.txt
> | | Pages : 9
> | | Date : 2002-10-16
> | |
> | | Microsoft Windows 2000 includes operating system specific data in
> | | the Kerberos V5 [2] authorization data field that is used for access
> | | control. This data is used to create an NT access token. The access
> | | token is used by the system to enforce access checking when
> | | attempting to access objects. This document describes the structure
> | | of the Windows 2000 specific authorization data that is carried in
> | | that field for use by servers in performing access control.
> | |
> | | A URL for this Internet-Draft is:
> | |
http://www.ietf.org/internet-drafts/draft-brezak-win2k-krb-authz-01.txt
> | |
> | |
> | |
> | I wasn't able to access that document, but found something similar:
> |
> |
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnkerb/html/MSDN_PAC.asp
>
> |
> |
> | and
> |
> |
>
http://download.microsoft.com/download/win2000srv/Spec/1.0/NT5/EN-US/kerbspec.exe
>
> |
> |
> | the later is a packaged pdf file, at least M$ says that about it, I
> | haven't downloaded it yet.
> |
> | Good Luck!
> |
> | P.S.
> | We Samba users, are all waiting for an MSPAC implementation in Heimdal
> |
> | Cheers,
> |
> | Geza
> Sorry for the second link it says that you must agree with M$ world
> dominance agreement, and offer your first born, before you can read it,
> or you are not allowed.
> Sorry for sending that stupid link. But the first one is ok from the
> point of view of a license.
>
> cheers,
>
> Geza
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFAROIq/PxuIn+i1pIRAiCeAJ4zK3NyhWOr5IoixshVRPD4SZkwlgCfaVXF
> lrTT0Cn7m/3AP+X6XMtB5dI=
> =QCHp
> -----END PGP SIGNATURE-----
>