Lemhi can't sign in to a client's tenant: Review connection findings

This is for the MSP admin who sees "Lemhi can't sign in to this client" on a connected client. Each section is headed by the finding's first sentence as Lemhi shows it. When you finish, Check again shows that Lemhi can sign in, and the nightly sync brings the client's employees up to date.

Where it shows

The same finding shows in four places:

• Settings > Microsoft Partner Account > Review connection, under Client connections. Clients with a problem are listed alphabetically with a count, such as 1 problem. Opening a row shows that client's finding; a stored check more than an hour old is rechecked. Below the list: "<N> other clients have no recorded sign-in or relationship warnings." That line doesn't claim every workload works for those clients.

• The client's M365 Connection card in its settings, in full.

• The client's overview strip, as one line linking to the card.

• The client's Data Governance banner.

When no check describes the refusal yet, a drawer row shows "Nightly sync blocked in the client's tenant (<code>) since <date>." with Check again.

If the partner account sign-in is broken, these places show the partner notice instead of any client finding. Fix that first: see Partner Connect stopped working.

Each finding has a summary, numbered steps, any Manual checks (things Lemhi couldn't verify), links to Microsoft's instructions, and buttons for Check again, the admin center to open, and Copy troubleshooting details. Under the steps, "Last checked <time>." When reconnecting can't help, it adds "Reconnecting Partner Connect does not change this."

<account> isn't a member of <group>, the security group your GDAP relationship <relationship> with <client> assigns its roles to.

The account that completed Partner Connect isn't in the group your relationship gives its roles to. You fix this in your own tenant. Reconnecting doesn't change it.

1. In Microsoft Entra in your own tenant, add the account to the named group as an active member. If the membership is eligible in Privileged Identity Management, make it active: Lemhi's nightly sync runs when no one can activate it.

2. Select Check again.

The overview strip shows: "<account> isn't in the GDAP security group for this client."

Your GDAP relationship <relationship> with <client> has no active security group assignment.

The relationship exists, but no security group is assigned to it. You fix this in Partner Center. Reconnecting doesn't change it.

1. In Partner Center, assign the relationship's roles to a security group that the account belongs to. See Step 3.

2. Select Check again.

Your GDAP relationships with <client> grant no Microsoft Entra roles.

Your relationships with this client carry no Entra roles. A relationship can't gain roles after approval, so you need a new one. Reconnecting doesn't change it.

1. In Partner Center, request a new relationship with the roles Lemhi needs and ask the client to approve it. See Step 1 and Step 2.

2. Select Check again.

You have no active GDAP relationship with <client>.

No relationship with this client is active. The fix and the steps are the same as the section above. If the relationship ended, see Access ended or ending.

The overview strip shows, for both: "You have no active GDAP relationship with this client that grants a role."

Lemhi couldn't check your GDAP access to <client>.

Microsoft refused the sign-in, and Lemhi couldn't read your GDAP setup to find where it breaks. The summary adds one reason:

• The Partner Connect connection could not be used.

• Microsoft denied the request for GDAP details.

• The check took too long.

• There were too many results to read.

• Microsoft returned an unexpected response.

• A Microsoft request failed.

Lemhi couldn't tell where the access breaks, so the steps are checks:

1. In Partner Center, confirm your GDAP relationship with the client is active.

2. Confirm its roles are assigned to a security group that the account is an active member of.

3. Select Check again.

<client>'s Microsoft tenant requires multi-factor authentication that Lemhi's overnight sign-in can't complete.

Microsoft code AADSTS50076. A Conditional Access policy in the client's tenant asked for MFA, and Lemhi signs in without anyone present. You change the policy in the client's tenant. Reconnecting doesn't change it.

1. In the client's Microsoft Entra admin center, open Sign-in logs and find the failed sign-in for the account to Lemhi Partner Connect at the time and trace ID the finding gives. Its Conditional Access tab names the policy that applied.

2. In that policy, exclude Service provider users for your organization's tenant.

3. Select Check again.

Manual check: "If the policy sets a sign-in frequency, that is the likely cause: Lemhi signs in without anyone present, so it can't re-authenticate."

<client>'s Microsoft tenant requires multi-factor authentication that Microsoft says <account> hasn't registered.

Microsoft code AADSTS50079. The steps are the same three as the section above. The manual checks differ, because a GDAP account completes MFA in your own tenant, not the client's:

• In your own Microsoft Entra admin center, open Users > the account > Authentication methods and check that a method is registered that meets the policy.

• If the account signs in through another identity provider, check that the provider sends Microsoft the multi-factor authentication claim.

• If you register a method and Check again is still refused, reconnect Partner Connect with that account so Lemhi's stored sign-in uses the method, then select Check again.

Whether registering a method clears this without a reconnect isn't established, so Lemhi doesn't say either way.

A Conditional Access policy in <client>'s tenant blocks Lemhi's sign-in.

Microsoft code AADSTS53003. A Conditional Access policy in the client's tenant blocked the sign-in. The steps are the same three as the AADSTS50076 section. Reconnecting doesn't change it.

For these three policy findings, Lemhi may add that none of the roles on your GDAP access can open the client's sign-in logs (Reports Reader can) and its Conditional Access policies (Security Reader can read them; Conditional Access Administrator can change them), naming whichever it couldn't read. Reports Reader and Security Reader are in the six roles from Step 1. If your relationship lacks them, request a new relationship that includes them (Step 1) and assign them to a group your account is in. When the path is otherwise complete, the finding says: "Your GDAP access to <client> is complete; the client's sign-in policy is what refuses it."

Microsoft blocked <account> from signing in to <client> because it flagged the account as risky in your own tenant.

Microsoft code AADSTS530032. Microsoft flagged the account as risky in your own tenant and blocked the sign-in. You fix this in your own tenant.

1. In your own Microsoft Entra admin center, open ID Protection > Risky users and find the account. Investigate the risk detections: Microsoft flagged this account as possibly compromised.

2. Remediate the risk: reset the account's password, or dismiss the risk once you've confirmed the account is safe.

3. If you reset the password, reconnect Partner Connect afterwards (the password change ends Lemhi's stored sign-in), then select Check again.

Microsoft refused Lemhi's sign-in to <client> (<code>). Lemhi found an active GDAP access path for <account>, so the cause is not known.

Your relationship, group and membership all check out, and Microsoft still refused. Lemhi doesn't guess a cause. Reconnecting doesn't change it.

1. Microsoft can take time to apply a recent change. Select Check again later.

2. If it still fails, select Copy troubleshooting details and send them to Lemhi support.

Microsoft refused Lemhi's sign-in to <client> (<code>).

Microsoft returned a code Lemhi has no finding for yet. The finding shows the code, when it was refused, Microsoft's trace ID, and: "Lemhi doesn't have specific steps for this yet; we've been alerted."

Sign-in restored; sync pending

This drawer label means a newer check signed in, but the nightly employee sync hasn't succeeded since the refusal. The card shows "Lemhi can sign in to <client> again" with "Sign-in checked <time>." and the last successful employee sync, as separate times.

• On the client's card: "Employee sync is still pending. Select Sync from M365 to try now, or wait for the next scheduled sync."

• A drawer row with only Sign-in restored had no sync refusal recorded: "A successful sign-in does not confirm that reports load."

The row stays listed while the drawer is open.

What Check again proves

Check again runs a new sign-in to the client. A pass proves sign-in only. The nightly sync, or Sync from M365, proves employee sync. A report is proven when it downloads and loads. Lemhi doesn't clear a sync problem on a sign-in pass, and doesn't promise the next sync will work.

Copy troubleshooting details

Copy troubleshooting details copies plain text: the client, the connected account, when it was checked, the result, Microsoft's code, the finding, each relationship, any group the account isn't in, the refusal time, the client tenant ID, Microsoft's trace and correlation IDs, whether your roles can read the client's sign-in logs and Conditional Access, and a support reference. It never includes tokens or Microsoft's raw error text. Paste it as is.

Related

• Step 3: Assign your security group

• Partner Connect stopped working

• Access ended or ending

Still stuck? Send your Lemhi contact the text from Copy troubleshooting details for the client, and what you changed since the last check.