Gabin Gervais
2025-Sep-02 19:36 UTC
[Samba] 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 !
Luis Peromarta
2025-Sep-02 19:53 UTC
[Samba] SID→UID mapping issue between Samba DC and member server after decommissioning an old DC
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
Rowland Penny
2025-Sep-02 20:12 UTC
[Samba] SID→UID mapping issue between Samba DC and member server after decommissioning an old DC
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