[Samba] Leopard Macs using Kerberos: Failed to parse negTokenTarg
James Peach
jorgar at gmail.com
Tue Aug 5 20:34:30 GMT 2008
2008/8/5 Kai Lanz <lanz at 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... at .`
> 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 at gmail.com
More information about the samba
mailing list