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

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

Thank you very much for taking the time to explain this so clearly with the
example, it really helps me understand why the mappings diverged between
the old DC, the new DC, and the member server.

I?m fully aware that using a DC as a file server is a bad practice.
Unfortunately, this setup wasn?t my choice, I inherited it, and now I?m
trying to clean it up and move things closer to best practices.

The real challenge for me is that I have around 200 users with their
roaming profiles in /home, in addition to all the shares (~40). This makes
the migration even trickier.

I really appreciate the suggestions you?ve given me so far, they are
pointing me in the right direction and helping me think about the best path
forward.