This is a technical companion to our main Microsoft 365 set up document and does not apply to anyone using a service account to connect with Microsoft 365 instead.
When setting up Robin for the first time, you may wonder why a Global Admin is required to authenticate as part of the set up process. Especially if you're used to using delegate access to manually share permissions between accounts.
This is something we're happy to answer and welcome opportunities to show our security practices. Based on past conversations, this article shares a few clarifications others found useful. Before you continue, we recommend reading this introduction to Azure app setup from Microsoft.
More familiar with Exchange service accounts?
If you don't want to use the app method, you can also set up a service account for Robin instead.
The big idea
In order to sync calendars, Robin needs to install an integrated Azure AD app onto your Microsoft 365 account. In Microsoft 365, only a Global Admin has the ability to install integrated Azure apps. This is a great thing for security, and prevents any user from giving apps access to sensitive parts of your configuration.
We'll let Microsoft give you the full explanation on Azure App installation:
Only global administrators can:
- Add apps from the Azure AD app gallery (pre-integrated 3rd Party Apps)
- Publish an app using the Azure AD Application Proxy
All users in your directory have rights to add applications that they are developing and discretion over which applications they share/give access to their organizational data. Remember user sign up/in to an app and granting permissions may result in a service principal being created.
What does the installed app do?
Robin uses this app as a gateway to manage room calendars and the users involved in each room's meetings. You probably already have a few other services installed similarly and can see a list of apps you have today via http://myapps.microsoft.com
"Why not only share access to the room calendars?"
Robin's scheduling tools are focused on room calendars, however we frequently have to update meetings on behalf of users where the room calendar is just one of several which needs updates. This "cascading" concept is a key part of how we manage calendars when both people and rooms are involved.
This is easy to visualize using Google Calendar. In this case we just edit the room's event and nobody else is updated:
But if you update the organizer's version it changes everywhere:
If you used a more explicit delegate approach, you'd quickly run into a problem of new employees having to share their personal calendars with the delegate and keep that list up to date to avoid "I deleted this event; why is it still on my calendar if the room is free?" moments.
As we continue to develop user-to-room and user-to-user scheduling tools, this permission becomes more and more important to successfully scheduling without creating confusing workflows for your users.
"Why does it ask for full access to all mailboxes?"
In short, there are three ways apps (like Robin) can authenticate with Exchange services:
- NTLM: One-way hash of username and password. Most secure way of storing credentials for on-premise Exchange.
- Basic: Plaintext username and password. This method is considered insecure and we don't support it with Robin.
- OAuth: Scoped token-based authentication standard, used by apps/services to request very specific rights for your account.
While we support NTLM for connect on-premise/hosted Exchange servers to Robin, Microsoft 365 (via EWS) only supports OAuth and Basic authentication and not NTLM. If you see apps ask for just your Microsoft 365 username and password to authenticate, it means they are using Basic authentication, and store your account password and username, which is a bigger security concern since the account info has to be decrypted on use when using Basic Auth.
Put another way, if you cannot connect to Microsoft 365 through OAuth there's a considerable concern with security compromising via apps that allow you to sign in via Basic authentication. For this reason, we only support OAuth authentication at this time.
Using OAuth, we securely install the connector app onto your Microsoft 365 account. For Microsoft 365/EWS, Microsoft (for some inexplicable reason) requires that all OAuth apps request this permission. Robin does not use it. Once installed, the Robin app can only interact with your calendars.
"Why do you need global admin privileges just to manage room calendars?"
Happily, we don't.
Once the app is installed, the global admin account is no longer involved with managing calendars. To use a really extreme example: You could make a brand new Global Admin account, use it to install the Robin app, then delete the account entirely and Robin would still be good to go since the app is already active.
By installing the app, Robin does not gain the abilities of a Global Administrator in your organization. Similar to how creating a new user mailbox as the Global Admin does not transfer power to the user account simply because an admin is needed to complete the setup step.
If this presents problems, we strongly recommend using the service account method to connect instead.
You can also read more about our security practices here.