+++ This bug was initially created as a clone of Bug #44749 +++ Almost all customers that use the Office365 connector have asked for the possibility to connect existing Office365 users to existing ucs users. We described how to do the process manually here: https://help.univention.com/t/ucs-office365-issue/7209
Created attachment 10219 [details] script to connect existing UCS users to existing Azure AD users
Created attachment 10628 [details] script to connect existing UCS users to existing Azure AD users v2 New version of the script, support for multiple ad connections added. Example call: There is a testuser uid=test03, and an Azure user aaduser_03@somedomain.onmicrosoft.com. test03 should be connected, and the ad connection in UCS is the default 'defaultADConnection'. The user has no mailPrimaryAddress set in UCS, and is not activated for O365. We have to configure a mailadress, and choose to set the uid as the localpart, and use a maildomain that is configured in UCS, in this case 'mydomain.intranet' ./o365_connect_azure_to_ucs_user -p aaduser_03@univentiontestgmbh.onmicrosoft.com -u test03 --set_mail --maildomain mydomain.intranet --mail_localpart_from_uid -a -c defaultADConnection This is the default run, to really modify the user add --modify to the call. Disclaimer: Test this with testusers first, and double check every connected user. The modification will set the immutableID in the Azure AD, the script can only be called once for every user. To reset the immutableID in Azure, powershell on Windows can be used.
should be still relevant for UCS 4.4
That script does not work anymore with the recent version of the MS365 connector. Is there an updated version? I'm getting the following error with: - MS365 Connector 4.4 - UCS 4.9 $ ./o365_sync_existing_users Traceback (most recent call last): File "./o365_sync_existing_users", line 34, in <module> from univention.office365.azure_handler import AzureHandler ImportError: No module named azure_handler
Created attachment 11019 [details] script to connect existing UCS users to existing Azure AD users v3
Caveats: Hashbang needs to be different, depending on the UCS version 5.0 -> python3, 4.4 -> python2 The script is 90% idempotent: It can be executed many times for the same User. But! A successful script-run may change the UserPrincipalName in Azure which will break subsequest script-runs. How to test: Create UDM user: > udm users/user create --set username=blumendi --set lastname=blumendi --set password=univention --position cn=users,dc=test,dc=intranet --set mailPrimaryAddress=blumendi@test.intranet Create Azure user in Azure Portal (azuretestdomain) try to connect the users: Minimal Version: > python3 connect_existing_users.py -p "blumendi@alphadistrict.onmicrosoft.com" -u "blumendi" -c azuretestdomain -m user is not activated Add -a to activate user Add --set_mail --maildomain test.intranet --mail_localpart_from_uid to sync Mail aswell Look in UDM if the stuff was written into LDAP Look in Azure if the onPremiseImmutableId was synced Modify UDM user and see if it syncs to Azure: > udm users/user modify --dn uid=blumendi,cn=users,dc=test,dc=intranet --set lastname=blumendi333 --set firstname=blumendi444
Resetting bug state. If the bug has any state in the flag 'Resolution', it is not included in the bugzilla default search result. As this script is not part of the product at the moment, this bug should be easy to find.
A partner requested the solution for this feature while preparing for a partial migration of users from an existing UCS@School instance to a new one.
Why hasn't this been made part of the product yet? The bug is 5 years old. The original bug is even 7 years old! The opening clearly says that almost every customer using the app needs this. I have made this a "bug" instead of a "feature request," so it gets better prioritized. The feature (a script) exists. It just hasn't been packaged properly. IMHO, that's a bug. The script to do this has existed for 5 years now. All that's left to do is add it to the distribution and write a test + Jenkins for it to support it.
(In reply to Daniel Tröder from comment #10) > Why hasn't this been made part of the product yet? The bug is 5 years old. > The original bug is even 7 years old! > The opening clearly says that almost every customer using the app needs this. > > I have made this a "bug" instead of a "feature request," so it gets better > prioritized. > The feature (a script) exists. It just hasn't been packaged properly. IMHO, > that's a bug. > > The script to do this has existed for 5 years now. > All that's left to do is add it to the distribution and write a test + > Jenkins for it to support it. I changed back to "Feature Request". I agree that the feature is helpful for many user scenarios, but as we never had this feature there is no reason to file this as a bug.
Requested again #2025032821000188
5.2 univention-office365 (5.0.1-14) 9bfca21e849b | chore(test): Add new test univention-office365 (5.0.1-13) 3593e7ed4c74 | chore(scripts): Add connect_existing_users to usr/share/univention-office365/scripts/ 5.0 univention-office365 (3.0.1-33) cca943371ead | chore(test): Add new test univention-office365 (3.0.1-32) fd9963eec1df | chore(scripts): Add connect_existing_users to usr/share/univention-office365/scripts/
The script works fine. And it's include in the new office app place in: `/usr/share/univention-office365/scripts/connect_existing_users` The new feature discover and connect users need to be discussed with PM.
Great news! Why not make it available as /usr/sbin/office365-connect-existing-users ? It's what other applications do, too. It'll make it easier to use for customers and easier to document.
(In reply to Daniel Tröder from comment #21) > Great news! > > Why not make it available as /usr/sbin/office365-connect-existing-users ? > It's what other applications do, too. > It'll make it easier to use for customers and easier to document. Because that is the place where all scripts from Office 365 are located.
(In reply to Iván.Delgado from comment #22) > (In reply to Daniel Tröder from comment #21) > > Why not make it available as /usr/sbin/office365-connect-existing-users ? > > It's what other applications do, too. > > It'll make it easier to use for customers and easier to document. > Because that is the place where all scripts from Office 365 are located. Time to change a bad habit. If you want backward compatibility, create symlinks from /usr/sbin/office365* to /usr/sbin/.