Here’s a practical way to troubleshoot Azure AD (Microsoft Entra ID) users not being provisioned. The exact steps depend on whether you mean:

• User sync from on-prem AD to Entra ID via Azure AD Connect / Cloud Sync, or
• User provisioning into an app/SaaS using Entra ID provisioning.

I’ll cover the most common checks for both.

---

1) Identify where provisioning is failing

First, confirm the direction:

• On-prem AD → Entra ID: users are not appearing in Microsoft Entra ID
• Entra ID → SaaS app: users exist in Entra ID but are not being created in the target app

This matters because the logs and tools are different.

---

2) Check the provisioning status in Entra ID

Go to:

Microsoft Entra admin center → Identity → Monitoring & health

For app provisioning:

• Enterprise applications
• Select the app
• Provisioning
• Check:
  • Provisioning status = On
  • Scope (sync only assigned users vs all users)
  • Last sync time
  • Provisioning logs

For directory sync:

• Check if DirSync / sync is healthy
• Review Synchronization status if you use Azure AD Connect / Cloud Sync

---

3) Review provisioning logs

This is usually the fastest way to find the cause.

In Entra admin center:

• Identity → Monitoring & health → Provisioning logs

Look for:

• Skipped
• Failure
• Quarantine
• Duplicate
• Attribute mapping issues
• Permission / authorization failures

Open a failed record and note:

• Error code
• Failure reason
• Source object
• Target object
• Attribute causing issue

---

4) Verify the user is in scope

A very common issue is that the user is not actually included in the provisioning assignment.

For app provisioning:

Check:

• The user is assigned to the enterprise app if scope is “assigned users only”
• The user is in a group assigned to the app
• The provisioning scope includes the OU/group where the user lives

For AD sync:

Check:

• The user is in a synced OU
• The user is not excluded by filtering rules
• The user is not blocked by admin or attribute-based filtering

---

5) Check attribute mapping and source data

Provisioning often fails because required attributes are missing or invalid.

Look for:

• UPN missing or malformed
• Duplicate proxyAddresses
• Invalid mail
• Missing displayName
• Missing unique identifier
• Bad characters in attributes
• Length limits exceeded

If you use app provisioning, review the attribute mapping in the enterprise app and ensure required source attributes exist.

---

6) Check for duplicates / matching conflicts

Provisioning can stop if Azure AD or the app finds an existing conflicting account.

Typical causes:

• Same UPN already exists
• Same email address already exists
• Matching rules are linking to the wrong user
• Duplicate accounts in the target app

Check:

• Whether the user already exists in Entra ID
• Whether an object already exists in the target app
• Whether soft-match/hard-match is interfering

---

7) Confirm licensing and feature requirements

Some provisioning scenarios require:

• Specific Entra ID / P1 / P2 licensing
• The app provisioning feature to be enabled
• Azure AD Connect or Cloud Sync configured correctly

For app provisioning:

• Make sure the app supports automatic provisioning
• Ensure the service account has required permissions

---

8) Review permissions and credentials

Provisioning failures often happen if the connector account lost permissions or its password/token expired.

Check:

• Connector/service account credentials are valid
• API token or SCIM credentials are current
• The app connector still has rights to create/update users
• Admin consent hasn’t been revoked

---

9) Check synchronization health

If using Azure AD Connect / Cloud Sync:

On the sync server:

• Verify the sync service is running
• Check Synchronization Service Manager
• Review export/import errors
• Confirm the scheduler is enabled
• Look for connectivity or authentication issues

Common Azure AD Connect issues:

• Password hash sync disabled
• Staging mode enabled unintentionally
• OU filtering excludes the user
• A synchronization rule blocks the object
• Export errors due to duplicate attributes

---

10) Look for quarantine or throttling

If the provisioning service detects repeated failures, it may place the job in quarantine.

Check:

• Provisioning status = Quarantined
• Recent high failure rates
• API throttling from the target app

If quarantined:

• Fix the underlying issue
• Restart provisioning
• Wait for the next cycle or manually restart it

---

11) Use targeted tests

Try a single known-good user to narrow it down:

• Create a test user with simple attributes
• Assign them to the app/group
• Force a sync/provisioning cycle
• See whether the issue is user-specific or systemic

If the test user works, the problem is likely:

• Attribute data
• Matching conflict
• Scope/filtering issue

---

12) Check audit logs and service health

Also review:

• Audit logs
• Service health in Microsoft 365 admin center
• Azure / Entra incident messages

Sometimes the problem is due to:

• Microsoft service incident
• Tenant-level configuration issue
• API outage in the target SaaS app

---

Quick checklist

If users aren’t provisioning, verify:

• Provisioning is turned on
• User is in scope / assigned
• No attribute errors
• No duplicate/conflicting account
• Connector credentials are valid
• Logs show the real failure reason
• Sync service is healthy
• No quarantine/throttling

---

If you want the fastest path

Send me:

1. Whether this is AD Connect / Cloud Sync or app provisioning
2. The exact error message from provisioning logs
3. Whether the user is in scope/assigned
4. The target app name, if applicable

I can help you narrow it down step by step.