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

[Michael Wood]

Hi

You might try getting a packet capture.

By the way, what's common between the user before you deleted the
account and the one you created later, besides the username?  The
password?  Can you replicate this in a test environment?

If you can replicate this in a test environment and you know more or
less when the problem started, perhaps you could use git bisect to
find exactly when it happened.

e.g. roll back samba to a version from 3 months ago.  If it works
there, tell git bisect that that is the last good version you know of.
 Then tell it that your current version is bad and let it choose the
versions for you to compile and test.  You keep telling it that the
version you've just tested is either good or bad and it will
eventually tell you which commit broke it.

Then you can post that information to the list.  (I suspect
samba-technical would be a better list for this sort of thing.)

Also, I'm pretty sure Samba should never core dump, so you might want
to post stack traces etc. when that happens.

On 25 February 2013 13:51, Tris Mabbs <TM-Samba201302 at firstgrade.co.uk> wrote:
> 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



-- 
Michael Wood <esiotrot at gmail.com>