Bug 40350 - create cleanup page for office365
create cleanup page for office365
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: Office 365
UCS 4.1
Other Linux
: P5 normal (vote)
: UCS 4.1-x
Assigned To: Mail maintainers
:
Depends on: 38950
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-30 16:09 CET by Daniel Tröder
Modified: 2019-01-03 07:21 CET (History)
2 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Tröder univentionstaff 2015-12-30 16:09:36 CET
Because of permission changes in the Azure API (see Bug #) users are currently not deleted in the Azure AD but only deactivated. Those are now also marked (immutableId = "deactivated_<immutableId>"), so they could be automatically deleted with the proper permissions.

Those permissions are granted in an interactive session that could easily be implemented in a UMC UI module. The user would click a button "cleanup", be redirected to authenticate with MS and then UMC could issue the appropriate commands to the Azure REST API and delete all marked users.

The code for this is in ucs-4.0/component/office365/univention-office365/ as there I didn't know how to do it with certificates.
Comment 1 Daniel Tröder univentionstaff 2015-12-30 16:14:54 CET
MS make changes permission in the Azure API for client authentication [1][2][3] without creating an alternative first... The listener deactivates users and remove the occupied licenses. But that still leaves them in existence in the Azure AD. Furthermore the properties "password" and "mobile" cannot be changed (can only be set when creating the user).

Currently the AAD user accounts are reused if the user would be reactivated. They could also be renamed, so every time a new user would be created. This could be used as a workaround for the "mobile" attribute.

It should be checked if the PowerShell script is easy for customers to run.

[1] https://github.com/Azure-Samples/active-directory-dotnet-graphapi-console/issues/27
[2] https://support.microsoft.com/en-us/kb/3004133
[3] http://stackoverflow.com/questions/31834003/azure-ad-change-user-password-from-custom-app
Comment 2 Daniel Tröder univentionstaff 2016-01-04 10:24:16 CET
postponed
Comment 3 Stefan Gohmann univentionstaff 2019-01-03 07:21:50 CET
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact
your partner or Univention for any questions.

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