Re: [Samba] winbind causing huge timeouts/delays since 4.8
- Date: Mon, 25 Feb 2019 11:19:33 +0100
- From: Viktor Trojanovic via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] winbind causing huge timeouts/delays since 4.8
On 25.02.2019 10:20, Rowland Penny via samba wrote:
Can you just help me understand the relationship between these
xidNumbers and the SID, if there is any?
On Mon, 25 Feb 2019 09:24:24 +0100
Viktor Trojanovic via samba <samba@xxxxxxxxxxxxxxx> wrote:
I'm confused.. how is the choice of the idmap backend related to an
AD DC use case?
Only in the case of wanting the same ID everywhere.
In my understanding, the idmap backend only needs to be specified in
the smb.conf for member servers. That's why I still don't see how it
is related to a AD DC use case. I take it I'm missing something
A Samba AD DC uses idmap.ldb by default, this means that you get
xidNumbers in the '3000000' range, but if you use the 'ad' backend on
Unix domain members, these xidNumbers get overridden by the uidNumber's
and gidNumber's set in AD. It also turns some groups from being both
users and groups into just groups.
Assuming just DCs and I create a new user (using ADUC), I understand
this user will receive a xidNumber (I take it xid stands for both uid
and gid?) that will automatically be set by the DC and is in the 3000000
range. Where is this xidNumber stored, though? If it was stored in the
AD, I assume member servers could just query it directly, right? But
that doesn't seem to be the case since we still need to set these
xidNumbers manually when using the ad back end, and when using the rid
backend not the xidNumber but the rid is used to calculate the ID. Then
what is the purpose of the xidNumber set by the DC? Honestly, I'm a bit
If your users never log into a Unix domain member or store files on
one, then do not even need to consider a winbind backend.
In a Windows clients only environment, I thought that having AD
member servers implied that files were stored on them.
But I take it from what you write that as soon as some kind of access
is needed, we are actually speaking about a "login", even if it's
just on the share level and the user never sees a shell.
In which case, yet again, the question comes up which back end to
use. I'll get to that further below.
Then I will answer it below ;-)
I assume that most readers of the wiki will, like me, find that
"central administration of ID's inside the AD" and "ID's not stored
in a local database that can corrupt with lost file ownership" seem
like really important arguments (btw, the last point is not stated
as a disadvantage for the rid/autorid backend in the wiki). Reading
this, it just seems that the ad backend is always the right one
except that it's a headache to manage.
It isn't really a headache to manage, once you get your head around
For very large environments, I guess you would just script it either
with samba-tool or powershell. But having to do it manually and
remember that for every user, computer, and group 1-2 attributes need
to be set, and kept track of, does seem like a nuisance.
Ah, that type of headache, what do I need to ad and what was the last
uidNumber I used.
Well.. yes. What other headaches are there with the ad backend? :-)
To put it differently, if Samba was improved in such a way that we
could use the ad backend without having to manually manage the
rfc2307 attributes, wouldn't this be the best if not only solution
I think you are mistaking using a subset of the RFC2307 attributes
with using most of them. If you use any backend other than
'ad' (and I include a DC here) all you get is a uidNumber for a
user, or a gidNumber for a group. Using the 'ad' backend gets an ID
number that you set, plus individual login shells, Unix home dirs
I guess I was. Are you saying, then, that if I have no need for
individual login shells and *nix home dirs (which in a pure Windows
client environment I clearly have not), the ad back end isn't really
offering any advantage for me?
If your users do not need to actually log into a Unix machine, then
there is no need to set a login shell, they will get the default
'bin/false'. If your users do not store anything in a Unix homedir
(only really needed if they log in) then you don't need to set the
template homedir, though there is the default /home/DOMAIN/user.
What still confuses me here is how the wiki states that in case of
rid/autorid information about file ownership is lost if the local tdb
fails and cannot be restored.
Where does it say that ?
It's implied here: https://wiki.samba.org/index.php/Idmap_config_ad
Advantages: "IDs are not stored in a local database that can corrupt and
thus file ownerships are not lost.*"*
Either I'm misunderstanding this, or this statement is really giving the
I assume this does not mean that the
actual ownership information is stored in tdb (or in the AD, for that
matter) but that the user ID used in the ACL needs to be retrieved
from somewhere, and in case of the ad back end this ID is being
retrieved from the AD directly, in case of the rid back end it's
retrieved from the local store only. And yet you said that on member
servers with identical smb.conf files (I assume you were talking
about the global section only), IDs would always be the same.
The 'DOMAIN' ID's on Unix domain members are always stored in AD, just
not always in a way you expect ;-)
For the 'ad' backend, the uidNumber & gidNumber attributes are used,
most others calculate the ID from the 'RID'. This means that if
something goes wrong and AD is okay, recreating the Unix domain member
should be enough. If the '*' tdb gets corrupt, you can delete it and it
will get recreated and whilst I cannot totally guarantee the ID's will
be the same, it doesn't really matter because the users and groups in
there are from the Well Known SIDs and are not used by the normal
Let me see if I understand this correctly. No matter if the ad or the
rid backend is used, the member server queries the AD to check which ID
belongs to which user and sets ACL accordingly. In the case of ad, the
uidNumber is used, in case of rid the ID is calculated in a transparent
way. I assume this means that each time someone access a member server
(for example to access a file), the member server will query the DC to
verify this user's ID. What happens if the DC cannot be reached, will a
local cache be used or will the request remain pending until a DC answers?
Naturally, two questions come up:
1) If one member server fails, wouldn't it be possible and sufficient
to just regenerate the tdb using the same smb.conf? If this yields
the same results every time, then why would I even worry about a
Yes and, on a Unix domain member, you don't have to worry
Why did you mention the *nix domain member specifically? In which other
cases would I have to worry?
Questions over questions... thanks for bearing with me! :-)
To unsubscribe from this list go to the following URL and read the