Samba 4 and winbind

[Michael Adam]

Hi Rowland,

On 2013-04-15 at 15:41 +0100, Rowland Penny wrote:
> On 15/04/13 11:59, Rowland Penny wrote:
> >Hi, does anybody know if there is a way to turn of the winbind
> >part of the samba daemon?
> >
> >Rowland
> >
> >
> OK, replying to myself, to turn off winbind add 'server services =
> -winbind'

Exactly.

> but this did not help with my problem of mounting cifs
> shares at login and then being able to actually write to them. This
> is using sssd pulling all users info from AD.

I guess I don't understand what your setup is.
Where and why are you using sssd?
As far as I understand it (might be wrong) you can run either samba or sssd
on a system.

> What it did do, is to start me thinking (yes I know, probably
> dangerous ;-) ) Samba 4 is supposed to be a clone of a windows
> server and work in the same way

No. Samba is not supposed to be a clone of Windows!
Samba is an implementation of the wire protocols of Windows AD
(and SMB) services on a POSIX platform.
So it is to behave like windows on the wire.
If you want to put it that way, Samba is a big translation
engine translating from windows to the Unix/Linux world.

> so why does the samba daemon have
> winbind built into it, windows servers aren't like that.

There is nothing prescribed about the implementation in the
above. It is written nowhere that samba may only have parts
that are there in a windows server. It even needs internal
parts like winbindd.

And it is the design of the samba daemon that all various tasks
are a part of the single daemon, the tasks that implement wire
aspects like kerberos, dns, rpc server, end point mapper and so on,
but also internal tasks like the winbind task. The only exception
to this rule is (currently) the smbd daemon for fileserving,
which replaces the builtin smb server in the "samba" binary in
the default installation, but even this might change in a future
release.

> As far as I know, you can add posix uidNumbers etc to the AD, but
> windows never uses them itself,

This is correct, but samba is not windows!
Samba has to translate to the unix world:
In order for a user of samba to be able to access files
via smb (and this is needed for netlogon and group policy
for example), samba needs to have assigned a unix id to
a the user and her groups.

Hence samba can't wait for the windows admin to be so generous
to give a user or a group a unix id. Samba has to assing unix ids
when a user or group is created.

Windows does not offer a mechanism to automatically fill the SFU
unix attributes. This is a compelling idea, but there are
non-trivial challenges associated with automatically assigning
SFU unix IDs. For instance there is no UnixID FSMO role, so Samba
would need to introduce something like this, thereby removing
interoperability with windows DCs. So it was decided for 4.0
to keep the old scheme of a high watermark algorithm for
allocating unix ids as the objects come by (as Alexander has
explained).

This is by the way in contrast to what you wrote in another mail
not different from Samba3's winbindd but it is s3-winbindd's default
mode of operation. s3-winbindd only has more modes to choose
for id-mapping like rid, autorid, and some more.

We are in fact thinking about changing the idmap mode,
i.e. adding another mode like SFU, but it is not done yet.
And if you have another source of id mapping, we might
think about making this turnable-off, but currently it
is not implemented, since automatic unix-id allocation
is needed for samba to be operational at all.

I hope these explanations make it clear that winbind is not
an annoying and superfluous component of samba but plays an
important role and can not be turned off just like that.

Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 206 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130415/cf485fc9/attachment.pgp>