In the mean time I figured out there was a problem with the NETBIOS domain names. I corrected the domain names.
Original:
ucr get kerberos/realm
INTRA.MM-NETWORK.HU

ucr get windows/domain
INTRA

ucr get ldap/base
dc=MM-Systems,dc=local


udm settings/sambadomain list

DN: sambaDomainName=INTRA,cn=samba,dc=MM-Systems,dc=local
  NextGroupRid: 1000
  NextRid: None
  NextUserRid: 1000
  SID: S-1-5-21-1431207662-3394139552-923829525
  badLockoutAttempts: None
  disconnectTime: None
  domainPasswordComplex: 1
  domainPasswordStoreCleartext: 0
  domainPwdProperties: 1
  lockoutDuration: None
  logonToChangePW: None
  maxPasswordAge: None
  minPasswordAge: None
  name: INTRA
  passwordHistory: 0
  passwordLength: 8
  refuseMachinePWChange: None
  resetCountMinutes: None



I changed using the following commands:
ucr set --force windows/domain="MM-SYSTEMS"

udm settings/sambadomain modify --dn sambaDomainName=INTRA,cn=samba,dc=MM-Systems,dc=local --set name=MM-SYSTEMS

When now I start the Active Directory Takeover, I get the following error:
After pressing Next:
A Windows Server 2003 Active Directory domain with the domainname MM-Systems.local has been found. The server hpsap.intra.mm-network.hu (10.99.98.11) will be used as Active Directory Domain Controller for the takeover.

The following accounts have been found in the Active Directory domain:

25 users
63 groups
30 computers
Click "Next" to start with the migration.

"An error occurred
Could not fulfill the request.

Server error message:

Internal module error: Takeover running, aborting attempt to restart"

How can I restart the Takeover process and cancel the original one?

Comment 2 Arvid Requate 2018-08-22 20:21:14 CEST

Thanks for the feedback, the state of the process is stored in the file

  /var/lib/samba/private/.adtakeover

and if you remove that file you may be able to restart the takeover, but I'm not sure about the current state of your system.

Comment 3 Johannes Keiser 2019-03-22 13:33:04 CET

Reported again: Version: 4.4-0 errata0 (Blumenthal)

(unmodified traceback: Ticket#2019031321000262)
Traceback (most recent call last):
  File "%PY2.7%/univention/management/console/modules/adtakeover/__init__.py", line 61, in _background
    result = func(self, request)
  File "%PY2.7%/univention/management/console/modules/adtakeover/__init__.py", line 110, in copy_domain_data
    takeover.join_to_domain_and_copy_domain_data(ip, username, password, self.progress)
  File "%PY2.7%/univention/management/console/modules/adtakeover/takeover.py", line 305, in join_to_domain_and_copy_domain_data
    takeover.post_join_tasks_and_start_samba_without_drsuapi()
  File "%PY2.7%/univention/management/console/modules/adtakeover/takeover.py", line 1032, in post_join_tasks_and_start_samba_without_drsuapi
    attrs=["objectSid"])
LdbError: (32, 'No such Base DN: ****')

Role: domaincontroller_master

Comment 4 Arvid Requate 2019-05-28 20:53:25 CEST

It's a bit unclear still how we get into this situation.


The AD server of the original report was: hpsap.intra.mm-network.hu

But the UCS master was set up with ldap/base "dc=MM-Systems,dc=local".

The traceback indicates that the customer has passed the actual samba-tool domain join. That can only have happend if the "root" ldap base of hte AD-Server also was "dc=MM-Systems,dc=local" (Attribute "rootDomainNamingContext" of the DSA) and not "DC=intra,DC=MM-Systems,dc=local" or something similar.


Thinking from the perspective of AD, my first idea was, that the customer may have two AD-Servers, one with "dc=MM-Systems,dc=local" and a subordinate one with "cn=intra,dc=MM-Systems,dc=local". But that would have led to diffrent error situations. In our tests we saw that the AD-Subdomain-Server would then send an LDAP referral when trying to count the AD objects and that would result in a different traceback. Looks like a dead end for three reasons:
 1) the tracebacks would be different
 2) the end result would be undefined: A UCS server as a subdomain
    of a AD domain, where the CN=Configuration parition seems to get
    replicated between both. At least that's a pretty interesting situation.
 3) We were unable to do a samba-tool domain join into this subdomain-AD,
    it always aborted with some permission issues when modifying an object
    that was in the parent AD-Domain.



Second attempt, thinking from the perspective of UCS: The customer configured a UCS ldap/base that doesn't match kerberos/realm (which is derived from domainname in 01univention-ldap-server-init.inst). kerberos/realm in turn is the basis that 96univention-samba4.inst uses to derive the value of samba4/ldap/base. And that doesn't match the AD-domain, that is obvious from the Python traceback. AFAICS our takeover code doesn't adjust kerbers/realm to the AD domain at any point. Ww should probably try to determine that from the AD server, the question is just, how to do that properly. I'll add a non-functional sketch of a patch to clarify the points that would need adjustment.

Comment 5 Arvid Requate 2019-05-28 20:54:37 CEST

Created attachment 10048 [details]
set_samba4_ldap_base_from_ad.diff

That's the basic idea, but I don't know how to properly determine the kerberos realm of an MS AD DC.

Comment 6 Ingo Steuwer 2021-05-14 16:38:27 CEST

This issue has been filed against UCS 4.3.

UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.