Delegated Permissions

The great majority of services of the Bacula Enterprise M365 plugin are using the model of ‘Application permissions’. With this model, the plugin application can directly access the implied services once a tenant admin has aproved it.

On the contrary, some other services can require the model of ‘Delegated permissions’ where the plugin needs to impersonate a given user in order to be capable of accessing and restoring the data inside the service. Although we will support more in the future, currently, the only service requesting delegated permissions is:

Calendar: If any group is included as an entity to protect

Chat: In order to be able to backup all chat messages belonging to a certain user the user in question will need to delegate the permissions as described below.

Delegated permissions or application permissions are automatically applied when they are needed. However, delegated permissions need user interaction the first time they are invoked, or if the local information about access tokens has been lost for some reason.

The user interaction can be manually triggered with a special query command that may be run as follows:

query-login

.query plugin="m365: tenant=e421f055-748a-4a80-90da-bf48b66fa166 objectid=9017f87a-c164-488e-8f93-47139bcd6d47" client=127.0.0.1-fd parameter=login:peter@bacula.onmicrosoft.com
info=Connected through: bacula-m365-plugin-standalone
info=We don't have a valid token for peter@bacula.onmicrosoft.com. It's needed to sign in
info=To sign in; use a web browser to open the page https://microsoft.com/devicelogin and enter the code LXSZGLY3F to authenticate. Please do it with peter@bacula.onmicrosoft.com

Note the format of the parameter, that is parameter=login:[usermail].

Additionally, it is possible to log in using a group with the format: parameter=login:[groupname] or a site, using exactly the same format and the site name.

query-login

.query plugin="m365: tenant=e421f055-748a-4a80-90da-bf48b66fa166 objectid=9017f87a-c164-488e-8f93-47139bcd6d47" client=127.0.0.1-fd parameter=login:Dev/Team/1
info=Connected through: bacula-m365-plugin-standalone
info=We don't have a valid token for any group owner of Dev/Team/1. It's needed to sign in
info=To sign in; use a web browser to open the page https://microsoft.com/devicelogin and enter the code LYZF9EC6Q to authenticate. Please do it with some owner of the group Dev/Team/1
info=Owners found: jorge@bacula.onmicrosoft.com;AdeleV@bacula.onmicrosoft.com
info=We have a valid token got from account:
user=jorge@bacula.onmicrosoft.com
info=It will be automatically refreshed when needed. But the current expiration date is: 2025-06-27T12:33:49Z
info=Backups using services with delegated permissions around jorge@bacula.onmicrosoft.com won't ask for intervention

We only need to follow the instructions, open a browser, enter the code and use the correct user to login (which means a user with access to the resource we want to backup).

For example, if we are working with the calendar of a group, we will need a user with access to that calendar (in general, to protect calendars associated to groups, it will be necessary to create a special backup user with access to all of them and perform the login with, which will avoid the need of performing the login process for every different group).

Here, if any MFA mechanism is enabled, it will be normally required and the user must complete the associated process. Finally Microsoft will ask to confirm if we want the plugin app to proceed with the operation, and we need to confirm:

Once the login is complete, the plugin will automatically end the operation and show something like:

query-login-2

info=We have a valid token got from account: johndoe@johndoe.onmicrosoft.com
info=It will be automatically refreshed when needed. But the current expiration date is: 2021-06-16T16:18:16Z
info=Backups using services with delegated permissions won't ask for intervention

It will also store the token information locally in a special file that it is stored in the working directory inside a folder with the tenant name. For example: /opt/bacula/working/m365/tennantname/[appid]-token_cache.json

This file is also backed up in the backup operation itself, so it can be restored manually, in case it was lost and in case you don’t want to run login operations again

In case the query method is not invoked prior to any job needing it, the job itself will show the message in the joblog and it will be blocked until a user performs the needed interaction described above. Once this happens, the job will automatically continue.

To verify the users currently logged into the system, we can use another query call using the logged-users parameter:

query-logged-users

.query plugin="m365: tenant=e421f055-748a-4a80-90da-bf48b66fa166 objectid=9017f87a-c164-488e-8f93-47139bcd6d47" client=127.0.0.1-fd parameter=login:logged-users
info=Connected through: bacula-m365-plugin-standalone
user=AlexW@bacula.onmicrosoft.com
user=jorge@bacula.onmicrosoft.com

Note

Starting with version 14.0 of Bacula Enterprise you can also see logged in users directly using BWeb, where you can also manually add logged-in users. In order to see more details, please go to section: BWeb Console<./m365-bweb-console>.