[Samba] Multiple DC and idmap.ldb sync problem

[Rowland Penny]

See inline comments:

On Fri, 7 Mar 2025 12:17:27 +0100
Piotr Adamcio via samba <samba at lists.samba.org> wrote:

> I have 4 DCs with sysvol replication, but one central database for 
> users, computers, etc. 

What does that mean ? Every DC holds the same users, group, computers
etc.

> On every server, there is an |idmap.ldb|
> file which stores user & group IDs in 'xidNumber' attributes.
> Locally, |idmap| stores attributes with autoincrementation, and I
> understand this. And on every DC, I have to guarantee that each DC
> will use the same ID for a given user or group; that's why I have to
> copy |idmap.ldb|.

Why do you have to guarantee the same IDS, this is only really required
for the small number of users/groups (which are usually part of the
'Well Known SIDs') that 'own' things in sysvol.

> 
> I have such a problem that even when I copy (first backup, second
> copy to another DC, and third rename to the original name), linux
> doesn't use this attrib from Samba unless I restart the Samba
> service, or even in some cases, restart the whole Debian system.

Running 'net cache flush' followed by 'samba-tool ntacl sysvolreset' is
usually all that is required.

> thats why i have problem with file permission

What problems with file permissions ?

> 
> In the documentation, I found that Unix attributes about a user can
> be stored in AD - not in a file. In this case, attributes can be
> synced via the catalog replication mechanism, and all attributes will
> sync on every DC.

Big problem with that on a DC, any uidNumber or gidNumber attributes in
AD will replace the xidNumber attributes from idmap.ldb, provided
'idmap_ldb:use rfc2307  = yes' is set in the DCs smb.conf file. The
main problem is the Domain Admins group, if you give that group a
gidNumber, it becomes a Unix group and cannot own files and directories
in sysvol and it needs to.

> 
> Idmap config ad (https://wiki.samba.org/index.php/Idmap_config_ad).
> The main problem is about the disadvantages: I have to manually track
> ID values to avoid duplicates, and the values for the RFC2307
> attributes are not created automatically; they must be added manually.

You do not have to use rfc2307 attributes.
1) You shouldn't use a DC as a fileserver, even Microsoft says this.
2) If you use the 'rid' or 'autorid' backends on Unix domain members,
you will always get the same Unix IDs, because they are calculated from
the RID.
3) Samba will 'map' AD users to the UNIX ID on DCs and Unix domain
members, Windows will just use the SID.

> 
> The most important thing is the master DC, and maybe there is any 
> workaround to put the information which is stored in |idmap.ldb| into 
> the AD database. In the next step, the whole AD database will
> replicate using built-in mechanisms.
> 
> I wonder why Samba developers omitted autoincrement in AD Unix 
> attributes, and why we can't put RFC2307 attribute values into the 
> database, maybe defined in |smb.conf| or something like that.

You can add the rfc2307 attributes to AD, but one of the main reasons
it isn't done by default is that there is no aggreement on just where
to start the Domain Unix IDs from or what range to use, it isn't helped
by the fact that it was commonplace to just use the RID on the old
NT4-style domains that have been upgraded to AD.

> 
> Maybe someone has a workaround for this case  that avoids copying the 
> idmap.ldb files.

It is a bit more involved than that. ;-)

Rowland