[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heimdal 0.2a
- To: heimdal-discuss@sics.se
- Subject: Re: Heimdal 0.2a
- From: joda@pdc.kth.se (Johan Danielsson)
- Date: 18 Oct 1999 11:47:59 +0200
- In-Reply-To: Assar Westerlund's message of "18 Oct 1999 05:51:44 +0200"
- References: <5l4sfpz5pr.fsf@assaris.sics.se>
- Sender: owner-heimdal-discuss@sics.se
- User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3
Assar Westerlund <assar@sics.se> writes:
> * internal ls in ftpd
A comment on this. It's still somewhat experimental, so you have to
enable it with `--builtin-ls'. It is not 100% compatible with `the
real stuff', it doesn't do `-R' (I'm not sure you want that), and it
doesn't glob the file argument `ls foo*' doesn't do what you might
expect. Having said this, please go ahead and try it, and send
whatever feedback you have to us.
Furthermore you need this patch to make the external ls behave as
ususal.
--- ftpd.c 1999/10/03 16:38:14 1.121
+++ ftpd.c 1999/10/18 09:43:35 1.122
@@ -38,7 +38,7 @@
#endif
#include "getarg.h"
-RCSID("$Id: ftpd.c,v 1.121 1999/10/03 16:38:14 joda Exp $");
+RCSID("$Id: ftpd.c,v 1.122 1999/10/18 09:43:35 joda Exp $");
static char version[] = "Version 6.00";
@@ -2094,9 +2094,9 @@
pdata = -1;
} else {
#ifdef HAVE_LS_A
- char *cmd = "/bin/ls -lA";
+ char *cmd = "/bin/ls -lA %s";
#else
- char *cmd = "/bin/ls -la";
+ char *cmd = "/bin/ls -la %s";
#endif
retrieve(cmd, file);
}
/Johan
>From heimdal-discuss-owner Sat Oct 30 15:29:55 1999
Received: (from majordom@localhost)
by color.sics.se (8.9.3/8.9.3) id PAA20217;
Sat, 30 Oct 1999 15:28:44 +0200 (MET DST)
env-from (owner-heimdal-discuss@sics.se)
Received: from assaris.sics.se (assaris.sics.se [193.10.66.108])
by color.sics.se (8.9.3/8.9.3) with ESMTP id PAA20200
for <heimdal-discuss@sics.se>; Sat, 30 Oct 1999 15:28:39 +0200 (MET DST)
env-from (assar@sics.se)
Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id PAA97412 for heimdal-discuss@sics.se; Sat, 30 Oct 1999 15:29:36 +0200 (CEST)
Message-ID: <10F8EB7E5319D31195CF0090277AF237187584@c2.154.nauticom.net>
From: Ben Cox <BenC@CoManageCorp.com>
To: Assar Westerlund <assar@sics.se>, heimdal-discuss@sics.se, krbdev@MIT.EDU,
samba-ntdom@samba.org
Subject: RE: format of authorization data in a win2k ticket
Date: Fri, 29 Oct 1999 11:45:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BF2224.9CD41518"
Sender: owner-heimdal-discuss@sics.se
Precedence: bulk
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01BF2224.9CD41518
Content-Type: text/plain;
charset="iso-8859-1"
Hello Assar,
On September 21, you wrote:
> I did some testing with Heimdal against a Windows 2000 rc1 KDC and
> after having managed to a client on the w2k-box to authenticate to my
> server I got ahold of an encrypted ticket with the extra authorization
> data in it. The entire contents of the authorization data that I got
> is available at <http://www.sics.se/~assar/add-ticket>.
> [...]
> And the octet string contains lots of uninterpretable data (too me)
> but includes the client name (Administrator), the host name (TERMIT),
> and the first component of the domain name (FOO), and you can also
> find four SIDs in there but I haven't been able to figure out what
> these SIDs belong to. It's unclear how you would get out the SIDs of
> particular users from the database but it's clear that the SIDs belong
> to this domain since the prefix of them are the same as the SIDs that
> can be found in the registry.
>
> If anyone can bring some more clarity on the data in the octet string,
> that would be very nice.
I haven't seen any further discussion of this message, so hopefully I
am not duplicating work that has already been done much better by other
people, but I have done some preliminary investigation of the authz
data and below are my results. I have also included a dump with my
comments as an attached file instead of just including the text, in
the hope that the line breaks will be preserved, since the lines are
fairly wide (>> 80 chars).
Ben Cox <BenC@CoManageCorp>
Development Engineer
CoManage Corporation
+1 412 318-6004
DISCLAIMER: Nothing in this message should be construed as an official
position of CoManage Corporation.
-----------------------------------------------------------
Interpret the first 8 bytes as a long long (64-bit int). Its value is
4. This probably indicates the count of segments to follow.
Then, there are 4 16-byte structures. In each of these, there is a
32-bit tag(?), a 32-bit length, and a 64-bit offset. These are:
{ 1, 616, 72 }
{ 10, 36, 688 }
{ 6, 20, 728 }
{ 7, 20, 752 }
Then follow 4 more segments: a 616-byte segment starting at offset 72,
a 36-byte segment starting at offset 688, a 20-byte segment starting
at offset 728, and a 20-byte segment starting at offset 752. These
offsets are chosen to align to 8-byte (LONGLONG) boundaries. (Which
is why the last one doesn't start at 748, for example, but 752.) (All
offsets in this discussion are relative to the start of the 776-byte
octet string.)
The first segment, I haven't figured out the structure of yet. This
is the segment that contains the first instance of the account name
("Admnistrator"), the hostname ("TERMIT"), the domain name ("FOO"),
and the SID list. The strings in this segment are in BSTR format (a
32-bit count of unsigned 16-bit Unicode characters, followed by the
characters themselves). There are 6 SIDs here total. They are:
S-1-5-21-602162358-1957994488-854245398
S-1-5-21-602162358-1957994488-854245398-518
S-1-5-21-602162358-1957994488-854245398-512
S-1-5-21-602162358-1957994488-854245398-519
S-1-5-21-602162358-1957994488-854245398-520
S-1-5-21-602162358-1957994488-854245398-513
The first SID is almost certainly the SID of your domain itself, as it
is the prefix for the remaining SIDs, each of whose final RID is a
low-valued (and in 3 cases well-known) RID. The one ending in -518 is
the SID of your domain's schema admins group; 512 is domain admins,
and 513 is domain users (these are all well-known RIDs). The 519 and
520 ones are not well-known RIDs, but are the first available group
RIDs after the predefined groups. It is likely that you belong to two
groups defined at your site beyond the standard administrative group
set. The first SID starts at offset 0x01C4; the first 4 bytes are the
32-bit value 4, which is the number of subauthorities in the SID, then
the SID immediately follows. The remainder of the SIDs start at
offset 0x20C, and all 5 are consecutive with a prefixed 32-bit value 5
(which is the number of subauthorities in those SIDs). The list
appears to be terminated at offset 0x2AC with a 32-bit 0 value.
The second segment has 8 bytes that I can't interpret, followed by a
non-NUL-terminated Unicode string (L"Administrator") prefixed with a
16-bit byte count. (Note: not the same as a BSTR. Also I say
non-NUL-terminated even though some zero-bytes follow, because the
36-byte length given in the header up top doesn't include the four
0-bytes that follow the string; they appear just to be padding.)
The third and fourth segments begin with 76FF FFFF (probably should be
interpreted as 0xFFFFFF76, or decimal -138), followed by 16 nonzero
bytes. (Followed by 4 zero bytes, but remember that those appear to
be padding to a quadword boundary.) I'm guessing that these are
actually encrypted MD5 hashes or MD5 HMACs of the first two segments.
(They might also be GUIDs.)
------_=_NextPart_000_01BF2224.9CD41518
Content-Type: text/plain;
name="add-ticket.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="add-ticket.txt"
----------------------------------------------------------------------
HEADER:
00000000: 0400 0000 0000 0000 LONGLONG: 4
00000008: 0100 0000 DWORD: 1
0000000C: 6802 0000 DWORD: 616
00000010: 4800 0000 0000 0000 LONGLONG: 72
00000018: 0A00 0000 DWORD: 10
0000001C: 2400 0000 DWORD: 36
00000020: B002 0000 0000 0000 LONGLONG: 688
00000028: 0600 0000 DWORD: 6
0000002C: 1400 0000 DWORD: 20
00000030: D802 0000 0000 0000 LONGLONG: 728
00000038: 0700 0000 DWORD: 7
0000003C: 1400 0000 DWORD: 20
00000040: F002 0000 0000 0000 LONGLONG: 752
----------------------------------------------------------------------
SEGMENT 1:
00000048: 0110 0800 ?
0000004C: CCCC CCCC ? (uninitialized?)
00000050: 5802 0000 0000 0000 LONGLONG: 600 (length of remainder of =
this segment)
00000058: 40F2 6700 ?
0000005C: 30F2 92AF 4403 BF01 ? (timestamp?)
00000064: FFFF FFFF FFFF FF7F ? (note: MAXLONGLONG; =
"forever"/"never" timestamp?)
0000006C: FFFF FFFF FFFF FF7F ? (MAXLONGLONG)
00000074: 206B 2E1D B6F2 BE01 ? (timestamp?)
0000007C: 206B 2E1D B6F2 BE01 ? (timestamp?)
00000084: FFFF FFFF FFFF FF7F ? (MAXLONGLONG)
0000008C: 1A00 1A00 E8F8 ?
00000092: 0900 0000 0000 04F9 ?
0000009A: 0900 0000 0000 04F9 ?
000000A2: 0900 0000 0000 04F9 ?
000000AA: 0900 0000 0000 04F9 ?
000000B2: 0900 0000 0000 04F9 ?
000000BA: 0900 0B00 0000 F401 0000 0102 0000 0000 ?
000000CA: 0000 0000 0000 2000 0000 0000 0000 0000 ?
000000DA: 0000 0000 0000 0000 0000 0C00 0E00 04F9 ?
000000EA: 0900 0600 0800 14F9 0900 1CF9 0900 0000 ?
000000FA: 0000 0000 0000 1002 0000 0000 0000 0000 ?
0000010A: 0000 0000 0000 0000 0000 0000 0000 0000 ?
0000011A: 0000 0000 0000 0500 0000 34F9 0900 0000 ?
0000012A: 0000 0000 0000 0000 0000 ?
00000134: 0D00 0000 0000 0000 QWORD: 13
0000013C: 0D00 0000 4100 6400 6D00 6900 6E00 6900 BSTR("Admini
0000014C: 7300 7400 7200 6100 7400 6F00 7200 strator")
0000015A: 0000 0000 0000 0000 0000 0000 0000 0000 ?
0000016A: 0000 0000 0000 0000 0000 0000 0000 0000 ?
0000017A: 0000 0000 0000 0000 0000 0000 0000 0000 ?
0000018A: 0000 0000 0000 0000 0000 0000 0000 ?
00000198: 0700 0000 0000 0000 QWORD: 7
000001A0: 0600 0000 5400 4500 5200 4D00 4900 5400 BSTR("TERMIT")
000001B0: 0400 0000 0000 0000 QWORD: 4
000001B8: 0300 0000 4600 4F00 4F00 BSTR("FOO")
000001C2: 0000 ? (padding to dword boundary?)
000001C4: 0400 0000 DWORD: 4 (# of subauths)
000001C8: 0104 0000 0000 0005 1500 0000 B644 E423 SID: =
S-1-5-21-602162358-
000001D8: F89F B474 16C0 EA32 1957994488-854245398
(SID of the domain)
000001E0: 0500 0000 5CF9 0900 0700 0000 78F9 0900 ?
000001F0: 0700 0000 94F9 0900 0700 0000 B0F9 0900 ?
00000200: 0700 0000 CCF9 0900 0700 0000 ?
0000020C: 0500 0000 DWORD: 5 (# of subauths)
00000210: 0105 0000 0000 0005 1500 0000 B644 E423 SID: =
S-1-5-21-602162358-
00000220: F89F B474 16C0 EA32 0602 0000 1957994488-854245398-518
(SID of schema admins group)
0000022C: 0500 0000 DWORD: 5 (# of subauths)
00000230: 0105 0000 0000 0005 1500 0000 B644 E423 SID: =
S-1-5-21-602162358-
00000240: F89F B474 16C0 EA32 0002 0000 1957994488-854245398-512
(SID of domain admins group)
0000024C: 0500 0000 DWORD: 5 (# of subauths)
00000250: 0105 0000 0000 0005 1500 0000 B644 E423 SID: =
S-1-5-21-602162358-
00000260: F89F B474 16C0 EA32 0702 0000 1957994488-854245398-519
0000026C: 0500 0000 DWORD: 5 (# of subauths)
00000270: 0105 0000 0000 0005 1500 0000 B644 E423 SID: =
S-1-5-21-602162358-
00000280: F89F B474 16C0 EA32 0802 0000 1957994488-854245398-520
0000028C: 0500 0000 DWORD: 5 (# of subauths)
00000290: 0105 0000 0000 0005 1500 0000 B644 E423 SID: =
S-1-5-21-602162358-
000002A0: F89F B474 16C0 EA32 0102 0000 1957994488-854245398-513
(SID of domain users group)
000002AC: 0000 0000 DWORD: 0 (end of SID list?)
----------------------------------------------------------------------
SEGMENT 2:
000002B0: 80EC B561 7603 BF01 ? (timestamp?)
000002B8: 1A00 WORD: 26 (# of bytes in string)
000002BA: 4100 6400 6D00 6900 6E00 6900 7300 7400 L"Administ
000002CA: 7200 6100 7400 6F00 7200 rator"
000002D4: 0000 0000 (padding)
(Note: this string is not a BSTR, as the count of bytes is
only 16 bits and it counts bytes, not chars.)
----------------------------------------------------------------------
SEGMENT 3:
000002D8: 76FF FFFF ?
000002DC: 3C7F F138 AE11 CDB0 9153 4B17 DA8A 5593 MD5 hash? (GUID?)
000002EC: 0000 0000 (padding)
----------------------------------------------------------------------
SEGMENT 4:
000002F0: 76FF FFFF ?
000002F4: A886 4DBC DAF8 15FE 8250 9229 6A09 E654 MD5 hash? (GUID?)
00000304: 0000 0000 (padding)
----------------------------------------------------------------------
------_=_NextPart_000_01BF2224.9CD41518--
>From heimdal-discuss-owner Mon Nov 1 03:31:57 1999
Received: (from majordom@localhost)
by color.sics.se (8.9.3/8.9.3) id DAA04981
for heimdal-discuss-outgoing; Mon, 1 Nov 1999 03:21:14 +0100 (MET)
env-from (owner-heimdal-discuss@sics.se)
Received: from assaris.sics.se (assaris.sics.se [193.10.66.108])
by color.sics.se (8.9.3/8.9.3) with ESMTP id DAA04977
for <heimdal-discuss@sics.se>; Mon, 1 Nov 1999 03:21:13 +0100 (MET)
env-from (assar@sics.se)
Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id DAA00855; Mon, 1 Nov 1999 03:22:12 +0100 (CET)
X-Mailer: exmh version 2.1.0 09/18/1999
X-Exmh-Isig-CompType: unknown
X-Exmh-Isig-Folder: mlist/freebsd/fs
X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE
X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt
X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73
X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1
X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt
From: Jacques Vidrine <n@nectar.com>
To: heimdal-discuss@sics.se
Subject: Heimdal and telnet and encoding types
Mime-Version: 1.0
Content-Type: text/plain
Date: Sat, 30 Oct 1999 19:10:59 -0500
Original-Sender: nectar@nectar.com
Message-Id: <19991031001059.69EB41DA4@bone.nectar.com>
Lines: 22
Sender: owner-heimdal-discuss@sics.se
Precedence: bulk
Hello everyone!
I have just started testing the Heimdal code for interoperability
with MIT Kerberos V.
The telnet client seems to want to fetch ``host'' credentials
with encoding type des-cbc-rsa-md4, despite my efforts to set
the default encoding type to des-cbc-crc in /etc/krb5.conf.
If I have the credentials previously stored (e.g. from the MIT
telnet client or by using kgetcred) with encoding type des-cbc-crc
they are used as expected.
I'm not sure how to track this down. Any pointers would be
appreciated.
Thanks!
--
Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org
>From heimdal-discuss-owner Mon Nov 1 03:59:33 1999
Received: (from majordom@localhost)
by color.sics.se (8.9.3/8.9.3) id DAA07445
for heimdal-discuss-outgoing; Mon, 1 Nov 1999 03:54:06 +0100 (MET)
env-from (owner-heimdal-discuss@sics.se)
Received: from assaris.sics.se (assaris.sics.se [193.10.66.108])
by color.sics.se (8.9.3/8.9.3) with ESMTP id DAA07440
for <heimdal-discuss@sics.se>; Mon, 1 Nov 1999 03:54:04 +0100 (MET)
env-from (assar@sics.se)
Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id DAA00909; Mon, 1 Nov 1999 03:54:56 +0100 (CET)
To: Jacques Vidrine <n@nectar.com>
Cc: heimdal-discuss@sics.se
Subject: Re: Heimdal and telnet and encoding types
References: <19991031001059.69EB41DA4@bone.nectar.com>
Mime-Version: 1.0 (generated by tm-edit 7.68)
Content-Type: text/plain; charset=US-ASCII
From: Assar Westerlund <assar@sics.se>
Date: 01 Nov 1999 03:54:54 +0100
In-Reply-To: Jacques Vidrine's message of "Sat, 30 Oct 1999 19:10:59 -0500"
Message-ID: <5l904i6hvl.fsf@assaris.sics.se>
Lines: 17
X-Mailer: Gnus v5.5/Emacs 19.34
Sender: owner-heimdal-discuss@sics.se
Precedence: bulk
Jacques Vidrine <n@nectar.com> writes:
> Hello everyone!
Hi.
> The telnet client seems to want to fetch ``host'' credentials
> with encoding type des-cbc-rsa-md4, despite my efforts to set
> the default encoding type to des-cbc-crc in /etc/krb5.conf.
The telnet client actually tries to fetch credentials with keytype
DES, that is any of the des-* enctypes, which means that whatever you
have specified with `[libdefaults] default_etypes =' in /etc/krb5.conf
doesn't apply. If there exists a key of that type in the database and
in the keytab on the remote host, why is it a problem that it uses
des-cbc-rsa-md4?
/assar
>From heimdal-discuss-owner Mon Nov 1 10:57:25 1999
Received: (from majordom@localhost)
by color.sics.se (8.9.3/8.9.3) id KAA13851
for heimdal-discuss-outgoing; Mon, 1 Nov 1999 10:57:16 +0100 (MET)
env-from (owner-heimdal-discuss@sics.se)
Received: from blubb.pdc.kth.se (blubb.pdc.kth.se [193.10.159.47])
by color.sics.se (8.9.3/8.9.3) with SMTP id KAA13847;
Mon, 1 Nov 1999 10:57:14 +0100 (MET)
env-from (joda@pdc.kth.se)
Received: from joda by blubb.pdc.kth.se with local (Exim 1.71 #3)
id 11iE8b-0000G2-00; Mon, 1 Nov 1999 10:52:29 +0100
To: Assar Westerlund <assar@sics.se>
Cc: Jacques Vidrine <n@nectar.com>, heimdal-discuss@sics.se
Subject: Re: Heimdal and telnet and encoding types
References: <19991031001059.69EB41DA4@bone.nectar.com> <5l904i6hvl.fsf@assaris.sics.se>
From: joda@pdc.kth.se (Johan Danielsson)
Date: 01 Nov 1999 10:52:28 +0100
In-Reply-To: Assar Westerlund's message of "01 Nov 1999 03:54:54 +0100"
Message-ID: <xofk8o24jz7.fsf@blubb.pdc.kth.se>
Lines: 11
User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-heimdal-discuss@sics.se
Precedence: bulk
Assar Westerlund <assar@sics.se> writes:
> If there exists a key of that type in the database and
> in the keytab on the remote host, why is it a problem that it uses
> des-cbc-rsa-md4?
Because, apparently, both the MD4 and MD5 thingy in the MIT code is
broken. At least, that's the impression I got when we tried to
interoperate with Tom Yu.
/Johan