This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(272, 54%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETP%3C/text%3E%3C/svg%3E)
When trying to access the Microsoft share point site, guest users receive the message as couldn’t find account.
All of them have Entra accounts. All these accounts are having identifier as mail in their account attributes .
Any advise will be really helpful
A cloud-based identity and access management service for securing user authentication and resource access
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(9.6, 23%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ERE%3C/text%3E%3C/svg%3E)
We are seeing this same issue in our tenant. Users have signed in with their email address as recent as yesterday. Today they are getting the error message and are unable to sign in.
We narrowed the issue down to the MFA settings being migrated off of legacy to modern. After updating our conditional access policies to permit OTP for select users, they were able to sign in successfully.
You may want to review your MFA settings, and CA policies to make the necessary adjustments.
This behaviour is typically related to identity resolution during the authentication flow rather than the existence of the guest object itself in Microsoft Entra ID.
When a guest user receives a could not find account message while accessing a SharePoint site, the issue is usually caused by one of the following conditions.
First, validate how the guest object was created in Microsoft Entra ID.
Navigate to Entra ID Admin Center Go to Users Locate the affected guest user Confirm the following:
The User principal name follows the external format such as user_domain.com#EXT#@tenant.onmicrosoft.com
The Identities property contains the correct sign in address
If the guest object exists but the user signs in with a different email address than the one defined in the Identities attribute, Entra ID will not match the incoming token to the guest object.
This commonly occurs in the following scenarios:
The invitation was sent to ******@company.com
The user attempts to sign in using an alias such as ******@anotherdomain.com
The external organisation uses a different Entra tenant and the user selects the wrong account during authentication
Next, verify whether the guest user has redeemed the invitation.
Open the guest user object Review the External user state in Entra ID.
If the state is Pending acceptance, the invitation was not redeemed successfully. In this case:
Delete the existing guest object
Re invite the user using the correct external email address
Ensure the user accepts the invitation from the original email
Also verify the authentication method of the external identity.
Run the following using Microsoft Graph PowerShell:
Get-MgUser -UserId ******@yourtenant.onmicrosoft.com -Property Identities
Confirm that the Identities collection includes the correct sign in type, for example:
emailAddress for One Time Passcode
federated for Entra to Entra B2B
MicrosoftAccount for consumer accounts
If the Identities collection does not match how the user is attempting to authenticate, delete and recreate the guest object. Entra ID does not dynamically update the identity provider binding after creation.
Additionally, confirm that the SharePoint site permission is assigned to the correct guest object. It is possible that:
An old guest object exists
A duplicate guest object exists
Permissions are linked to a different objectId
You can validate this by running:
Get-MgUser -Filter "mail eq '******@company.com'"
If multiple results are returned, remove unused guest objects and reassign permissions to the correct object.
Finally, confirm that cross tenant access settings are not blocking authentication.
Go to External Identities Select Cross tenant access settings Review the inbound policy in Entra ID.
Ensure B2B collaboration is allowed for the partner tenant.
In most cases, the root cause is one of the following:
The guest signs in with a different identity than the one stored in the Identities attribute
The invitation was never redeemed
A duplicate guest object exists
The identity provider type does not match the authentication method
Correcting the guest identity binding and ensuring proper invitation redemption resolves the issue consistently.This behaviour is typically related to identity resolution during the authentication flow rather than the existence of the guest object itself in Microsoft Entra ID.
When a guest user receives a could not find account message while accessing a SharePoint site, the issue is usually caused by one of the following conditions.
First, validate how the guest object was created in Microsoft Entra ID.
Navigate to Entra ID Admin Center
Go to Users
Locate the affected guest user
Confirm the following:
User type is set to Guest
The User principal name follows the external format such as user_domain.com#EXT#@tenant.onmicrosoft.com
The Identities property contains the correct sign in address
If the guest object exists but the user signs in with a different email address than the one defined in the Identities attribute, Entra ID will not match the incoming token to the guest object.
This commonly occurs in the following scenarios:
The invitation was sent to ******@company.com
The user attempts to sign in using an alias such as ******@anotherdomain.com
The external organisation uses a different Entra tenant and the user selects the wrong account during authentication
Next, verify whether the guest user has redeemed the invitation.
In Entra ID:
Open the guest user object
Review the External user state
If the state is Pending acceptance, the invitation was not redeemed successfully. In this case:
Delete the existing guest object
Re invite the user using the correct external email address
Ensure the user accepts the invitation from the original email
Also verify the authentication method of the external identity.
Run the following using Microsoft Graph PowerShell:
Get-MgUser -UserId ******@yourtenant.onmicrosoft.com -Property Identities
Confirm that the Identities collection includes the correct sign in type, for example:
emailAddress for One Time Passcode
federated for Entra to Entra B2B
MicrosoftAccount for consumer accounts
If the Identities collection does not match how the user is attempting to authenticate, delete and recreate the guest object. Entra ID does not dynamically update the identity provider binding after creation.
Additionally, confirm that the SharePoint site permission is assigned to the correct guest object. It is possible that:
An old guest object exists
A duplicate guest object exists
Permissions are linked to a different objectId
You can validate this by running:
Get-MgUser -Filter "mail eq '******@company.com'"
If multiple results are returned, remove unused guest objects and reassign permissions to the correct object.
Finally, confirm that cross tenant access settings are not blocking authentication.
In Entra ID:
Go to External Identities
Select Cross tenant access settings
Review the inbound policy
Ensure B2B collaboration is allowed for the partner tenant.
In most cases, the root cause is one of the following:
The guest signs in with a different identity than the one stored in the Identities attribute
The invitation was never redeemed
A duplicate guest object exists
The identity provider type does not match the authentication method
Correcting the guest identity binding and ensuring proper invitation redemption resolves the issue consistently.
If this resolution has been helpful, I kindly request that you take a moment to click on
and select “Yes” to indicate that the response was helpful. Should you have any further questions or require additional assistance, please do not hesitate to let me know.
Thank you for the response
These guest users were previously able to access our sites without any issues, most of them using Gmail accounts. I tried deleting and re‑adding a few of the accounts, then sent a new invitation from the external Teams site, and that worked. However, we have many guest users, so deleting and recreating each one isn’t a practical solution. All of these users have been accessing the system with the same credentials for several years.
I also noticed a new issue with recreated guest users: they can access the external SharePoint site without any problems, but when they are added directly to external file share folders, they receive an “Access Denied” error. To work around this, I created a group in Entra ID, added the user to that group, and then granted the group access to the external file share folder—this worked. Why is there a difference now in how access is applied?
In Entra, all guest users with Gmail addresses are being identified as Microsoft Accounts, despite not having actual Microsoft Accounts. Should we therefore depend on Email OTP as their authentication method?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(233.6, 85%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVS%3C/text%3E%3C/svg%3E)
Tersilin Philip No, you should not depend on Email OTP for these Gmail guest users.
What you are seeing is expected behavior in Microsoft Entra ID. Even if users believe they do not have a Microsoft Account, Gmail addresses can be (and often are) registered as Microsoft Accounts, sometimes without the user realizing it. When Entra detects this, it automatically classifies the guest identity as MicrosoftAccount, and authentication will follow that method.
Email OTP is only used when no Microsoft Account or federated identity exists. Entra ID does not switch an existing guest from MicrosoftAccount to Email OTP, and doing so would require deleting and recreating the guest user—which is not recommended for long‑standing users.
Recommended approach:
Email OTP should only be used for new guest users who clearly do not have a Microsoft Account and where lightweight, passwordless access is required.
This approach ensures stability and avoids further access issues.