[Samba] "Samba 4" - "smbd"; "can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL" error but only for a single domain user ("Server 2008 R2" domain, "Server 2008" functional level forest).

[Andrew Bartlett]

On Tue, 2013-02-26 at 22:58 +0000, Tris Mabbs wrote:
> So, I have some results.
> 
> Interesting (well, I thought so anyway :-)
> 
> First, as suggested, I put some code into "source3/auth/auth_generic.c" ("somewhere near auth3_generate_session_info_pac()") as follows:

I do so enjoy working with users who I can ask to 'put some code in' and
who can handle this so well :-).

> That was very slightly more complicated as I wanted to use the
> Kerberos principal name (if known) in creating the dump file name, so
> it would be easy to work out which dump file was which.
> 
> In leaving that code running for a while, it was perhaps of interest
> to note that although several user accounts caused dump files to be
> created named with their Kerberos principal name, this did not happen
> at all for the problematic user.  I'm not sure whether or not that's
> significant, but I thought it at least worth mentioning - I'm not sure
> what the potential code paths are into this function which may, or may
> not, result in the principal name being known on entry ...

I think it is quite significant.  We should dig into this some more,
once we sort out the PAC.

> Anyway, what it did get me were some NDR encoded Kerberos PAC dumps,
> including ones for the problematic user.
> So, following Andrew's instructions, I ran (for example) "ndrdump
> krb5pac decode_pac in /var/tmp/PAC-NDR-1819" to examine what lay
> therein.
> 
> I'm not going to post the actual significant data to a public forum
> (obviously; and yes I know that writing the PAC dumps into "/var/tmp/"
> with no particular control over permissions etc. isn't the best
> security policy in the world, but it was fine for this testing, esp.
> since I'm the only sysadmin on this particular box ...).  However
> these parts may be of general interest:
> 
> --------
> % ndrdump krb5pac decode_pac in /var/tmp/PAC-NDR-1819
> pull returned NT_STATUS_BUFFER_TOO_SMALL
> WARNING! 136 unread bytes
> ...
>     decode_pac: struct decode_pac
>         in: struct decode_pac
>             pac: struct PAC_DATA
>                 num_buffers              : 0x00000005 (5)
>                 version                  : 0x00000000 (0)
>                 buffers: ARRAY(5)
>                     buffers: struct PAC_BUFFER
>                         type                     : PAC_TYPE_LOGON_INFO (1)
>                         _ndr_size                : 0x00000248 (584)
>                         info                     : *
>                             info                     : union PAC_INFO(case 1)
>                             logon_info: struct PAC_LOGON_INFO_CTR
>                                 info                     : *
>                                     info: struct PAC_LOGON_INFO
>                                         info3: struct netr_SamInfo3
>                                             base: struct netr_SamBaseInfo
> <load of correctly dumped information>
> ===============================================================
> INTERNAL ERROR: Signal 11 in pid 8122 (4.1.0pre1-GIT-3e5acc1)
> Please read the Trouble-Shooting section of the Samba HOWTO
> ===============================================================
> PANIC: internal error

I don't get the panic, so getting a 'bt full' on that under gdb would be
very helpful.  

gdb --args 'ndrdump krb5pac decode_pac' in /var/tmp/PAC-NDR-1819

Even a bad decode should never crash Samba, so something is going quite
wrong here, hopefully only in a manual parser. 

> Abort (core dumped)
> %
> --------
> 
> So, same symptoms (as one would expect) in trying to dump out the PAC, followed by a core dump.  The information actually dumped out was correct in every detail, so the information is at least mostly correctly being decoded.
> 
> Andrew, I'll send you over the "/var/tmp/PAC-NDR-1819" file to look at, if that's still OK with you - hopefully you'll be able to make sense of what's causing the apparent misinterpretation of the PAC data.

I got it, and I ran an automated git bisect on our big server.  The
problem commit is apparently:

a6be8a97f705247c1b1cbb0595887d8924740a71 is the first bad commit
commit a6be8a97f705247c1b1cbb0595887d8924740a71
Author: Simo Sorce <idra at samba.org>
Date:   Thu Sep 27 14:12:06 2012 -0400

    Support UPN_DNS_INFO in the PAC
    
    Previously marked as UNKNOWN_12 the UPN_DNS_INFO is defined in
MS-PAC
    
    Autobuild-User(master): Simo Sorce <idra at samba.org>
    Autobuild-Date(master): Fri Sep 28 01:13:44 CEST 2012 on
sn-devel-104

I've CC'ed Simo who made the change, and GD who is working on improving
our PAC handling (he has a series of patches under development, which
may already solve your issue).  Hopefully they can sort things out from
here.

Samba 4.0.x is unaffected, this change is only in master.

If you can contribute your PAC to the public realm (the PAC itself does
not contain passwords, but you will need to read the full dump to
determine if any other details might be a problem), then I know it will
be very much appreciated, as we can add tests to show that these exotic
samples continue to work. 

(Otherwise, and perhaps more reasonably, if you can pin down what,
presumably UPN related, you did for this user, we might be able to
reproduce this ourselves). 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org