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

Hello,

I have a Samba AD domain (samba.lan). The old DC was also acting as a file
server. I added a new DC (dc1), which correctly resolves users and groups,
and then decommissioned the old DC. I reused that old machine as a domain
member so it could continue serving files.

The problem is that the ACLs stored on the Samba shares no longer match. On
the new DC, the command wbinfo --sid-to-uid=S-1-5-21-xxx-1104 returns
3000021. However, on the member server, the very same command returns
1000000. As a result, the existing ACLs are no longer applied properly,
because the SID?UID/GID mapping differs.

Here?s what I have tried so far:

Configured the member server with idmap config SAMBA : backend = ad and
schema_mode = rfc2307.

Checked for the uidNumber and gidNumber attributes in AD. By default, these
attributes are not populated.

If I add them manually in AD, the DC can see them via ldbsearch, but the
member server doesn?t seem to actually use them.

My goal is for the member server to use exactly the same SID?UID/GID
mapping as the DC, in order to preserve the existing ACLs on the file
shares.

So my question is: What is the best approach to achieve this?

Do I need to systematically populate the uidNumber/gidNumber attributes for
all accounts (RFC2307), or is there a more ?native? way to reuse the
mapping that was already in place on the old DC?

Thanks a lot for your help !

This situation highlights one of the main reasons why using a domain controller
as a file server is generally discouraged. A domain controller maintains its own
ID mapping, which cannot be reliably aligned with the ID mappings used on member
servers.


The simplest and most reliable way to handle ID mapping on a member server is to
use the RID ID mapping backend, which ensures a consistent translation of SIDs
to UNIX IDs.


That said, if you need to migrate data, the best approach is to reset the
ownership and permissions of the files on the member server from a Windows
machine. This way, permissions are reapplied using domain SIDs rather than
conflicting UNIX IDs.


Please note that if you have many users and complex permission structures, the
process can become time-consuming and challenging to manage.

More info here

samba.bigbird.es


On 2 Sep 2025 at 20:37 +0100, Gabin Gervais via samba <samba at
lists.samba.org>, wrote:
> Hello,
>
> I have a Samba AD domain (samba.lan). The old DC was also acting as a file
> server. I added a new DC (dc1), which correctly resolves users and groups,
> and then decommissioned the old DC. I reused that old machine as a domain
> member so it could continue serving files.
>
> The problem is that the ACLs stored on the Samba shares no longer match. On
> the new DC, the command wbinfo --sid-to-uid=S-1-5-21-xxx-1104 returns
> 3000021. However, on the member server, the very same command returns
> 1000000. As a result, the existing ACLs are no longer applied properly,
> because the SID?UID/GID mapping differs.
>
> Here?s what I have tried so far:
>
> Configured the member server with idmap config SAMBA : backend = ad and
> schema_mode = rfc2307.
>
> Checked for the uidNumber and gidNumber attributes in AD. By default, these
> attributes are not populated.
>
> If I add them manually in AD, the DC can see them via ldbsearch, but the
> member server doesn?t seem to actually use them.
>
> My goal is for the member server to use exactly the same SID?UID/GID
> mapping as the DC, in order to preserve the existing ACLs on the file
> shares.
>
> So my question is: What is the best approach to achieve this?
>
> Do I need to systematically populate the uidNumber/gidNumber attributes for
> all accounts (RFC2307), or is there a more ?native? way to reuse the
> mapping that was already in place on the old DC?
>
> Thanks a lot for your help !
> --
> 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 21:36:34 +0200
Gabin Gervais via samba <samba at lists.samba.org> wrote:
> Hello,
> 
> I have a Samba AD domain (samba.lan). The old DC was also acting as a
> file server. I added a new DC (dc1), which correctly resolves users
> and groups, and then decommissioned the old DC. I reused that old
> machine as a domain member so it could continue serving files.
> 
> The problem is that the ACLs stored on the Samba shares no longer
> match. On the new DC, the command wbinfo
> --sid-to-uid=S-1-5-21-xxx-1104 returns 3000021.
That looks about right, it is returning an 'xidNumber' from idmap.ldb,
but not necessarily the same 'xidNumber' as on the original DC.

A Samba DC uses 'xidNumbers' in the '3000000' range, but each DC
allocates these when a user, group or computer first contacts the DC
and as you cannot be sure that this will happen in the same order on
every DC, you cannot be sure that a user or group will get the same
xidNumber on every DC. This is the reason why you should sync idmap.ldb
from the DC with FSMO roles (usually the first DC) to all other DCs.

NOTE 'xidNumber' is correct and should not be confused with uidNumber
and gidNumber attributes found in sam.ldb (AD).
 
> However, on the
> member server, the very same command returns 1000000.
Unix domain members use a different idmap config backend, which one is
up to you.
> As a result,
> the existing ACLs are no longer applied properly, because the
> SID?UID/GID mapping differs.
Yes, they would be different.
> 
> Here?s what I have tried so far:
> 
> Configured the member server with idmap config SAMBA : backend = ad
> and schema_mode = rfc2307.
> 
> Checked for the uidNumber and gidNumber attributes in AD. By default,
> these attributes are not populated.
Correct, there is nothing in Samba to allocate uidNumber or gidNumber
attributes, it does not happen automatically, it is up to you to
allocate these and keep track of them.
> 
> If I add them manually in AD, the DC can see them via ldbsearch, but
> the member server doesn?t seem to actually use them.
Then probably either your smb.conf is incorrect (please post the output
of 'testparm -s) or the Domain Users group does not have a gidNumber
attribute.
> 
> My goal is for the member server to use exactly the same SID?UID/GID
> mapping as the DC, in order to preserve the existing ACLs on the file
> shares.
Not sure if this will be possible if the users & groups on the new DC
have different IDs to the old DC.
 
> 
> So my question is: What is the best approach to achieve this?
> 
> Do I need to systematically populate the uidNumber/gidNumber
> attributes for all accounts (RFC2307), or is there a more ?native?
> way to reuse the mapping that was already in place on the old DC?
If you must have the same IDs everywhere, then you will have to add the
uidNumber & gidNumber attributes, but they will be different from the
original xidNumber attributes in the 3000000 range, unless you know
what ID each user, group etc. had.

It might just be easier to forget the rfc2307 attributes and use the
'rid' backend on the Unix domain member, this does not need anything
adding to AD.

Rowland