I see. Thanks for clarification. Checking the detailed of using debuglevel 10 I see this message: ../../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5583: Resolving conflict record via existing-record rename 'CN=Vikas Rajan,CN=Users,DC=SUB,DC=DOM,DC=TLDbg' -> 'CN=Vikas Rajan\0ACNF:de5b7fa1-e3ec-4631-a8d7-cdfc137ac3b7,CN=Users,DC=SUB,DC=DOM,DC=TLD' Although it was renamed and re-replicated: ../../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5605: With conflicting record renamed, re-apply replicated creation of 'CN=Vikas Rajan,CN=Users,DC=SUB,DC=DOM,DC=TLD' The whole transaction seems to fail. Maybe because it is still using the old dn instead of the renamed one. I renamed the dn manually using ldbrename and after that the join succeeds. br ________________________________________ From: samba <samba-bounces at lists.samba.org> on behalf of Rowland Penny via samba <samba at lists.samba.org> Sent: Monday, December 16, 2024 3:30 PM To: samba at lists.samba.org Cc: Rowland Penny Subject: Re: [Samba] Error when joining new DC On Mon, 16 Dec 2024 13:01:53 +0000 Peter Mittermayer via samba <samba at lists.samba.org> wrote:> While resuming my testing for adding a new DC with higher Samba > version I have some questions: > > 1. do I have to expunge tombstones on each DC or just one (and > replication will remove it from others). - I think it should be run > on all DCs. > > 2. same question for dbcheck >All DCs should hold the same database (apart from a few non replicated attributes), so making changes on one DC should lead to those changes being replicated to all other DCs. So, doing a change on one DC, should lead to changes on all others.> 3. Rowland mentioned that the error message I get when trying the DC > is just a result of the real issue. In which section of the join > procedure would I have to look for the real issue if it is really > related to the newly introduced security constraints in 4.14.10? > Running with debuglevel 10 provides a lot of details and I'm not sure > where exactly to look for any additional hints or how they might look > like. >In your initial post, you posted the output from the join command, the relevant parts were these: Your error started here: An operation failed during a batch mode transaction, the transaction was rolled back DSDB Transaction [commit] at [Thu, 05 Dec 2024 19:29:47.054187 EET] duration [24679161] status [1] reason [end_trans error on DC=SUB,DC=DOM,DC=TLD: An operation failed during a batch mode transaction, the transaction was rolled back] {"timestamp": "2024-12-05T19:29:47.054240+0200", "type": "dsdbTransaction", "dsdbTransaction": {"version": {"major": 1, "minor": 0}, "action": "commit", "transactionId": "6c245342-5ecc-4c4e-8e13-1196825d7116", "duration": 24679161, "statusCode": 1, "status": "Operations error", "reason": "end_trans error on DC=SUB,DC=DOM,DC=TLD: An operation failed during a batch mode transaction, the transaction was rolled back"}} Join failed - cleaning up The next few lines were these: ldb_wrap open of secrets.ldb dsdb_search: SUB SEARCH_ONE_ONLY flags=0x00000200 cn=Primary Domains (&(flatname=SUB)(objectclass=primaryDomain)) -> 0 results Could not find machine account in secrets database: Failed to fetch machine account password for SUB from both secrets.ldb (Could not find entry to match filter: '(&(flatname=SUB)(objectclass=primaryDomain))' base: 'cn=Primary Domains': No such object: dsdb_search at ../../source4/dsdb/common/util.c:5731) and from /usr/local/samba/private/secrets.tdb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO You can ignore those, the file that cannot be found isn't created until the join is successful, that is why it cannot be found. Your actual error is a bit lower down: ERROR(ldb): uncaught exception - end_trans error on DC=SUB,DC=DOM,DC=TLD: An operation failed during a batch mode transaction, the transaction was rolled back File "/usr/local/samba/lib64/python3.9/site-packages/samba/netcmd/__init__.py", line 353, in _run return self.run(*args, **kwargs) File "/usr/local/samba/lib64/python3.9/site-packages/samba/netcmd/domain/join.py", line 128, in run join_DC(logger=logger, server=server, creds=creds, lp=lp, domain=domain, File "/usr/local/samba/lib64/python3.9/site-packages/samba/join.py", line 1621, in join_DC ctx.do_join() File "/usr/local/samba/lib64/python3.9/site-packages/samba/join.py", line 1511, in do_join ctx.join_replicate() File "/usr/local/samba/lib64/python3.9/site-packages/samba/join.py", line 1101, in join_replicate ctx.local_samdb.transaction_commit() Rowland -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Now I just need to find a solution how to allow dyndns updates only for the DCs and not the clients. Reason for this is that all our servers have multiple interfaces. Although they are connecting to AD mostly via default route we have seen issues where some register with wrong interface thus creating incorrect DNS records.All the DNS records A & PTR are usually created automatically during server provisioning and we don't use dhcp. So there is absolutely no need for dyndns except for changes in the AD infrastructure (i.e. joining/removing a DC). Any suggestions? br ________________________________________ From: samba <samba-bounces at lists.samba.org> on behalf of Peter Mittermayer via samba <samba at lists.samba.org> Sent: Monday, December 16, 2024 4:52 PM To: samba at lists.samba.org Subject: Re: [Samba] Error when joining new DC I see. Thanks for clarification. Checking the detailed of using debuglevel 10 I see this message: ../../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5583: Resolving conflict record via existing-record rename 'CN=Vikas Rajan,CN=Users,DC=SUB,DC=DOM,DC=TLDbg' -> 'CN=Vikas Rajan\0ACNF:de5b7fa1-e3ec-4631-a8d7-cdfc137ac3b7,CN=Users,DC=SUB,DC=DOM,DC=TLD' Although it was renamed and re-replicated: ../../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5605: With conflicting record renamed, re-apply replicated creation of 'CN=Vikas Rajan,CN=Users,DC=SUB,DC=DOM,DC=TLD' The whole transaction seems to fail. Maybe because it is still using the old dn instead of the renamed one. I renamed the dn manually using ldbrename and after that the join succeeds. br ________________________________________ From: samba <samba-bounces at lists.samba.org> on behalf of Rowland Penny via samba <samba at lists.samba.org> Sent: Monday, December 16, 2024 3:30 PM To: samba at lists.samba.org Cc: Rowland Penny Subject: Re: [Samba] Error when joining new DC On Mon, 16 Dec 2024 13:01:53 +0000 Peter Mittermayer via samba <samba at lists.samba.org> wrote:> While resuming my testing for adding a new DC with higher Samba > version I have some questions: > > 1. do I have to expunge tombstones on each DC or just one (and > replication will remove it from others). - I think it should be run > on all DCs. > > 2. same question for dbcheck >All DCs should hold the same database (apart from a few non replicated attributes), so making changes on one DC should lead to those changes being replicated to all other DCs. So, doing a change on one DC, should lead to changes on all others.> 3. Rowland mentioned that the error message I get when trying the DC > is just a result of the real issue. In which section of the join > procedure would I have to look for the real issue if it is really > related to the newly introduced security constraints in 4.14.10? > Running with debuglevel 10 provides a lot of details and I'm not sure > where exactly to look for any additional hints or how they might look > like. >In your initial post, you posted the output from the join command, the relevant parts were these: Your error started here: An operation failed during a batch mode transaction, the transaction was rolled back DSDB Transaction [commit] at [Thu, 05 Dec 2024 19:29:47.054187 EET] duration [24679161] status [1] reason [end_trans error on DC=SUB,DC=DOM,DC=TLD: An operation failed during a batch mode transaction, the transaction was rolled back] {"timestamp": "2024-12-05T19:29:47.054240+0200", "type": "dsdbTransaction", "dsdbTransaction": {"version": {"major": 1, "minor": 0}, "action": "commit", "transactionId": "6c245342-5ecc-4c4e-8e13-1196825d7116", "duration": 24679161, "statusCode": 1, "status": "Operations error", "reason": "end_trans error on DC=SUB,DC=DOM,DC=TLD: An operation failed during a batch mode transaction, the transaction was rolled back"}} Join failed - cleaning up The next few lines were these: ldb_wrap open of secrets.ldb dsdb_search: SUB SEARCH_ONE_ONLY flags=0x00000200 cn=Primary Domains (&(flatname=SUB)(objectclass=primaryDomain)) -> 0 results Could not find machine account in secrets database: Failed to fetch machine account password for SUB from both secrets.ldb (Could not find entry to match filter: '(&(flatname=SUB)(objectclass=primaryDomain))' base: 'cn=Primary Domains': No such object: dsdb_search at ../../source4/dsdb/common/util.c:5731) and from /usr/local/samba/private/secrets.tdb: NT_STATUS_CANT_ACCESS_DOMAIN_INFO You can ignore those, the file that cannot be found isn't created until the join is successful, that is why it cannot be found. Your actual error is a bit lower down: ERROR(ldb): uncaught exception - end_trans error on DC=SUB,DC=DOM,DC=TLD: An operation failed during a batch mode transaction, the transaction was rolled back File "/usr/local/samba/lib64/python3.9/site-packages/samba/netcmd/__init__.py", line 353, in _run return self.run(*args, **kwargs) File "/usr/local/samba/lib64/python3.9/site-packages/samba/netcmd/domain/join.py", line 128, in run join_DC(logger=logger, server=server, creds=creds, lp=lp, domain=domain, File "/usr/local/samba/lib64/python3.9/site-packages/samba/join.py", line 1621, in join_DC ctx.do_join() File "/usr/local/samba/lib64/python3.9/site-packages/samba/join.py", line 1511, in do_join ctx.join_replicate() File "/usr/local/samba/lib64/python3.9/site-packages/samba/join.py", line 1101, in join_replicate ctx.local_samdb.transaction_commit() Rowland -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
On Mon, 16 Dec 2024 14:52:03 +0000 Peter Mittermayer via samba <samba at lists.samba.org> wrote:> I see. Thanks for clarification. > > Checking the detailed of using debuglevel 10 I see this message: > > ../../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5583: Resolving > conflict record via existing-record rename 'CN=Vikas > Rajan,CN=Users,DC=SUB,DC=DOM,DC=TLDbg' -> 'CN=Vikas > Rajan\0ACNF:de5b7fa1-e3ec-4631-a8d7-cdfc137ac3b7,CN=Users,DC=SUB,DC=DOM,DC=TLD'That is what is known as a 'collision', at some time, the record was created on one machine, it possibly was a bit slow in replicating, so it was also created on another machine just at the same time as the replication arrived and they collided. Or it was created on two different machines at the same time, either way you cannot have two identical records, so one became 'CN=Vikas Rajan\0ACNF:de5b7fa1-e3ec-4631-a8d7-cdfc137ac3b7,CN=Users,DC=SUB,DC=DOM,DC=TLD'> > Although it was renamed and re-replicated: > ../../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:5605: With > conflicting record renamed, re-apply replicated creation of 'CN=Vikas > Rajan,CN=Users,DC=SUB,DC=DOM,DC=TLD'Well yes, but that record probably already exists> > The whole transaction seems to fail. Maybe because it is still using > the old dn instead of the renamed one. > > I renamed the dn manually using ldbrename and after that the join > succeeds. >But what did you rename it to ? You might want to read this: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/rename-item-replication-collision Rowland