Ich kann nur aus der Erfahrung mit Azure AD Connect (gegen MS AD) sagen, dass ich auch unsicher war, weil von früher her nicht wenige Benutzer im AAD tenant sich selbst registriert hatten. Ich habe mir damals einen Testmandanten gebastelt genommen und das durchexerziert, um sicher zu gehen, weil wir eine ganze menge selbst registrierter User im schon hatten.
Ich kann dir das gleiche empfehlen, alternativ gehst du zu einem Univention Partner oder Univention direkt, je nach Grösse wirklich nicht verkehrt, da du eine solche Integration vielleicht alle paar Jahre machst, wenn nicht einmalig.
Damals haben letztlich AAD connect und Azure ein soft-matching basierend auf dem UPN in Azure gemacht (Mailadresse), das hat funktioniert, auch wenn ich dem zuerst nicht getraut habe. Danach hat die uniqueId aus AAD ins AD als ms-DS-ConsistencyGuid runterschrieben, das ist bei AAD connect dann der sourceAnchor.*
Was der verlinkte Artikel erwähnt, ist da vom Prinzip her sehr ähnlich, prinzipiell scheint UniventionOffice365ObjectID auch noch im LDAP Schema aufzutauchen.
Du müsstest also wirklich herausfinden, wie du als Anker zwischen UCS und Azure AD diese ObjectID angleichst. Es ist natürlich schade, dass der verlinkte Thread aus 2018 nicht mehr tut, denke aber, das ist “ein” Schlüssel ans Ziel.
Die damaligen Einchränkungen, wie bei der Wahl des Loginnamens auf Azure mit dem O365 connector, waren übrigens relevante Gründe, am Ende eben nicht den O365 connector einzusetzen. Vielleicht wäre das heute anders.