[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).

[Tris Mabbs]

Good day, one and all ...

I just had to rebuild our main Samba server ("OpenSlowlaris" -> "Slowlaris 11.11"), during which I put the latest (at the time; currently 4.2.0pre1-GIT-b505111) Samba4 on there.  I thought that by now that Gunther's speculative changes to improve the PAC decode might have made their way into the trunk revision - obviously I was wrong, as I'm once again getting a load of "Can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL" messages and a user who can't access any Samba shares.

Whoops ...

So as we previously discussed looking into things in more detail (specifically finding out why there is no "client_principal" being passed into "kerberos_decode_pac()"), but nothing else ever happened, is there anything I can do to assist in getting the improved PAC decoding included into the trunk revision?  Whilst I can't guarantee immediate responses to any request, I'm quite happy to stick any code in anywhere you might want if you don't mind potentially waiting a day or so for the results :-)

Also:
I appreciate this is off-topic, but I was wondering whether anyone is interested in/would like me to open a separate thread on any of these ...
Built the code, installed the code, set it up (joined the domain, etc. etc. etc. etc.).  Had 2(-and-a-bit) problems (one of which I've fixed):
	1. Although "bin/default/source3/winbindd/idmap_ad_4.o" gets built, "bin/default/source3/winbindd/libidmap-ad.so" doesn't, so "<TARGDIR>/lib/idmap/ad.so" doesn't get installed.  No "ad" idmap backend; no AD UID/SID mapping; much administrator (me) confusion if said administrator is expecting AD UID/SID mapping to work ...
	  I'd completely forgotten about this little "hiccup" - it's been a while since I initially shoe-horned Samba4 onto "OpenSlowlaris", but fortunately I'd made a note of this in the build script I used so after 2 days of banging my head against a wall, I finally remembered to check my own darn' script and saw the comment "If ''/usr/local/samba/lib/idmap/ad.so'' doesn't build and install then ...".  Bang bang bang bang ...  Doh!
	   Linked "libidmap-ad.so" manually and copied into "/usr/local/samba/lib/idmap/ad.so" and, as if by magic, my UID/SID mapping started working ...
	2. "net ads testjoin" works; "wbinfo -t" works (as do "wbinfo -u", "wbinfo -g", ....).  In fact everything works (after installing "ad.so"!) *except* ...  If I do a "net rpc testjoin" (and remember, "wbinfo -t" *does* work here) I get an error stating that it can't connect to "GATEWAY" (local server name) and therefore the join to the "FIRSTGRADE" domain isn't valid.
	   Duh?
	   So for some reason, "net rpc testjoin" is trying to connect to the local server rather than any DC for the domain.  No particular reason apparent in the log files, and it doesn't seem to be affecting anything, but it is an odd disparity.  Ramped up debugging but couldn't see any sensible explanation in the logs ...
	[3. Kinda ...  Sorta ...  Can't build Samba4 on "Slowlaris 11.11" without complaints about "no ldap_add_result_entry() support in LDAP libs!" filling every log file on the system.
	    So I kicked and forced and prodded and poked and finally managed to persuade Samba to build using OpenLDAP-2.4, which gets rid of this problem.
	    However that involved fiddling with "CPPFLAGS" and "LDFLAGS" before calling any build scripts; it's nasty, messy and dirty - I don't approve of any "solution" which involves that sort of messing around (yuk).  There has to be a better way ...
	    From looking at other discussions, it seems Samba4 as a DC isn't supported (yet?) using OpenLDAP, but might it be worthwhile providing some way to "encourage" the use of OpenLDAP, rather than the OS native LDAP (whatever that may be), if it *can* be used?  Perhaps a "--I-cant-believe-its-not-OpenLDAP" flag of some sort (sorry, British humour - that probably doesn't mean anything to anyone else ...)?]
If you think it's worth opening a thread on any of these (probably, I'd guess, in the main Samba discussion rather than Samba-Technical?) then please say so and I'll do so.  Otherwise I'll continue quietly to ignore them :-)

Many thanks folks, and have a great week/weekend,

Cheers,

Tris.

-----Original Message-----
From: Tris Mabbs [mailto:TM-Samba201302 at Firstgrade.Co.UK] 
Sent: 15 March 2013 17:59
To: Andrew Bartlett
Cc: 'Michael Wood'; Guenther Deschner; samba at lists.samba.org; samba-technical at samba.org
Subject: RE: [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).

>> 	So it seems that with these changes, "kerberos_decode_pac()" is 
>> never entered with "client_principal" anything other than a NULL pointer.
>> 
>> So I'm (very) happy that these changes fix my problem.  However it 
>> does seem a little curious that "client_principal" now never appears 
>> to be set - I don't know whether that's expected behaviour?
>
> It isn't, we need to look into that some more. 

	More than happy to - let me know what you want put where and it'll be done.

	Meanwhile, having cleared them out recently, I currently have ~3,600 PAC dumps, not a single one with the Kerberos principal in the name (every one's a PID based name).

	On the plus side, still nary a core dump:

------->Cut here:
# find /var/samba4/log/cores/ -type f
#
<-------Cut here.

> Does the ndrdump run you did before now pass fine?

	Yes, runs perfectly:

------->Cut here:
% /var/tmp/samba/samba-master/samba-gd/bin/ndrdump krb5pacdecode_pac in PAC-NDR-1819 pull returned NT_STATUS_OK
    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

...

                    buffers: struct PAC_BUFFER
                        type                     : PAC_TYPE_KDC_CHECKSUM (7)
                        _ndr_size                : 0x00000014 (20)
                        info                     : *
                            info                     : union PAC_INFO(case 7)
                            kdc_cksum: struct PAC_SIGNATURE_DATA
                                type                     : KERB_CHECKSUM_HMAC_MD
5 (0xFFFFFF76)
                                signature                : DATA_BLOB length=16
[0000] 3B 96 CC BB BB 9D E4 57   13 C9 6D 1C 65 A0 B1 1B   ;......W ..m.e...
                                RODCIdentifier           : 0x0000 (0)
                        _pad                     : 0x00000000 (0)
dump OK
%
<------- Cut here.

Large amounts of data, all looking absolutely fine.

So definite progress ...

Many thanks, regards, and have a great weekend everyone,

Tris.