Hello,
We're having a problem with "Samba 4" joined to a "Server 2008 R2" domain (at "Server 2008" functional level across the forest). The interesting thing is that this only affects a single user - all other accounts work without problems. 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)"). I can't see any reason for the error affecting this one specific user. As the Kerberos PAC is mainly concerned with information such as supplemental groups, I've altered the group membership for the user. I've removed the user from all groups. I've even completely deleted and re-created the user (so a different SID, in case there was any corrupted cached information anywhere). Nothing makes any difference - that one user consistently gets this error, and no others do. I've even tried changing the Kerberos encryption types in case that had any effect (was it the result of a decryption problem?) but again, no difference. It's not a client problem either, as I've tried accessing the Samba shares from various different platforms (even including an embedded Linux based network media player - "Dune HD Max" - I happened to have on the network) - everything attempting to access as that user causes exactly the same problem. As this is happening in a call to the "NDR_PULL_NEED_BYTES()" macro, I modified that slightly to print out a bit more information. That resulted in "ndr_pull_error(11): Pull bytes 34, data_size=88, offset=58, unlikely(34)=1 (../librpc/ndr/ndr_string.c:591)", so it's quite right - pulling 34 bytes from 88 of data at an offset of 58 will exceed the size of the contents in the data buffer. So the question is either why is it trying to pull 34 bytes from offset 58 of 88 data bytes (is that number 34 correct or has that been mis-decoded?), why is the existing offset 58 (has something caused this to be set too far into the data buffer already?) or why is the data size 88 bytes (has this been decoded incorrectly somehow and should there be more?). At this point, my knowledge of the internals of Samba and Kerberos stopped me and I felt I had to ask people who know somewhat more than me - that would be the readers of this list! Incidentally, this used to work. We've been running "Samba 4" for quite a while; we're not using its' AD server facilities, but found it considerably easier to get the version 4 codebase to compile up and run on this server (running "OpenSolaris") - the version 3 codebase gets very fiddly to persuade to work with the "OpenSolaris" LDAP and Kerberos whereas the version 4 correctly figures it all out for itself very nicely thank you . We also periodically update the code as we have (since first moving to version 4) experienced occasional core-dumps. They don't cause a major problem, they're just a minor inconvenience, but it would be nice to lose that inconvenience and I trust the Samba developers to have beta code that's vastly more stable than most vendor's release code, so I don't mind periodically updating the code straight from the current source snapshot (via "git"). This user used not to have any problems, then about (from memory) 3 months ago a code update caused this problem. Unfortunately I don't know the precise version numbers at which it was working and at which it broke - pity as that would doubtless make it considerably easier to work out what might have caused the problem :-(. In poking around with "Google", I did find a single reference to a change in which the submitter said they had found exactly this error, again on just a single account, but unfortunately I can't locate the post again (despite searching my "Chrome" history). As I recall, the code change was committed anyway as it was just a single account which had experienced the problem and the change author didn't consider it to be significant. There's obviously a whole lot more information I could attach; "smb.conf" file, full debug traces, the fact that "wbinfo -u"/"wbinfo -g" etc. all work correctly, . but there didn't seem any point attaching any of that unless it would actually be useful. What might be useful info. is that "smbd -V" reports "Version 4.1.0pre1-GIT-3e5acc1"; "testparm" is happy, as is "net ads testjoin" (and "net rpc testjoin", for that matter). I'm not at all averse to going into the source code and adding debug code to dig this problem out - with over 30 years 'C' experience (including working as a kernel/system developer on "mainstream" Unix) I'm quite happy to dive in and add code to the source tree, if that would contribute any useful information. So can anyone suggest any way forward to resolve this please? It would appear that something is incorrectly being decoded somewhere, so it's probably to everyone's advantage to get this sorted out - I know it would certainly be to mine :-) Many thanks, and regards, Tris Mabbs. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba