samba - Mar 2012 - Connected client unaffected by group/user/share change

I am trying to solve what I perceive as undesirable behavior of my Samba server.
Please understand I am not claiming this is a bug in Samba. It is simply
different from the behavior I want, and I'm asking for help in modifying the
behavior.

My Samba server is version 3.5.4 (release 68.el6) and runs under CentOS 6.0
(x86_64). I happen to use Active Directory (AD) to authenticate, but am not
convinced this behavior is specific to AD.

What follows is a generalized statement of the undesirable behavior, with the
context provided first as a sequence of events:

1) A CIFS client establishes (and maintains) a connection to a CIFS share on our
Samba server. Everything is normal so far.
2) After that connection has been established, a configuration change is made
(examples provided as bullets below) which I think should immediately revoke the
CIFS client's access to the connected CIFS share. For example:

? ? o Active Directory user is deleted from the domain (via the Active Directory
Administrative Center on the domain controller).
? ? o The Active Directory user is removed from the CIFS share's list of
permitted users (on the Samba server host).
? ? o The CIFS share is deleted (on the Samba server host).

Here?s the undesirable behavior. As long as the CIFS client maintains the
existing connection to the CIFS share, access to that share is not revoked. That
is, the user continues to have the same access to the share as they did when the
connection was first established.

The desired behavior is for access to be revoked as soon as the configuration
change pertinent to access rights is finalized. Disconnecting the affected
client session(s) is acceptable and appropriate, but disconnecting other
sessions (unaffected by the configuration change) is undesirable.

I would like to get your ideas toward an approach, programmatic or otherwise,
that will yield the desired behavior. Perhaps this is as simple as changing my
Samba server?s configuration; I have not found any configuration parameters that
appear relevant to this behavior.

Thanks for reading.

Sincerely,
Steve Tice

On Fri, Mar 30, 2012 at 4:14 PM, Steve Tice <stic6021 at yahoo.com>
wrote:
> Here?s the undesirable behavior. As long as the CIFS client maintains the
existing connection to the CIFS share, access to that share is not revoked. That
is, the user continues to have the same access to the share as they did when the
connection was first established.
>
> The desired behavior is for access to be revoked as soon as the
configuration change pertinent to access rights is finalized. Disconnecting the
affected client session(s) is acceptable and appropriate, but disconnecting
other sessions (unaffected by the configuration change) is undesirable.
>
the quick and dirty hack is to use smbstatus to get the clients PID
and kill it.  this is also useful when changing share options as the
clients will automatically reconnect, but not all applications will
handle losing their open file handles cleanly, so use with caution
here.

On Fri, Mar 30, 2012 at 5:25 PM, Chris Weisswrote:
>?the quick and dirty hack is to use smbstatus to get the clients PID and
kill it.
Yes, that's the sort of active revokation I'm looking for. Thanks for
the suggestion. More difficult is the art of detecting that a connection should
be torn down (because the connected user should no longer have access). For each
existing connection, perhaps I'd need to see if a new connection with all
the same parameters can currently be established. In a perfect world, I could
test authorization and validity of the new connection without requiring the
user's password. In other words, it would be helpful to test authorization
without first having to authenticate. Is such a test possible?