Web lists-archives.com

Re: [Samba] winbind causing huge timeouts/delays since 4.8




On Mon, 25 Feb 2019 11:19:33 +0100
Viktor Trojanovic via samba <samba@xxxxxxxxxxxxxxx> wrote:

> 
> On 25.02.2019 10:20, Rowland Penny via samba wrote:
> > 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 crucial here.
> > 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.
> >
> Can you just help me understand the relationship between these 
> xidNumbers and the SID, if there is any?

I will try and there is a definite relationship between xidNumbers and
SID-RIDs

> 
> Assuming just DCs and I create a new user (using ADUC), I understand 
> this user will receive a xidNumber 

Yes

> (I take it xid stands for both uid and gid?)

No, I think it was chosen to differentiate them from uidNumber &
gidNumber attributes, they are similar but not the same. They also only
exist on DC's

> that will automatically be set by the DC and is in the 3000000 range.

They are set on a 'first come' basis.

> Where is this xidNumber stored, though?

They are stored in idmap.ldb, which on Debian based distros is usually
in /var/lib/samba/private/

> If it was stored in the AD, I assume member servers could just query
> it directly, right?

No, they are only used on DC's

> But that doesn't seem to be the case since we still need to set these
> xidNumbers manually when using the ad back end,

You cannot set xidNumbers manually, you set uidNumber and/or gidNumber
attributes.

> and when using the rid backend not the xidNumber but the rid is used
> to calculate the ID. 

This is correct on a Unix domain member.

>Then what is the purpose of the xidNumber set by the DC? Honestly, I'm
>a bit lost here...

Have you ever heard of 'Sysvol' ?

Windows has the interesting fact that groups can 'own' things, Unix
doesn't and domain groups need to 'own' things in 'Sysvol'.
To explain how this works, lets look at a fragment of idmap.ldb:

dn: CN=S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-500
cn: S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-500
objectClass: sidMap
objectSid: S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-500
type: ID_TYPE_UID
xidNumber: 0
distinguishedName: CN=S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-500

dn: CN=S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-512 
cn: S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-512 
objectClass: sidMap
objectSid: S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-512 
type: ID_TYPE_BOTH
xidNumber: 3000010
distinguishedName: CN=S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-512 

xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz replaces the domain SID
500 is the RID for Administrator
512 is the RID for Domain Admins

The first time a user or group contacts the DC, its SID-RID is mapped
to the next available xidNumber. there are a few exceptions to this,
Administrator being one of them, as you can see 'RID' 500
(Administrator) is mapped to the ID '0' (Unix root), it is also set to
be 'ID_TYPE_UID'.
Most others get the next xidNumber and 'ID_TYPE_BOTH', this means the
Unix OS identifies them by the xidNumber and thinks they are both a
user and a group. 

> > 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? :-)

'need to ad' should have been 'need to add', that is the major headache
if using the 'ad' backend, just remembering what options to add when
creating users and what values to use.

> >
> >> 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 wrong picture.

Fair comment, I think what was meant was, the user & group data is
stored in AD and is easily retrievable in case of local failure.
 
> 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?

Winbind caches ID's locally and refreshes the cache periodically and if
'winbind offline logon = yes' is set in a Unix domain members smb.conf,
they will allow login even if the DC cannot be contacted.

> Why did you mention the *nix domain member specifically? In which
> other cases would I have to worry?

As far as Samba and AD is concerned, there are only three posibilties,
DC's, Windows domain members and Unix domain members. Windows domain
members don't have 'tdb' files. If a DC goes down, you have bigger
worries. This just leaves Unix domain members and as long as you use
the same smb.conf as before you can easily recover from a Samba crash.

> 
> Questions over questions... thanks for bearing with me! :-)

Asking questions is the only way to get answers ;-)

Rowland
 


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