Skip to main content
Troubleshooting

"Microsoft Entra role needed" on your own tenant's Data Governance

Why your Internal client's Data Governance needs an Entra role on the connected account, which roles work, and where to assign them.

Written By The Lemhi Product Team

Last updated 10 days ago

This is for the MSP admin who sees "Microsoft Entra role needed" on Data Governance for the Internal client, your own Microsoft 365 tenant. When you finish, the connected account holds a role that SharePoint and sensitivity labels accept, and Check again shows access restored.

Microsoft Entra role needed

The banner text: "The account connected to Lemhi doesn't hold a Microsoft Entra role this data needs in your own tenant, such as Global Reader. Reconnecting won't add it. Review access names the account and where to assign the role."

Your own tenant has no GDAP relationship. In a client tenant, the roles come from the relationship and its security group. In your own tenant, the account that completed Partner Connect acts as itself, so it needs the role directly, assigned in your own Microsoft Entra. Reconnecting Partner Connect does not add a role, so the banner has no reconnect button.

Which roles work

Data

Roles Lemhi accepts

SharePoint

Global Reader (SharePoint Administrator also works, but grants write access)

Sensitivity labels

Compliance Administrator

Assign Global Reader for SharePoint. Sensitivity labels need Compliance Administrator.

<account> does not hold <roles> in your own Microsoft 365 tenant, so Microsoft refuses this read.

Select Review access on the banner. The sheet names the account and the roles for each workload. You fix this in your own tenant.

  1. In Microsoft Entra, open Roles and administrators, select the role, and add an assignment for the account. The sheet has a link that opens Roles and administrators directly.

  2. Wait. Microsoft can take up to an hour to apply a new role to Lemhi's access: a SharePoint token Lemhi already holds can keep refusing for up to an hour after the role is assigned.

  3. In Review access, select Check again.

The sheet shows Access restored when the read works. If it shows Access is not restored yet, wait and check again.

Lemhi could not check the roles of <account>.

Lemhi couldn't read the account's roles, so the steps are manual checks:

  1. In Microsoft Entra, check whether the account holds one of the roles above in your own tenant.

  2. If your organization uses Privileged Identity Management (PIM), check that the role is active, not only eligible.

<account> holds a role that allows this read in your own Microsoft 365 tenant, but Microsoft still denied the read.

The role is in place and Microsoft still refused. The sentence ends differently when the data couldn't be read ("but the data could not be read") or Lemhi couldn't reload it ("but Lemhi could not reload the data to confirm"); for those two, use Check again.

  1. Microsoft can take time to apply access changes. Use Check again after some time.

  2. If your organization uses Privileged Identity Management (PIM), check that the group membership is activated.

  3. If it keeps failing, copy the troubleshooting details for support.

Related

Still stuck? Send your Lemhi contact the text from Copy troubleshooting details in Review access, and the role you assigned with the time you assigned it.

Was this helpful?

Still need help? Ask the team