Cannot do an AD take over

talleyrand · February 2, 2023, 2:56am

During an AD takeover & replacement
Everything works ok and univention claims it migrated >200 objects correctly.

The annoying thing is that, it has worked for a load of users.

then there are 4 it did not work for

then there are a load MORE users it DID work for.

then some others bringing the total objects to about 94…

now either the migration process works or it does not, why should groups of records fail to migrate
whilst most of the others are ok?

If the records contain bad fields , this should be flagged during the migration process.

using LDAP editor to check these records there IS a “uidNumber” feild & it is populated.

and most users are migrated but in the s4 connector it states this:

01.02.2023 14:21:41.493 LDAP        (PROCESS): sync AD > UCS: Resync rejected dn: 'CN=firstname.secondname,OU=01-Office,DC=org,DC=blown-up,DC=com'
01.02.2023 14:21:41.496 LDAP        (PROCESS): sync AD > UCS: [          user] [       add] 'uid=firstname.secondname,OU=01-Office,dc=org,dc=blown-up,dc=com'
01.02.2023 14:21:41.528 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
01.02.2023 14:21:41.529 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/univention/s4connector/__init__.py", line 1483, in sync_to_ucs
    result = self.add_in_ucs(property_type, object, module, position)
  File "/usr/lib/python3/dist-packages/univention/s4connector/__init__.py", line 1203, in add_in_ucs
    res = ucs_object.create(serverctrls=serverctrls, response=response)
  File "/usr/lib/python3/dist-packages/univention/admin/handlers/__init__.py", line 557, in create
    dn = self._create(response=response, serverctrls=serverctrls)
  File "/usr/lib/python3/dist-packages/univention/admin/handlers/__init__.py", line 1259, in _create
    self._ldap_pre_create()
  File "/usr/lib/python3/dist-packages/univention/admin/handlers/users/user.py", line 1431, in _ldap_pre_create
    univention.admin.allocators.acquireUnique(self.lo, self.position, 'uidNumber', self['uidNumber'], 'uidNumber', scope='base')
  File "/usr/lib/python3/dist-packages/univention/admin/allocators.py", line 214, in acquireUnique
    univention.admin.locking.lock(lo, position, type, value.encode('utf-8'), scope=scope)
  File "/usr/lib/python3/dist-packages/univention/admin/locking.py", line 124, in lock
    raise univention.admin.uexceptions.noLock(_('The attribute %r could not get locked.') % (type,))
univention.admin.uexceptions.noLock: Could not acquire lock: The attribute 'uidNumber' could not get locked.

talleyrand · February 6, 2023, 8:54am

ok tracked this down…
it seems to be a race condition in the take over code…

specifically related to this :
password_sync_s4_to_ucs: Mismatch between UCS pwhistoryPolicy (3) and S4 pwhistoryPolicy (5). Using the larger one.

after checking these records were non existant in the UCS database
i modified the “locking” code in :
/usr/lib/python3/dist-packages/univention/admin/allocators.py

every one of the bad records failed the pw match AD->ucs, once the S4 connector blew thru all the pw errors
and the code mod ignored the lock
every one of thee records was correctly merged into the database and:

univention-s4connector-list-rejected
UCS rejected
S4 rejected

There may be no rejected DNs if the connector is in progress, to be
sure stop the connector before running this script.
last synced USN: 6302

and it all synced up with no errors…

so. i think maybe during the takeover there is a discrepancy in the pw setup, which causes the sync to throw errors , which then exit without the record lock being cleared, so that when it tried to add the users,
it cannot because the field is locked…
then on the next try it happens again… (pw length errs etc)

now since this is only a test AD, no users are logged in and nothing is changing in these records, so they should not be locking…

so basically for all 112 users that could nto add the first time:

modify code base
flusy py buf
3.restart
after that the lock for the 112 records is ignored & … they all flush as below"

06.02.2023 16:34:11.589 LDAP (WARNING): password_sync_s4_to_ucs: Mismatch between UCS pwhistoryPolicy (3) and S4 pwhistoryPolicy (5). Using the larger one.
06.02.2023 16:34:11.648 LDAP (PROCESS): sync AD > UCS: Resync rejected dn: ‘CN=first.last,OU=Resigned-Staff,DC=org,DC=blown-up,DC=com’
06.02.2023 16:34:11.653 LDAP (PROCESS): sync AD > UCS: [ user] [ add] ‘uid=first.last,OU=Resigned-Staff,dc=org,dc=blown-up,dc=com’
06.02.2023 16:34:12.589 LDAP (WARNING): password_sync_s4_to_ucs: Mismatch between UCS pwhistoryPolicy (3) and S4 pwhistoryPolicy (5). Using the larger one.

06.02.2023 16:34:39.239 LDAP (PROCESS): sync UCS > AD: [ group] [ modify] ‘cn=resigned-staff,cn=groups,DC=org,DC=blown-up,DC=com’
06.02.2023 16:34:39.285 LDAP (PROCESS): sync UCS > AD: [ user] [ add] ‘cn=first.last,ou=resigned-staff,DC=org,DC=blown-up,DC=com’

06.02.2023 16:34:51.862 LDAP (PROCESS): sync AD > UCS: [ user] [ modify] ‘uid=first.last,ou=resigned-staff,dc=org,dc=blown-up,dc=com’

and modify the code base back, manipulate any of these records & now it all syncs up correctly both ways.

atrobins · August 9, 2024, 6:22pm

Could you elaborate on the modifications you made to allocators.py. I’m having the exact same issue and still trying to resolve it. Thanks again for the assistance.

talleyrand · August 12, 2024, 1:35am

The code base has changed significantly since that time.

I had a look at this code and there have been changes in that area.

There were some pre-requirments

basically you have to throw away the migration and start again with the modifications in the code before you start.
once you get to the error stage, it is too late, the code has alredy errored out and you cannot get back into it to restart it, or re-run it.

I think I eventually tracked this down to a security fix made by MS

mS-DS-CreatorSID. a 28byte flag in the LDAP user record (or some of them)

there was a way a non admin could take over accounts, so Ms changed it to log who instigated the original account

but it true MS style they only modified the records AFTER the date of that fix., so there were random cases where user records some had a flag ,others did not.

There are all sorts of errors in the take over code and weird boundry cases… ESP for 2008SP2
I opened multiple bugs and it took them over a year to “Agree” and fix some of them.

atrobins · August 25, 2024, 1:36am

Thanks so much for getting back. I really appreciate the response since it is such an old thread.