Overview

If a user can sign in successfully but cannot open the file, site, mailbox, application, folder, or other resource they need, authentication is working but authorization may not be. Focus on the exact resource, signed-in identity, license or service assignment, group membership, permission path, and any conditional access applied to that resource.

Authentication is not authorizationA successful sign-in only proves the identity was accepted. It does not prove the user has permission or a license for every resource.

Why this happens

The user may be signed into the wrong account, missing a required license, excluded from a group, assigned the wrong role, blocked by a resource-specific policy, using an expired guest account, or attempting to open a resource whose permissions changed.

Before you begin

  • Identify the exact resource URL, application, mailbox, folder, or file.
  • Record the exact access-denied or permission message.
  • Confirm whether another user with the same approved role can access the resource.
  • Do not grant broad permissions simply to test access.

Click-by-click troubleshooting

Step 1: Confirm the exact signed-in identity

Action: In the affected service, select the profile icon and confirm the exact work email address. If account confusion is possible, open a private browser window and sign in only with the intended work account.

Why this matters: Personal accounts, guest identities, old work accounts, and cached sessions can authenticate successfully but lack access to the intended resource.

What to look for: Confirm the expected username, organization, and tenant or domain.

Expected result: The user should be signed in with the exact identity that is supposed to receive access.

Step 2: Open the resource directly in the web service

Action: Use the authoritative resource URL in a browser instead of Recent files, desktop shortcuts, or synchronized folders. Examples include the SharePoint site, Microsoft 365 web app, Google Drive, Shared Drive, or application web portal.

Why this matters: Direct browser access removes stale shortcuts and local sync state from the test.

What to look for: Record Access denied, Request access, license-required, not found, forbidden, or other resource-specific messages.

Expected result: You should have a direct authorization result from the system that owns the resource.

Step 3: Verify license or service assignment when the resource requires one

Action: If you are an authorized administrator, open the appropriate administration console and verify that the user has the required license or service assignment. In Microsoft 365 Admin Center, open Users > Active users, select the user, and review Licenses and apps.

Why this matters: A user can sign into Microsoft 365 while still lacking the service plan required for a specific application or feature.

What to look for: Look for an unassigned license, disabled service plan, expired subscription, or mismatch between the resource and assigned product.

Expected result: The user should have the approved license and service needed for the resource.

Step 4: Determine how access is supposed to be granted

Action: Identify whether the resource grants access directly, through a Microsoft 365 group, SharePoint group, security group, Google Group, Shared Drive role, application role, or another controlled access group.

Why this matters: Troubleshooting individual permissions is unreliable when the organization intentionally manages access through groups.

What to look for: Compare the affected user with a working user who has the same approved business role. Identify the group or role difference.

Expected result: You should know the intended access path before changing membership or permissions.

Step 5: Verify group membership or resource permissions

Action: If authorized, review the user in the controlling group or resource permissions. In SharePoint, use Settings > Site permissions or Manage access. In Google Drive or a Shared Drive, use Share or Manage members. In other applications, use the application's approved role-management page.

Why this matters: Missing membership, wrong role, broken inheritance, or access granted to a different identity are common reasons a signed-in user is denied.

What to look for: Look for missing membership, incorrect role, expired guest access, or a permission entry tied to another account.

Expected result: The user's approved role should map to the expected resource access.

Step 6: Check whether the problem is only local

Action: If browser access works but the desktop application, mapped drive, or sync client fails, sign out and back into the affected application and verify its account. Review sync or application status before changing permissions again.

Why this matters: A healthy browser authorization result proves the server-side permission is working and redirects troubleshooting to the client.

What to look for: Look for an old account, stale token, disconnected sync client, or local shortcut pointing to the wrong resource.

Expected result: Client access should use the same authorized identity and resource path that worked in the browser.

What to look for

  • Wrong signed-in account: correct identity before changing permissions.
  • Missing license or disabled service plan: authorization depends on licensing.
  • Working user belongs to a group the affected user does not: validate approved membership.
  • Browser works but desktop app fails: client/session problem, not server permission.
  • Guest or external user access expired: review external-access policy and business need.

When to stop

Do not over-permission the resourceStop before granting Everyone, organization-wide, owner, administrator, or broad sharing access merely to make the error disappear.

When to contact IT

Contact IT if the correct access path is unclear, a group or role change requires approval, the resource contains sensitive data, licensing is uncertain, or the user remains denied after identity and approved permissions are confirmed. Provide the user, resource URL, exact error, required business role, and comparison-user findings.

Need help with this issue?

J3 Systems Group supports small businesses and nonprofits with Microsoft 365, Google Workspace, cybersecurity, devices, documentation, and day-to-day IT operations.

Contact J3 Systems Group

Authoritative references

Vendor interfaces, licensing, and security guidance can change. Verify current platform behavior against the primary documentation below before making high-impact production changes.

Article KB-13.005 · Review after material vendor, licensing, interface, security, or service changes.