[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