Kai Lanz
2008-Aug-05 20:03 UTC
[Samba] Leopard Macs using Kerberos: Failed to parse negTokenTarg
I think I've found out why MacOS 10.5.x (Leopard) clients are unable to
connect to Samba shares when authenticating with Kerberos. Basically,
the
Leopard Macs insert a few extra bytes (Padding and reqFlags,
according to
wireshark) into the security blob within the Session Setup AndX Request
packet, bytes whose start tag is 0xa1, in a spot where Samba's parser
expects 0xa2. The critical error is "Failed to parse negTokenTarg at
offset
54", which looks like it's being caused by the call
asn1_start_tag(&data, ASN1_CONTEXT(2));
in parse_negTokenTarg().
Here's an excerpt from the smbd log with debug=10:
[2008/08/01 16:07:07, 3] smbd/process.c:switch_message(886)
switch message SMBsesssetupX (pid 5281) conn 0x0
[2008/08/01 16:07:07, 3] smbd/sec_ctx.c:set_sec_ctx(288)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2008/08/01 16:07:07, 5] auth/auth_util.c:debug_nt_user_token(486)
NT user token: (NULL)
[2008/08/01 16:07:07, 5] auth/auth_util.c:debug_unix_user_token(505)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
[2008/08/01 16:07:07, 5] smbd/uid.c:change_to_root_user(296)
change_to_root_user: now uid=(0,0) gid=(0,0)
[2008/08/01 16:07:07, 3] smbd/sesssetup.c:reply_sesssetup_and_X(655)
wct=12 flg2=0xc801
[2008/08/01 16:07:07, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego
(535)
Doing spnego session setup
[2008/08/01 16:07:07, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego
(566)
NativeOS=[Mac OS X 10.5] NativeLanMan=[SMBFS 1.4.2] PrimaryDomain=[]
[2008/08/01 16:07:07, 1] libsmb/clispnego.c:parse_negTokenTarg(251)
Failed to parse negTokenTarg at offset 54
[2008/08/01 16:07:07, 3] smbd/error.c:error_packet(129)
error packet at smbd/sesssetup.c(425) cmd=115 (SMBsesssetupX)
NT_STATUS_LOGON_FAILURE
For comparison, here's the corresponding excerpt from the log of a
successful
connection from a MacOS 10.4.11 client:
[2008/08/01 10:40:05, 3] smbd/process.c:switch_message(886)
switch message SMBsesssetupX (pid 4681) conn 0x0
[2008/08/01 10:40:05, 3] smbd/sec_ctx.c:set_sec_ctx(288)
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2008/08/01 10:40:05, 5] auth/auth_util.c:debug_nt_user_token(486)
NT user token: (NULL)
[2008/08/01 10:40:05, 5] auth/auth_util.c:debug_unix_user_token(505)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
[2008/08/01 10:40:05, 5] smbd/uid.c:change_to_root_user(296)
change_to_root_user: now uid=(0,0) gid=(0,0)
[2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_sesssetup_and_X(655)
wct=12 flg2=0xc801
[2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego
(535)
Doing spnego session setup
[2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego
(566)
NativeOS=[MacOSX] NativeLanMan=[NETSMB] PrimaryDomain=[]
[2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_spnego_negotiate(444)
Got OID 1 2 840 48018 1 2 2
[2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_spnego_negotiate(447)
Got secblob of size 1438
[2008/08/01 10:40:05, 10] passdb/secrets.c:secrets_named_mutex(702)
secrets_named_mutex: got mutex for replay cache mutex
[2008/08/01 10:40:05, 10] lib/util.c:name_to_fqdn(2626)
name_to_fqdn: lookup for LAGOS -> LAGOS.Stanford.EDU.
Here's an excerpt from the packet containing the data block Samba can't
parse (captured by wireshark); I think the problem is the section
labeled
"Padding" and "reqFlags" inside the security blob:
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
[Response in: 78]
SMB Command: Session Setup AndX (0x73)
NT Status: STATUS_SUCCESS (0x00000000)
Flags: 0x08
Flags2: 0xc801
Session Setup AndX Request (0x73)
Word Count (WCT): 12
AndXCommand: No further commands (0xff)
Reserved: 00
AndXOffset: 0
Max Buffer: 16644
Max Mpx Count: 50
VC Number: 111
Session Key: 0x000013d3
Security Blob Length: 2414
Reserved: 00000000
Capabilities: 0x8080c05c
Byte Count (BCC): 2467
Security Blob: 6082096A06062B0601050502A082095E3082095AA0...
GSS-API Generic Security Service Application Program
Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected
Negotiation)
SPNEGO
negTokenInit
mechTypes: 3 items
Item: 1.2.840.113554.1.2.2 (KRB5 -
Kerberos 5)
Item: 1.3.5.1.5.2 (SNMPv2-SMI::org.5.1.5.2)
Item: 1.2.840.48018.1.2.2 (MS KRB5 -
Microsoft K5)
Padding: 1
reqFlags: 04 (confFlag)
0... .... = delegFlag: False
.0.. .... = mutualFlag: False
..0. .... = replayFlag: False
...0 .... = sequenceFlag: False
.... 0... = anonFlag: False
.... .1.. = confFlag: True
.... ..0. = integFlag: False
mechToken:
6082092706092A864886F71201020201006E82...
krb5_blob:
6082092706092A864886F71201020201006E82...
KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 -
Kerberos 5)
krb5_tok_id: KRB5_AP_REQ (0x0001)
Kerberos AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 20000000 (Mutual required)
.0.. .... = Use Session Key: Do
NOT use
..1. .... = Mutual required: is
REQUIRED
Ticket
Tkt-vno: 5
Realm: SU.WIN.STANFORD.EDU
Server Name (Principal): cifs/
lagos.stanford.edu
Name-type: Principal (1)
Name: cifs
Name: lagos.stanford.edu
enc-part rc4-hmac
Encryption type: rc4-hmac (23)
Kvno: 2
enc-part:
8D9C6DF702209BE400D2C64...
Authenticator rc4-hmac
Encryption type: rc4-hmac (23)
Authenticator data:
0424F0322CEF59C261...
Native OS: Mac OS X 10.5
Native LAN Manager: SMBFS 1.4.2
Here's the hex dump of the packet itself (Reassembled TCP (2530 bytes)).
The security blob starts at byte 0x3f, and the 54th byte of that blob
(byte
0x74 of the packet) is a byte = 0xa1, not 0xa2 as the parser expects.
The
expected 0xa2 byte occurs at byte 0x7a:
0000 00 00 09 de ff 53 4d 42 73 00 00 00 00 08 01 c8 .....SMBs.......
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 ................
0020 00 00 01 00 0c ff 00 00 00 04 41 32 00 6f 00 d3 ..........A2.o..
0030 13 00 00 6e 09 00 00 00 00 5c c0 80 80 a3 09 60 ...n.....\.....`
0040 82 09 6a 06 06 2b 06 01 05 05 02 a0 82 09 5e 30 ..j..+........^0
0050 82 09 5a a0 1f 30 1d 06 09 2a 86 48 86 f7 12 01 ..Z..0...*.H....
0060 02 02 06 05 2b 05 01 05 02 06 09 2a 86 48 82 f7 ....+......*.H..
0070 12 01 02 02 a1 04 03 02 01 04 a2 82 09 2f 04 82 ............./..
0080 09 2b 60 82 09 27 06 09 2a 86 48 86 f7 12 01 02 .+`..'..*.H.....
0090 02 01 00 6e 82 09 16 30 82 09 12 a0 03 02 01 05 ...n...0........
00a0 a1 03 02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 .......... .....
00b0 08 3e 61 82 08 3a 30 82 08 36 a0 03 02 01 05 a1 .>a..:0..6......
00c0 15 1b 13 53 55 2e 57 49 4e 2e 53 54 41 4e 46 4f ...SU.WIN.STANFO
00d0 52 44 2e 45 44 55 a2 25 30 23 a0 03 02 01 01 a1 RD.EDU.%0#......
00e0 1c 30 1a 1b 04 63 69 66 73 1b 12 6c 61 67 6f 73 .0...cifs..lagos
00f0 2e 73 74 61 6e 66 6f 72 64 2e 65 64 75 a3 82 07 .stanford.edu...
<snip>
For comparison, here's a packet captured during a successful
connection from
a non-Leopard Mac. Note that there is no Padding or reqFlags between the
mechTypes Item and the mechToken:
SMB (Server Message Block Protocol)
SMB Header
Server Component: SMB
SMB Command: Session Setup AndX (0x73)
NT Status: STATUS_SUCCESS (0x00000000)
Flags: 0x08
Flags2: 0x4801
Session Setup AndX Request (0x73)
Word Count (WCT): 12
AndXCommand: No further commands (0xff)
AndXOffset: 0
VC Number: 2
Session Key: 0x00004b58
Security Blob Length: 2354
Capabilities: 0x8000004c
Byte Count (BCC): 2368
Security Blob:
6082092E06062B0601050502A08209223082091EA00D300B...
GSS-API Generic Security Service Application Program
Interface
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected
Negotiation)
SPNEGO
negTokenInit
mechTypes: 1 item
Item: 1.2.840.48018.1.2.2 (MS KRB5 -
Microsoft K5)
mechToken:
6082090306092A864886F71201020201006E82...
krb5_blob:
6082090306092A864886F71201020201006E82...
KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 -
Kerberos 5)
krb5_tok_id: KRB5_AP_REQ (0x0001)
Kerberos AP-REQ
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 00000000
Ticket
Tkt-vno: 5
Realm: SU.WIN.STANFORD.EDU
Server Name (Principal): cifs/
sesfs.stanford.edu
Name-type: Principal (1)
Name: cifs
Name: sesfs.stanford.edu
enc-part rc4-hmac
Encryption type: rc4-hmac (23)
Kvno: 2
enc-part:
24F85A3983BE0989B20CC51F...
Authenticator des-cbc-md5
Encryption type: des-cbc-md5 (3)
Authenticator data:
ADB975580F588B675C...
Native OS: MacOSX
Native LAN Manager: NETSMB
Finally, here's the dump of the successful packet (Reassembled TCP (2431
bytes)). As before, the security blob starts at byte 0x3f, but in this
packet, at byte 0x62 (the 36th byte of the security blob), we have a
byte of
0xa2, like the parser is expecting.
0000 00 00 09 7b ff 53 4d 42 73 00 00 00 00 08 01 48 ...{.SMBs......H
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 ................
0020 00 00 01 00 0c ff 00 00 00 04 41 32 00 02 00 58 ..........A2...X
0030 4b 00 00 32 09 00 00 00 00 4c 00 00 80 40 09 60 K..2.....L...@.`
0040 82 09 2e 06 06 2b 06 01 05 05 02 a0 82 09 22 30 .....+........"0
0050 82 09 1e a0 0d 30 0b 06 09 2a 86 48 82 f7 12 01 .....0...*.H....
0060 02 02 a2 82 09 0b 04 82 09 07 60 82 09 03 06 09 ..........`.....
0070 2a 86 48 86 f7 12 01 02 02 01 00 6e 82 08 f2 30 *.H........n...0
0080 82 08 ee a0 03 02 01 05 a1 03 02 01 0e a2 07 03 ................
0090 05 00 00 00 00 00 a3 82 08 46 61 82 08 42 30 82 .........Fa..B0.
00a0 08 3e a0 03 02 01 05 a1 15 1b 13 53 55 2e 57 49 .>.........SU.WI
00b0 4e 2e 53 54 41 4e 46 4f 52 44 2e 45 44 55 a2 25 N.STANFORD.EDU.%
00c0 30 23 a0 03 02 01 01 a1 1c 30 1a 1b 04 63 69 66 0#.......0...cif
00d0 73 1b 12 73 65 73 66 73 2e 73 74 61 6e 66 6f 72 s..sesfs.stanfor
00e0 64 2e 65 64 75 a3 82 07 f7 30 82 07 f3 a0 03 02 d.edu....0......
<snip>
I've posted the full text of the log files and packet displays on the
web at:
http://www.stanford.edu/~lanz/leopard-samba/
Does this analysis look correct? And if so, is this something that
can be
patched in Samba?
--
Kai Lanz Stanford University School of Earth Sciences
Jeremy Allison
2008-Aug-05 20:37 UTC
[Samba] Leopard Macs using Kerberos: Failed to parse negTokenTarg
On Tue, Aug 05, 2008 at 01:02:49PM -0700, Kai Lanz wrote:> > I think I've found out why MacOS 10.5.x (Leopard) clients are unable to > connect to Samba shares when authenticating with Kerberos. Basically, > the > Leopard Macs insert a few extra bytes (Padding and reqFlags, according to > wireshark) into the security blob within the Session Setup AndX Request > packet, bytes whose start tag is 0xa1, in a spot where Samba's parser > expects 0xa2. The critical error is "Failed to parse negTokenTarg at > offset > 54", which looks like it's being caused by the call > > asn1_start_tag(&data, ASN1_CONTEXT(2)); > > in parse_negTokenTarg().In Samba 3.2.0 and 3.2.1 this is fixed by the following code in parse_negTokenTarg(). /* Skip any optional req_flags that are sent per RFC 4178 */ if (asn1_check_tag(&data, ASN1_CONTEXT(1))) { uint8 flags; asn1_start_tag(&data, ASN1_CONTEXT(1)); asn1_start_tag(&data, ASN1_BITFIELD); while (asn1_tag_remaining(&data) > 0) asn1_read_uint8(&data, &flags); asn1_end_tag(&data); asn1_end_tag(&data); } I'd try an upgrade :-). Jeremy.
James Peach
2008-Aug-05 20:41 UTC
[Samba] Leopard Macs using Kerberos: Failed to parse negTokenTarg
2008/8/5 Kai Lanz <lanz@stanford.edu>:> > I think I've found out why MacOS 10.5.x (Leopard) clients are unable to > connect to Samba shares when authenticating with Kerberos. Basically, the > Leopard Macs insert a few extra bytes (Padding and reqFlags, according to > wireshark) into the security blob within the Session Setup AndX Request > packet, bytes whose start tag is 0xa1, in a spot where Samba's parser > expects 0xa2. The critical error is "Failed to parse negTokenTarg at offset > 54", which looks like it's being caused by the call > > asn1_start_tag(&data, ASN1_CONTEXT(2)); > > in parse_negTokenTarg(). > > Here's an excerpt from the smbd log with debug=10: > > [2008/08/01 16:07:07, 3] smbd/process.c:switch_message(886) > switch message SMBsesssetupX (pid 5281) conn 0x0 > [2008/08/01 16:07:07, 3] smbd/sec_ctx.c:set_sec_ctx(288) > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > [2008/08/01 16:07:07, 5] auth/auth_util.c:debug_nt_user_token(486) > NT user token: (NULL) > [2008/08/01 16:07:07, 5] auth/auth_util.c:debug_unix_user_token(505) > UNIX token of user 0 > Primary group is 0 and contains 0 supplementary groups > [2008/08/01 16:07:07, 5] smbd/uid.c:change_to_root_user(296) > change_to_root_user: now uid=(0,0) gid=(0,0) > [2008/08/01 16:07:07, 3] smbd/sesssetup.c:reply_sesssetup_and_X(655) > wct=12 flg2=0xc801 > [2008/08/01 16:07:07, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(535) > Doing spnego session setup > [2008/08/01 16:07:07, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(566) > NativeOS=[Mac OS X 10.5] NativeLanMan=[SMBFS 1.4.2] PrimaryDomain=[] > [2008/08/01 16:07:07, 1] libsmb/clispnego.c:parse_negTokenTarg(251) > Failed to parse negTokenTarg at offset 54 > [2008/08/01 16:07:07, 3] smbd/error.c:error_packet(129) > error packet at smbd/sesssetup.c(425) cmd=115 (SMBsesssetupX) > NT_STATUS_LOGON_FAILURE > > For comparison, here's the corresponding excerpt from the log of a > successful > connection from a MacOS 10.4.11 client: > > [2008/08/01 10:40:05, 3] smbd/process.c:switch_message(886) > switch message SMBsesssetupX (pid 4681) conn 0x0 > [2008/08/01 10:40:05, 3] smbd/sec_ctx.c:set_sec_ctx(288) > setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 > [2008/08/01 10:40:05, 5] auth/auth_util.c:debug_nt_user_token(486) > NT user token: (NULL) > [2008/08/01 10:40:05, 5] auth/auth_util.c:debug_unix_user_token(505) > UNIX token of user 0 > Primary group is 0 and contains 0 supplementary groups > [2008/08/01 10:40:05, 5] smbd/uid.c:change_to_root_user(296) > change_to_root_user: now uid=(0,0) gid=(0,0) > [2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_sesssetup_and_X(655) > wct=12 flg2=0xc801 > [2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(535) > Doing spnego session setup > [2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_sesssetup_and_X_spnego(566) > NativeOS=[MacOSX] NativeLanMan=[NETSMB] PrimaryDomain=[] > [2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_spnego_negotiate(444) > Got OID 1 2 840 48018 1 2 2 > [2008/08/01 10:40:05, 3] smbd/sesssetup.c:reply_spnego_negotiate(447) > Got secblob of size 1438 > [2008/08/01 10:40:05, 10] passdb/secrets.c:secrets_named_mutex(702) > secrets_named_mutex: got mutex for replay cache mutex > [2008/08/01 10:40:05, 10] lib/util.c:name_to_fqdn(2626) > name_to_fqdn: lookup for LAGOS -> LAGOS.Stanford.EDU. > > Here's an excerpt from the packet containing the data block Samba can't > parse (captured by wireshark); I think the problem is the section labeled > "Padding" and "reqFlags" inside the security blob: > > SMB (Server Message Block Protocol) > SMB Header > Server Component: SMB > [Response in: 78] > SMB Command: Session Setup AndX (0x73) > NT Status: STATUS_SUCCESS (0x00000000) > Flags: 0x08 > Flags2: 0xc801 > Session Setup AndX Request (0x73) > Word Count (WCT): 12 > AndXCommand: No further commands (0xff) > Reserved: 00 > AndXOffset: 0 > Max Buffer: 16644 > Max Mpx Count: 50 > VC Number: 111 > Session Key: 0x000013d3 > Security Blob Length: 2414 > Reserved: 00000000 > Capabilities: 0x8080c05c > Byte Count (BCC): 2467 > Security Blob: 6082096A06062B0601050502A082095E3082095AA0... > GSS-API Generic Security Service Application Program Interface > OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) > SPNEGO > negTokenInit > mechTypes: 3 items > Item: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5) > Item: 1.3.5.1.5.2 (SNMPv2-SMI::org.5.1.5.2) > Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft > K5) > Padding: 1 > reqFlags: 04 (confFlag) > 0... .... = delegFlag: False > .0.. .... = mutualFlag: False > ..0. .... = replayFlag: False > ...0 .... = sequenceFlag: False > .... 0... = anonFlag: False > .... .1.. = confFlag: True > .... ..0. = integFlag: False > mechToken: 6082092706092A864886F71201020201006E82... > krb5_blob: 6082092706092A864886F71201020201006E82... > KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos > 5) > krb5_tok_id: KRB5_AP_REQ (0x0001) > Kerberos AP-REQ > Pvno: 5 > MSG Type: AP-REQ (14) > Padding: 0 > APOptions: 20000000 (Mutual required) > .0.. .... = Use Session Key: Do NOT use > ..1. .... = Mutual required: is REQUIRED > Ticket > Tkt-vno: 5 > Realm: SU.WIN.STANFORD.EDU > Server Name (Principal): cifs/lagos.stanford.edu > Name-type: Principal (1) > Name: cifs > Name: lagos.stanford.edu > enc-part rc4-hmac > Encryption type: rc4-hmac (23) > Kvno: 2 > enc-part: 8D9C6DF702209BE400D2C64... > Authenticator rc4-hmac > Encryption type: rc4-hmac (23) > Authenticator data: 0424F0322CEF59C261... > Native OS: Mac OS X 10.5 > Native LAN Manager: SMBFS 1.4.2 > > Here's the hex dump of the packet itself (Reassembled TCP (2530 bytes)). > The security blob starts at byte 0x3f, and the 54th byte of that blob (byte > 0x74 of the packet) is a byte = 0xa1, not 0xa2 as the parser expects. The > expected 0xa2 byte occurs at byte 0x7a: > > 0000 00 00 09 de ff 53 4d 42 73 00 00 00 00 08 01 c8 .....SMBs....... > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 ................ > 0020 00 00 01 00 0c ff 00 00 00 04 41 32 00 6f 00 d3 ..........A2.o.. > 0030 13 00 00 6e 09 00 00 00 00 5c c0 80 80 a3 09 60 ...n.....\.....` > 0040 82 09 6a 06 06 2b 06 01 05 05 02 a0 82 09 5e 30 ..j..+........^0 > 0050 82 09 5a a0 1f 30 1d 06 09 2a 86 48 86 f7 12 01 ..Z..0...*.H.... > 0060 02 02 06 05 2b 05 01 05 02 06 09 2a 86 48 82 f7 ....+......*.H.. > 0070 12 01 02 02 a1 04 03 02 01 04 a2 82 09 2f 04 82 ............./.. > 0080 09 2b 60 82 09 27 06 09 2a 86 48 86 f7 12 01 02 .+`..'..*.H..... > 0090 02 01 00 6e 82 09 16 30 82 09 12 a0 03 02 01 05 ...n...0........ > 00a0 a1 03 02 01 0e a2 07 03 05 00 20 00 00 00 a3 82 .......... ..... > 00b0 08 3e 61 82 08 3a 30 82 08 36 a0 03 02 01 05 a1 .>a..:0..6...... > 00c0 15 1b 13 53 55 2e 57 49 4e 2e 53 54 41 4e 46 4f ...SU.WIN.STANFO > 00d0 52 44 2e 45 44 55 a2 25 30 23 a0 03 02 01 01 a1 RD.EDU.%0#...... > 00e0 1c 30 1a 1b 04 63 69 66 73 1b 12 6c 61 67 6f 73 .0...cifs..lagos > 00f0 2e 73 74 61 6e 66 6f 72 64 2e 65 64 75 a3 82 07 .stanford.edu... > <snip> > > For comparison, here's a packet captured during a successful connection from > a non-Leopard Mac. Note that there is no Padding or reqFlags between the > mechTypes Item and the mechToken: > > SMB (Server Message Block Protocol) > SMB Header > Server Component: SMB > SMB Command: Session Setup AndX (0x73) > NT Status: STATUS_SUCCESS (0x00000000) > Flags: 0x08 > Flags2: 0x4801 > Session Setup AndX Request (0x73) > Word Count (WCT): 12 > AndXCommand: No further commands (0xff) > AndXOffset: 0 > VC Number: 2 > Session Key: 0x00004b58 > Security Blob Length: 2354 > Capabilities: 0x8000004c > Byte Count (BCC): 2368 > Security Blob: 6082092E06062B0601050502A08209223082091EA00D300B... > GSS-API Generic Security Service Application Program Interface > OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) > SPNEGO > negTokenInit > mechTypes: 1 item > Item: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft > K5) > mechToken: 6082090306092A864886F71201020201006E82... > krb5_blob: 6082090306092A864886F71201020201006E82... > KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos > 5) > krb5_tok_id: KRB5_AP_REQ (0x0001) > Kerberos AP-REQ > Pvno: 5 > MSG Type: AP-REQ (14) > Padding: 0 > APOptions: 00000000 > Ticket > Tkt-vno: 5 > Realm: SU.WIN.STANFORD.EDU > Server Name (Principal): cifs/sesfs.stanford.edu > Name-type: Principal (1) > Name: cifs > Name: sesfs.stanford.edu > enc-part rc4-hmac > Encryption type: rc4-hmac (23) > Kvno: 2 > enc-part: 24F85A3983BE0989B20CC51F... > Authenticator des-cbc-md5 > Encryption type: des-cbc-md5 (3) > Authenticator data: ADB975580F588B675C... > Native OS: MacOSX > Native LAN Manager: NETSMB > > Finally, here's the dump of the successful packet (Reassembled TCP (2431 > bytes)). As before, the security blob starts at byte 0x3f, but in this > packet, at byte 0x62 (the 36th byte of the security blob), we have a byte of > 0xa2, like the parser is expecting. > > 0000 00 00 09 7b ff 53 4d 42 73 00 00 00 00 08 01 48 ...{.SMBs......H > 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 ................ > 0020 00 00 01 00 0c ff 00 00 00 04 41 32 00 02 00 58 ..........A2...X > 0030 4b 00 00 32 09 00 00 00 00 4c 00 00 80 40 09 60 K..2.....L...@.` > 0040 82 09 2e 06 06 2b 06 01 05 05 02 a0 82 09 22 30 .....+........"0 > 0050 82 09 1e a0 0d 30 0b 06 09 2a 86 48 82 f7 12 01 .....0...*.H.... > 0060 02 02 a2 82 09 0b 04 82 09 07 60 82 09 03 06 09 ..........`..... > 0070 2a 86 48 86 f7 12 01 02 02 01 00 6e 82 08 f2 30 *.H........n...0 > 0080 82 08 ee a0 03 02 01 05 a1 03 02 01 0e a2 07 03 ................ > 0090 05 00 00 00 00 00 a3 82 08 46 61 82 08 42 30 82 .........Fa..B0. > 00a0 08 3e a0 03 02 01 05 a1 15 1b 13 53 55 2e 57 49 .>.........SU.WI > 00b0 4e 2e 53 54 41 4e 46 4f 52 44 2e 45 44 55 a2 25 N.STANFORD.EDU.% > 00c0 30 23 a0 03 02 01 01 a1 1c 30 1a 1b 04 63 69 66 0#.......0...cif > 00d0 73 1b 12 73 65 73 66 73 2e 73 74 61 6e 66 6f 72 s..sesfs.stanfor > 00e0 64 2e 65 64 75 a3 82 07 f7 30 82 07 f3 a0 03 02 d.edu....0...... > <snip> > > I've posted the full text of the log files and packet displays on the web > at: > > http://www.stanford.edu/~lanz/leopard-samba/ > > Does this analysis look correct?yes> And if so, is this something that can be patched in Samba?Fixed in Samba 3.2 .. <http://git.samba.org/?p=samba.git;a=commit;h=59a2bcf30fef14ecc826271862b645dd3a61cb48> -- James Peach | jorgar@gmail.com