Wow. Hiya Andrew,
OK, this sounds like a very promising approach, and potentially saves me working through a large number of "git bisect"s (as also most helpfully suggested by Michael Wood) - so far, I'm right back into the beta code and there have been a lot of commits since then... I'm not easily in a position to set up a test domain for this, but I have no problem with your suggestion of capturing on the live domain and sending to you (especially since changing the password doesn't affect the issue). Or of dumping the information and decoding the PAC using "ndrdump" (wasn't aware of that). I'll work through your suggestions and see if I can get anywhere; when I reach a stage where I can't figure it out any further I'll send you what I've got. Any useful conclusions that don't contain sensitive information, I'll put back onto this thread in case they're of use to anyone else as well. It will probably take me a few days to get anywhere useful, as I can only really poke this out of normal working hours. So if there's no update for a few days, please don't think that means I've stopped. BTW, to answer your question, access is based on the username not the full name (haven't tried that, which in itself is an interesting point - not sure whether that would affect it as presumably that just forms an alternative mapping back to the underlying internal AD entity, but ...). Many thanks, I'll update as soon as I can. Cheers! Tris. -----Original Message----- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: 26 February 2013 11:05 To: Tris Mabbs Cc: samba@lists.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). On Mon, 2013-02-25 at 11:51 +0000, Tris Mabbs wrote: > Hello, >... > When accessing our main server using that account, "smbd" always > reports "can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL". This has > come from "../auth/kerberos/kerberos_pac.c:149(kerberos_decode_pac)", > trying to use NDR to pull a blob from the Kerberos ticket (that's > reported as > "ndr_pull_error(11): Pull bytes 34 (../librpc/ndr/ndr_string.c:591)"). >... 'Clearly' (as in, clear as mud, but the general direction to look at) either the IDL in librpc/idl/krb5pac.idl is incorrect, or the parsing code in Heimdal in unpacking this particular user's PAC incorrectly. It is interesting that this user causes the issue regardless of being re-created. Is this triggered on their full or user name? Does this happen if you set up a new testing domain? If so, what would be really, really helpful would be a network capture including the server keytab. (Or if you don't mind, and change the server password after, on your live domain to me personally). The procedure you or I will need to follow is to extract the decrypted 'PAC'. You could do this either from wireshark (export selected packet bytes, after running wireshark -k /tmp/server.keytab, or by patching the code to call: _PUBLIC_ bool file_save(const char *fname, const void *packet, size_t length) somewhere near auth3_generate_session_info_pac() Then, using that file, run bin/ndrdump krb5pac decode_pac in /tmp/pac Then essentially we keep changing the idl in librpc/idl/krb5pac.idl and the C helpers in librpc/ndr/ndr_krb5pac.c until this works. See also http://msdn.microsoft.com/en-us/library/cc237917.aspx Good luck! Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
