[Samba] Settings ACLS from Windows via member server

Gaiseric Vandal gaiseric.vandal at gmail.com
Thu Feb 24 14:51:32 MST 2011


Once upon a time I had only samba 3.0.x servers.   They were in a samba
domain (with a samba PDC) and had a trust relationship with a windows 2003
AD domain.     I had to use Winbind + idmap + nsswitch.conf so that users
from the trusted Windows AD domain could be allocated unix uid's and gid's.
I also used winbind so that member samba servers in the samba domain could
allocate unix uid's and gid's to the users from the samba PDC.  Within the
samba domain I found it simplest to move all the servers to an LDAP backend
for samba and unix accounts so that I could enforce a consistent UID-to-SID
mapping across all domain members.  As other users have noticed, it ended up
being simpler to promote key member servers to BDC's and remove any need for
winbind/idmap with in the samba domain.


However, I still (to the best of my knowledge) needed winbind and idmap to
allocate unix uid's and gid's to the domain.  In the smb.conf of the PDC  I
had  the following:
 
idmap config TRUSTEDDOMAIN:backend = ldap
idmap config TRUSTEDDOMAIN:readonly = no
idmap config TRUSTEDDOMAIN:default=no
idmap config TRUSTEDDOMAIN:ldap_base_dn =
ou=trusteddomain,ou=idmap,o=mydomain.com
idmap config TRUSTEDDOMAIN:ldap_user_dn = cn=Admin
idmap config TRUSTEDDOMAIN:ldap_url = ldap://ldap1.mydomain.com
idmap config TRUSTEDDOMAIN:range = 30000-39999

BDC's are similarily configured, except for the following line:

idmap config TRUSTEDDOMAIN:readonly=yes

With samba 3.0.x, idmap allocation worked somewhat-  id's were allocated but
would fail after the cache period expired.   With samba 3.4, idmap cache
issue was fixed but idmap did not allocate new uid's or gid's .


Based on your information, having upgrade to Samba 3.4,  I could have used
idmap_ad as the backend for the trusted Windows domain.    Although I
believe I still need winbind and nsswitch.conf so that the Unix system can
use the uid's and gid's allocated to the trusted users?

Have I understood correctly?

PS.  I truly appreciate all the effort that the samba community puts into
samba.  And yes, I know it is free.    However, man pages our good for
resolving specific implementation issues but they are not always ideal for
putting together a big picture of how all the parts are supposed to go
together.    Updated Samba HowTo would really be appreciated.  To be fair,
MS Server-  even with all its documentation-  also has some serious gaps in
documentation and users often have to resort to user forum support as well.


Thanks.








-----Original Message-----
From: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org]
On Behalf Of John H Terpstra
Sent: Tuesday, February 22, 2011 4:28 PM
To: samba at lists.samba.org
Subject: Re: [Samba] Settings ACLS from Windows via member server

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.
> 
> John

John,

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
includes:
	man winbindd
	man idmap_nss
	man idmap_ad
	man idmap_hash
	man idmap_rid
	man idmap_adex

The man page for winbindd for samba-3.5.4 says:

<quote>
"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."
<unquote>


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:
	libnss_files.so
	libnss_compat.so
	libnss_ldap.so
	libnss_hesoid.so
	libnss_winbind.so


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
and accounts.

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.

Cheers,
John T.
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba



More information about the samba mailing list