samba - Mar 2014 - AD+DFS+Samba flakiness

We have a situation at a couple of completely unrelated locations, where
there is an Active Directory server (Windows 2008R2) hosting a DFS tree, but
the back end is a collection of Samba servers hosting the files (Samba 3.6.3
on Ubuntu 12.04).

Every now and then users will get 'access denied' messages when trying
to
browse shares under the DFS tree.

If they go directly to the share on the Samba server, they generally can get
their files just fine.

One location has occasional issues with winbind on the Samba servers
'hanging' while trying to query the AD server, but I think this is
unrelated. (Subject for another post).

I'd like some confirmation from people who understand the workings of the
authentication systems involved, whether this occasional DFS flakiness is
*certainly* a problem with the Windows server, or if there's any way in
which the Samba servers might be related to the problem.


When a client querys a MS DFS tree, does the Windows server do any sort of
authentication checking to see if that user is allowed to access a given DFS
share; and if so, does the DFS server query the AD server, or does it query
the backend server actually serving up that share?


Could there be a problem with a trust relationship between the DFS or AD
server and the Samba server, which would give the DFS server a false belief
that the user is denied access?



-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com

On 03/05 10:27 , Carl Wilhelm Soderstrom wrote:
> We have a situation at a couple of completely unrelated locations, where
> there is an Active Directory server (Windows 2008R2) hosting a DFS tree,
but
> the back end is a collection of Samba servers hosting the files (Samba
3.6.3
> on Ubuntu 12.04).
> 
> Every now and then users will get 'access denied' messages when
trying to
> browse shares under the DFS tree.
> 
> If they go directly to the share on the Samba server, they generally can
get
> their files just fine.
After much examination of one case today, I'm not much closer to figuring
out what's going on. However, I *did* see errors like this in the logs on
the Samba server when trying to access a share under the DFS tree:

[2014/03/05 14:19:40.127577,  2]
smbd/service.c:627(create_connection_session_info)
  user 'DOMAIN+username' (from session setup) not permitted to access
this
share (Sharename)

If I went to the share directly on the Samba server, I could get in without
any problems.

If I used Smbclient from another Linux box, I could get into
\\sambaserver\sharename without any problems.

If I used Smbclient from another Linux box, I could get into
\\ADserver\DFS\sharename without any problems. (This being the path through
the Windows server to the Samba share listed above).

I killed the smbd process by which the user was logged into the samba
server, and thereafter the user was able to connect again successfully.

So I'm wondering if somehow some bad credentials were cached when the user
first authenticated. It only happens *sometimes* tho. Often enough to be
annoying (and make management want to go all-Microsoft), but infrequent
enough that it's exceedingly difficult to build a test case.


Does anyone have any advice on how to troubleshoot this further?

Random suggestions for things to look at next?

The problem is that even at log level 3, the logs get really huge really
fast, and I dread trying to turn up the logs to level 10, capture the
relevant data from all the appropriate logfiles for a successful logon,
wait around for an error to crop up, and hope the user tells me in time that
I can go look at it before it goes away.

I'll probably have to do that anyway.

-- 
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com