samba - Sep 2025 - SID→UID mapping issue between Samba DC and member server after decommissioning an old DC

Thank you both for your detailed explanations ? this really helps me
understand what is happening under the hood with idmap.ldb, xidNumbers, and
why the mappings differ between a DC and a domain member.

In my case, the challenge is that I have more than 200 shares on this
server, all with existing ACLs. Re-applying permissions manually from
Windows would be extremely time-consuming and error-prone.

Could you please suggest what would be the fastest and most reliable way to
migrate this setup?

Should I invest the effort into fully populating uidNumber / gidNumber
attributes in AD (RFC2307), or

Would switching the member to the rid backend and then resetting ACLs from
Windows be more practical in the long run?

Any advice on a migration strategy that minimizes downtime and effort would
be greatly appreciated.

There?s no other option but to reset ACLs via windows. Unless you are sure you
need something else, just use RID.
On 2 Sep 2025 at 22:21 +0100, Gabin Gervais via samba <samba at
lists.samba.org>, wrote:
> Thank you both for your detailed explanations ? this really helps me
> understand what is happening under the hood with idmap.ldb, xidNumbers, and
> why the mappings differ between a DC and a domain member.
>
> In my case, the challenge is that I have more than 200 shares on this
> server, all with existing ACLs. Re-applying permissions manually from
> Windows would be extremely time-consuming and error-prone.
>
> Could you please suggest what would be the fastest and most reliable way to
> migrate this setup?
>
> Should I invest the effort into fully populating uidNumber / gidNumber
> attributes in AD (RFC2307), or
>
> Would switching the member to the rid backend and then resetting ACLs from
> Windows be more practical in the long run?
>
> Any advice on a migration strategy that minimizes downtime and effort would
> be greatly appreciated.
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba

On Tue, 2 Sep 2025 23:20:51 +0200
Gabin Gervais via samba <samba at lists.samba.org> wrote:
> Thank you both for your detailed explanations ? this really helps me
> understand what is happening under the hood with idmap.ldb,
> xidNumbers, and why the mappings differ between a DC and a domain
> member.
> 
> In my case, the challenge is that I have more than 200 shares on this
> server, all with existing ACLs. Re-applying permissions manually from
> Windows would be extremely time-consuming and error-prone.
> 
> Could you please suggest what would be the fastest and most reliable
> way to migrate this setup?
> 
> Should I invest the effort into fully populating uidNumber / gidNumber
> attributes in AD (RFC2307), or
> 
> Would switching the member to the rid backend and then resetting ACLs
> from Windows be more practical in the long run?
> 
> Any advice on a migration strategy that minimizes downtime and effort
> would be greatly appreciated.
Lets take some data from your original post, but tie it to fictitious
users 'fred' and 'wilma'. On your original DC, 'fred'
had the SID
S-1-5-21-xxx-1104 with the Unix ID 3000021, 'wilma' had the SID
S-1-5-21-xxx-1105 with the Unix ID 3000022, because that is the order
they were created and connected, 'fred' first, then 'wilma'.

You then created a new DC, where all the data in sam.ldb is replicated
from the original AD to the new DC, this means that 'fred' and
'wilma'
will keep their SIDs. However, unless you also synced idmap.ldb from
the original DC to the new one, you cannot be certain that the users
will get the same Unix ID. In this, ficticious, scenario, 'wilma'
connects to the new DC first and gets the ID 3000020 and then sometime
later, 'fred' connects and gets the ID 3000028, now do you see the
problem ?

To compound this, you then threw a Unix domain member into the mix,
which (unless you use the 'ad' idmap backend AND set the uidNumber &
gidNumber attributes to the relevant 'xidNumber') will always be
different from the original DC IDs.

Samba, like Windows, uses the SID to identify accounts, it just maps
the SID to a Unix ID so that the Unix client knows who the account is.
This is why Luis is suggesting you use Windows to reset ownership and
permissions. It is now probably the only way to reset them, though with
the very large number of shares you appear to have, it still isn't
going to be easy. Do you know who exactly owns what ?

I am sorry to say this, but you appear to have proven why it is a bad
idea to use a DC as a fileserver.

Rowland