On Fri, Jun 4, 2010 at 4:16 AM, Fergal O'Connell
<[email protected]> wrote:
> The samba config is set to "server" and the password server is the local DC.
> This has been working for the past 4 years or so (and is unlikely to change 
> either)

  If you can't make changes that might help fix problems, then don't
expect the problems to be fixed.

> I'm having problems actually finding the source of this issue? Is this 
> actually a DC issue
> or a samba issue?

  Most likely it's an interaction between Samba, the XP client, and/or
the Windows DC.  Could be a configuration mismatch, where Samba's
configured one way, XP or the DC is configured another way, things
don't quite work.  Even if it's an apparent bug in Microsoft's SMB
implementation, good luck getting that fixed; a great deal of what
Samba does is "bug for bug compatibility" with Microsoft.

  Not knowing anything else, NT_STATUS_REQUEST_NOT_ACCEPTED suggests
the DC got the request from Samba but rejected it.  Since it works
most of the time, that's probably not an authentication issue, or a
severe configuration mismatch.  Sporadic problems suggest instead
something like contention, resource limits, or a software bug.

  Resource limits seem especially likely to me, since you're using
server authentication.  That means every SMB session has to result in
a full password change between Samba and the DC, rather than simply
doing passthrough authentication.  Under heavy load on Samba, from the
DC's point of view, that will appear very similar to a dictionary or
DoS attack.  Hence my suggestion to change to "security = ads".  That
will make your Samba box a full AD member.  It can then just check
Kerberos tickets from the client, drastically reducing Samba's load on
the DC.

  I can help you with that, if you're interested.

> From an AD or DC point of view how can investigate this further?

  I presume you've check all the Event Viewer logs on the DC for any
obvious errors.

  I'm not familiar with what diagnostic logging that might be
available on AD DCs, and I generally wouldn't start there anyway.
Presumably all your other AD members are working, so you'd get a ton
of noise from that.  So if I was trying to gather more information I
would turn up the logging level on the Samba box.  Samba has a huge
number of options for logging.  At the most verbose levels, it can
basically log hex dumps of every packet.  You'd still get a ton of log
volume, but at least it would be correlated with the errors you're
already seeing.  I also recommend having Samba log information to
different files on a per-client basis; this makes deciphering logs
much easier.  You can do this with something like:

        log file = /var/log/samba/host.%m.log

in your smb.conf file.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to