Using Local Groups with AD Domain Users for Samba Shares

[Marko Myllynen]

Hi,

in Samba 4 the "security = server" mode was removed making it a hard
requirement to use "security = ads" in AD environments to allow users to
access Samba shares with their AD username/password. While the server
mode had many problems [1] it allowed administrators to use local/NSS
groups to control access to shares while still allowing users to
authenticate with their AD username/password.

1)
http://git.samba.org/?p=samba.git;a=commitdiff;h=b4abd3faaf3bdcbcd24fed8325960ccdee43bea9

Already with Samba 3 there have been quite a few people asking on
different lists how to apply access restrictions to Samba shares by
using local groups instead of domain groups when using security = ads
(there are several reasons for this, one usual is that creating or
modifying domain groups usually comes with additional overhead compared
to creating or modifying local groups since on many occasions *nix
administrators are not AD administrators).

It would seem that there hasn't been a clear solution for this so I
wrote the attached script to be used as username map script in smb.conf
- it allows using both local and domain groups with domain users.

The downside is that because it seems impossible to determine at the
stage which the script is run which share the parent smbd process is
serving all the local groups must be iterated thus forcing creating
duplicate shares for cases where both domain and local group members
should be able to access a share (i.e., a share with valid users =
@local_group is ok as well as a share with valid_users =
@DOM\domain_group if no users part of a local group need access to that
share).

I wonder would it be possible to provide a method to find out which
share the smbd process is serving? That would remove the need for
duplicating shares with this approach.

Thanks,

-- 
Marko Myllynen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: smbusrmap
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20121019/2ae59eb3/attachment.ksh>