[Samba] Settings ACLS from Windows via member server
John H Terpstra
jht at samba.org
Tue Feb 22 14:27:30 MST 2011
On 02/23/2011 07:26 AM, John Drescher wrote:
>> While subscribers keep explaining what they believe, and keep giving
>> advice based on their belief system, rather than on well reasoned fact,
>> confusion will continue to exist and complaints regarding Samba
>> documentation will continue also.
>> Are you willing to take a brave step to explain your reasoning?
> This was acquired by several weeks of testing on some version of samba
> with test PDC/BDC and a few windows clients. I am not sure of the
> exact version. It was probably 3.0.X. The clients were mostly 32 bit
> windows XP with a few 64 bit XP machines. Outside of this test domain
> we have used samba for around 10 years and we are still using the
> original domain which has grown from a single samba PDC to a PDC with
> several BDCs, multiple LDAP servers and at least 1/2 dozen domain
> member servers since the PDC and BDCs do not act as fileservers. I do
> not have the test setup to try again with more recent samba but I
> guess I could easily create servers under Virtual Machines.
The role of winbindd has morphed considerably since the time the HOWTO
document was written. The most recent version of Samba covered by the
HOWTO is 3.0.20. The HOWTO has languished since that time.
Winbind has been significantly rewritten in 3.2.x, and gain in 3.3.x,
and in 3.4.x. It is no surprise that there is confusion regarding its
role, when it is needed, and how to configure it.
The best place to start (always) is the man pages that ship with the
version of Samba you are using. The man pages that should be consulted
The man page for winbindd for samba-3.5.4 says:
"winbindd is a daemon that provides a number of services to the Name
service Switch capability found in most modern C libraries, to arbitrary
applications via PAM and ntlm_auth and to Samba itself.
Even if winbind is not used for nsswitch, it still provides a service to
smbd, ntlm_auth and the pam_winbind.so PAM module, by managing
connections to domain controllers. In this configuraiton the idmap uid
and idmap gid parameters are not required. (This is known as `netlogon
proxy only mode´.)
The Name Service Switch allows user and system information to be
obtained from different databases services such as NIS or DNS. The exact
behaviour can be configured through the /etc/nsswitch.conf file. Users
and groups are allocated as they are resolved to a range of user and
group ids specified by the administrator of the Samba system.
The service provided by winbindd is called `winbind´ and can be used to
resolve user and group information from a Windows NT server. The service
can also provide authentication services via an associated PAM module.
The pam_winbind module supports the auth, account and password
module-types. It should be noted that the account module simply performs
a getpwnam() to verify that the system can obtain a uid for the user, as
the domain controller has already performed access control. If the
libnss_winbind library has been correctly installed, or an alternate
source of names configured, this should always succeed."
The components that make up the winbindd services includes:
winbindd - the daemon that itself
pam_winbind.so - the PAM library module
libnss_winbind.so - the NSS library module
idmap_xxx.so - Samba modules
The Samba modules provide identity mapping/resolution capabilities - see
the man pages for details. The idmap_ad, idmap_adex, idmap_has, and
idmap_rid modules make use of winbindd. The idmap_nss module can be
used with, or without winbind.
Samba CAN be used without winbind - that is a fact. Samba's smbd makes
calls to the getpwent() group of system calls whenever it needs to
obtain the uid/gid for a user of a group. Where NSS has been configured
to resolve user and group information via LDAP, a system call to
getpwent() will search the libnss libraries in the order they are
specified in the nsswitch.conf file. For example: Consider where
nsswitch.conf is configured with the following:
passwd: files compat ldap hesoid winbind
A call to getpwnam() will invoke the libraries specified in the order
given until a match is found. These libraries are used in the order
(from left to right) specified in the nsswitch.conf file:
Winbindd is necessary when Samba is a domain member server in a Windows
domain environment where the domain controllers are running MS Windows
(NT later) so that it can obtain user and group credentials from the
Microsoft domain controllers. In this role, Samba will need to resolve
the Windows user and group SID to a uid/gid tuple. This is handled
through a combination of winbindd and the idmap_xxx utility chosen.
All accounts that resolved via NSS are considered local to the machine
unless specific provision has been made to configure IDMAP to do
otherwise. BUILTIN accounts are handled by winbindd - so if winbindd is
not running, these accounts will not exist on the Samba server. Please
refer to the Microsoft knowledgebase for the role of the well-known SIDs
Now consider the following case: Under MS Windows a user from a foreign
domain (eg: georgeb\DOMAINB) tries to access a Windows 2008 server that
is a member of DOMAINA. There is an account called georgeb\DOMAINA with
the same password as georgeb\DOIMAINB, but they are different users and
should NOT be permitted to see each others files. Under MS Windows this
is not a problem. Where winbindd is not used both users will resolve to
the local georgeb account via NSS - therefore georgeb\DOMAINA and
georgeb\DOMAINB can access each other's files. When winbindd is used
together with an appropriate idmap_xxx (eg:idmap_rid) and the idmap
config options are correctly set, georgeb\DOMAINA and georgeb\DOMAINB
will each have different uid/gid tuples and therefore will not be able
to access each other's files.
I recognise that the above is complex until the role of NSS and Samba's
IDMAP facility are understood. Unfortunately, there is too much
folk-lore surrounding the use of winbindd - what we need is for list
subscribers to help each other with greater reference to current man
pages and with reference to the Samba source code.
I hope the above is accurate and helpful and I welcome corrections that
are based on fact, not speculation as so often happens.
More information about the samba