[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 TM-Samba201302 at Firstgrade.Co.UK
Mon Feb 25 04:51:34 MST 2013



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


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


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.

More information about the samba mailing list