Microsoft 365 / Office 365 Adapter - FNMS 2019 R1 - Azure User Account Roles / Token Generation

[kyle_wolff]

I was stepping through the new Microsoft 365 adapter post FNMS 2019 R1 with a customer and the customer had some concerns with how the adapter was built with regards to the token generation. The current adapter uses a Azure User based account that requires Multi Factor Authentication to be turned off, Global Administrator and Cloud Application Administrator roles, and based on token generation policy, has to re-generate the token every time the adapter runs (considering their specific policy is set to require a refresh token every 8 hours).

My customer does not like the idea of the Global Admin and Cloud App Admin roles being a requirement for the adapter to work ongoing after the initial setup where these roles are required. No account in their enterprise has these roles. So we did some additional trial and error to see if there was a way around this requirement. Which, led my customer to point out that it appears this adapter was built in a non-standard way, against Microsoft's best practices. The typical way to would be to create "Secrets" or "Certificates" for an application (https://docs.microsoft.com/en-us/graph/auth-v2-service#4-get-an-access-token) using Graph Application Permissions. Having the FNMS Microsoft 365 adapter written to use Graph Application Permission "Secrets" or "Certificates", would negate the need for an Azure user account to need to keep the Global Admin and Cloud App Admin roles assigned to it as long as the adapter is running as it wouldn't require a refresh token daily. Using the method documented in the link above, one could create a "Secret" or "Certificate" to apps, with admin consent, had have their validity times set to 1 year, 2 years, indefinitely.

I noticed the document I linked above was written May 3rd 2019 and this FNMS Microsoft 365 adapter was create before then. So on behalf of my customer, considering this Microsoft Graph best practice information, could the adapter be re-written again using "Secrets" or "Certificates" to avoid the ongoing need for an Azure user account to have the Global Administrator  and Cloud App Admin roles to it? It goes against this customers every security policy so they are hoping for a solution.

Thank you in advance and appreciate any information and input.

[pemerson1]

Hello Kyle,

Thank you for writing. 

I think the role requirements of two O365 connectors have been mixed up here. Note there is an OLD O365 connector named Microsoft Office 365 which required a Global Administrator or Billing and Skype Admin and there is a newer O365 named Microsoft 365 which requires Cloud Application Admin.

The older connector uses credentials to connect to O365 services while the newer connector uses an OAuth token. The older connector did not support 2-factor authentication however the newer one does.

Now there are various ways to connect to O365 via Microsoft Graph but it also depends on the application type. There are some ways specifically for Web Applications because they can store the credentials in their database on cloud and then there are some for Native Applications (like installed on Computers, Mobile devices). These mechanisms are mentioned here

Now the one you mentioned in your question is Client credentials grant flow which is typically used for Server-2-Server communication, in this case a Client Secret is generated and stored on client WebServer and this is then used to connect to Microsoft servers. However in this case, FlexNet Beacon, which is a native application, connects to Microsoft servers hence using a client secret flow is not secure and best practice. Therefore we use Auth code grant which is meant for Native applications.

Please refer to documentation for further detailed information.

Regards,

-Pete

[mercym]

What type of access would we advise the client to allow the account if they are not comfortable giving Cloud application Administrator?

[kyle_wolff]

Thanks Peter, I ran this by my customer and have shared their response below:

"

Hi Kyle / Peter,

Thanks for the feedback.  In the context of the Microsoft 365 connector, I don’t agree that it should be considered a MS Native application or that using a client secret flow is not secure / best practice.   Native applications generally call a web API on behalf of a logged in user as described here and are predicated on using the authorization code from the logged in user to acquire an access token for a resource.  My understanding is that the FlexNet Beacon will reach out to Azure AD on a regular basis to pull Azure AD information regardless of who is logged into the Flexera system at time. In my opinion more this scenario more closely resembles a scheduled server to server call as described here.  In server to server scenarios, MS does recommend using a client secret or certificate as long as the information is stored in a secure manner. 

Also, please note that the Cloud Application Administrator role required by the Microsoft 365 connector grants the ability to manage all aspects of all Azure enterprise applications and application registrations (described here).  This includes the ability to remove ALL applications registered in the Azure Tenant as well as impersonate any application in Azure (elevation of privilege).  As a result, this role is especially sensitive and must be treated accordingly.  In fact at <customer name>, this is the first time this role has ever been requested on behalf of an individual application. My recommendation is that the Flexera team review the design of the Microsoft 365 connector and weight all aspects of the solution to determine if they are on the right path or if changes are necessary (server to server vs native, client secret / certificate vs highly privileged role, etc). I am not an expert on the Flexera software but in my opinion, there is room for improvement.  Thanks

"

[ShaneM]

I very much agree that the use-case is read only and having this level of permissions configured seems way out of scope.
I also agree that this this use-case does behave in a system-to-system context and not a user application context.  Specifically because an independent "service" account should be used for this communication which has nothing to do with the authenticated user.

This is definitely not a minor factor, for my company at least.

[iammanzi]

@kyle_wolff  Can you advise what workaround helped you?

[Alpesh]

Hi Kyle,

Please review the following points and let us know if this helps you with the concerns you have raised in this post.

•  Flexera’s O365 App is considered a native App and it is being used by Beacon, which is installed in the User’s environment. The credentials information is not stored on FNMS Cloud anywhere. Flexera’s O365 App uses the OAuth 2.0 authorization code grant to generate the token and get the data: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow 
• If Flexera’s O365 App was a Web App and storing the refresh token on the Cloud Servers then we would need to use the Client Secret, as explained in the OAuth 2.0 Client Credentials Grant Process: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
• This Microsoft article clearly explains the consent and Permissions process that our new O365 adapter uses --> https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent
• Also about Cloud Application Administration permissions getting misused, on following the article above you will see that anytime the actual permissions get changed, the user will be requested a dialog for consent. In the O365 adapter for FNMS, the permissions actually used are Directory.Read.All and Reports.Read.All and both these permissions can only be consented by an admin. Hence, the clould application administrator role is needed and also that the role cannot be misused without consent from the administrator again.

Thanks! 

[winvarma]

The Azure cloud administrator is not receiving any kind of alerts when the Flexera Beacon is asking for the permissions and its working only when the flexera account from which the consent was sent should be assigned with the Cloud Application Administrator permissions and these permissions were not confined to the Flexera App itself , please suggest a workaround where in we can confine or restrict the permissions of the cloud application to particular app in this case flexera beacon

[douglasrfuller]

I'm just curious if there are any plans to change the way that the Office 365 Adapter works any time in the foreseeable future?

Thanks!

[ChrisG]

A key driver for developing the Microsoft 365 adapter was to significantly change (improve on!) how the Office 365 adapter went about things. Now that the Microsoft 365 adapter has been done and the Office 365 adapter has been deprecated, no further significant changes to the Office 365 adapter are planned.

[mercym]

For a workaround I would suggest that the Office 365 with correct access (cloud admin) generate a token from their side and provide it to you, also remember they need to allow multi-tenant when creating the application.

[Ralph_Crowley]

Did this work in your environment ? (having a token generated & provided to the flexnet beacon). Our admins have similar concerns about extending the cloud admin privileges. 

[mercym]

Hi

The token works, just remember to include the multi-tenant in Office 365.

Regards

Mercy