authentik and Microsoft Entra ID provisioning

How authentik provisions users and groups into Entra ID

If you run authentik for sign-in and need Entra ID to show the same people and groups without manual copying, the Entra ID provider in authentik's Enterprise edition is the component that pushes those identities outward. It is a provisioning flow, not a sign-in flow: users still authenticate against authentik, and the provider only creates, updates and removes accounts and group memberships in your Entra ID tenant. Treat authentik as the source of truth. Anything you change by hand in Entra ID for a provisioned object is a drift that the next sync can overwrite, so agree on that rule with the identity and Microsoft 365 owners before the first run. The authentik pricing page lists the Entra ID integration among its Enterprise-only features, so budget for that edition from the start. The code in the authentik/enterprise/ directory sits under its own license, which the authentik LICENSE file on GitHub describes, so have legal confirm that terms fit your use before you deploy it.

The provider works through a Microsoft Entra ID application registration that grants authentik permission to write to your tenant. Confirm with your Entra ID administrator which app registration, client credentials and directory scope will be used, who owns the secret and when it expires, and whether a dedicated service principal is acceptable under your change control. In authentik, the provider is paired with an application and a property mapping set that decides which attributes leave authentik, such as userPrincipalName and display name. Decide early which identifier is the stable key for matching, because the mapping determines whether an existing Entra ID account is adopted or a duplicate is created. Map every attribute you intend to push and document the owner of each mapping, since those mappings define your provisioning contract.

What you need before connecting authentik to Entra ID

Entra ID provisioning depends on four things being in place before any configuration starts: a supported authentik release, an Enterprise license, a tenant that lets your team register an application, and network paths from the authentik worker to Microsoft. Each card below is a checkpoint to close with your identity and platform owners before the provider is created.

Supported authentik release line

Confirm that the authentik deployment runs on a line the security policy lists as receiving security fixes, which is 2026.5.x or 2026.8.x. Check the running version in the admin interface rather than the version in the deployment file, because a chart or Compose tag can lag behind what is actually running. Plan the upgrade path first if the deployment sits on an older line, since the Entra ID provider should be configured on the release you intend to keep.

Enterprise license for the Entra ID provider

The Microsoft Entra ID integration is listed as an Enterprise-only feature, and the code for it sits under the separate enterprise license in the repository. Confirm with your authentik account contact which license tier covers the provider and how seats are counted for your user population, including external users. Ask for the license terms in writing before you build a sync that depends on them.

Entra ID tenant and application registration rights

Someone with rights to register an application in the target Entra ID tenant must be available for the whole setup, and that person must be able to grant the directory permissions the provider requests. Confirm whether your tenant policy requires administrator consent for those permissions and who can give it. Record the tenant ID, the application ID and the consent owner before work starts, because a consent request that waits on an absent approver is a common cause of delay.

Exact permissions and consent steps

This page does not list the Graph permissions or the consent sequence the provider needs. Read the current authentik Entra ID provider documentation and compare it with your tenant's conditional access and app consent policies. Write down each permission, why it is requested and who approved it. Treat any permission the documentation does not state as a question to resolve with the vendor, not an assumption.

Outbound access from the worker

Provisioning runs from the authentik worker container, not from the server container, so the network rule that matters is the worker's outbound path to Microsoft identity and Graph endpoints. Confirm that egress firewalls, proxies and DNS in your network allow those endpoints from the worker's subnet or node pool. In Kubernetes, check the egress policy on the worker's namespace. Test this path before the first sync, because a blocked call often appears only as failed tasks in the worker logs.

Worker capacity and PostgreSQL headroom

The worker runs background tasks, including provisioning, so a provider that syncs many users competes with login traffic for the same resources. Check that the worker has enough CPU and memory for your user count, and that PostgreSQL can absorb the extra connections that come with the 2025.10 change away from Redis. Ask your team to review worker sizing and database connection limits together, since both affect how quickly a sync completes.

Configuring the Entra ID provider in authentik

This sequence connects authentik to one Entra ID tenant through the Enterprise provider, scopes which groups leave authentik, and confirms with a test user and group that the tenant receives the expected objects before wider rollout.

Confirm the Enterprise license and version
The platform owner confirms that the authentik instance carries an Enterprise license, since the Microsoft Entra ID integration is listed as an Enterprise-only feature on the pricing page. Record the running version and check it against the supported releases in the security policy, so the provider configuration matches the release in production. Confirm the license covers the instance you will change, not a test instance. The step is done when the admin interface shows the Enterprise provider types and the version is recorded in your change ticket.
Register the application in the Entra tenant
A Microsoft Entra administrator creates an app registration in the target tenant and grants it the directory permissions needed to read and write users and groups. Record the tenant ID, the application (client) ID, and the client secret or certificate the provider will use, and store the secret in your vault rather than in a ticket. Confirm the exact permission names and consent steps in the current Microsoft documentation for your tenant, because the sets change over time. The step is done when the registration shows admin consent granted and the identifiers are recorded for the next step.
Create the Entra ID provider in authentik
An authentik administrator creates an Entra ID provider in the admin interface and enters the tenant ID, client ID and credential from the app registration. Leave the provider unattached at this point so no users are pushed yet. Save the provider and open it again to confirm the values were stored and the connection test, if the interface offers one, reports success. The step is done when the provider exists with the expected tenant identifier and no connection errors appear in the system logs.
Attach the provider to the source application
The administrator links the provider to the application or sources whose users should appear in Entra ID, so authentik knows which accounts are candidates for provisioning. Users outside those sources are not sent to the tenant. Review the property mappings attached to the provider and confirm that the attribute names for user principal name, display name and mail match what your Entra tenant expects. The step is done when the provider page lists the attached sources and the mappings show the intended attribute values for a sample user.
Define which groups are in scope
Choose the authentik groups that should exist in Entra ID and exclude groups used only inside authentik, such as break-glass or internal administrator groups. Decide how service accounts are filtered, for example by a dedicated group, an attribute or a naming convention, and write that rule down before the first sync. Confirm with the identity team which group names are authoritative in both systems. The step is done when a written list of in-scope groups exists and a test user inside one of them is the only account the provider would send.
Run one sync against a test user and group
Create a test user and a test group in authentik, add the user to the group, and run a single synchronization of the provider. Watch the task output in the worker logs or the sync status page until it reports completion or an error. Avoid running a full sync across all groups for the first pass. The step is done when the sync task finishes without errors and the log records the test objects as created or updated.
Verify the result in the Entra admin center
Open the Microsoft Entra admin center and search for the test user and test group. Check that the user's display name, user principal name and mail attributes match the values in authentik, and that the group membership reflects the single test assignment. Also check that no unintended accounts were created. Record the result and the sync task identifier. Confirm the deletion and suspension behavior with the provider documentation before any user is removed from authentik. The step is done when the tenant shows the expected user and group with correct attributes and nothing else changed.

Matching existing Entra ID accounts to authentik identities

This table compares the authentik user and group fields you map to Entra ID properties, the match key that links a pre-existing Entra account to an authentik user, and the decisions to make when a match is missing or ambiguous. Read each row as a decision to record before the first sync, and confirm every mapped attribute against the Enterprise Entra ID provider's current field list in your authentik version.

Item	What to decide	Risk if left open	Check before first sync
Username to userPrincipalName	Whether authentik username maps to the Entra user principal name or to mailNickname	Duplicate accounts when the UPN and username format differ	Confirm the mapped attribute in the provider's current field list
Email to mail	Which email attribute is authoritative and whether it may change	Accounts matched on a stale or alias address	Compare authentik email values with Entra mail for a sample of users
Display name to displayName	Whether authentik name fields or a combined name feed displayName	Name drift that confuses reviewers, not an access issue	Confirm the name property mappings the provider offers
Groups to Entra groups	Which authentik groups are pushed and whether group names or IDs are the key	Groups created with unexpected names or memberships left behind	Confirm group object fields and filter behavior in your version
Active state to accountEnabled	How authentik inactive users map to a disabled Entra account	Users who should be off still able to sign in to Entra-backed apps	Test one deactivated user and confirm the account is disabled, not deleted
Match key for existing accounts	Choose one key, such as UPN or email, and use it consistently	Silent duplicates or unintended takeover of an existing account	Run a dry review of matches on a copy of the tenant user list
Missing match	Whether authentik creates a new Entra account or leaves the user unlinked	Parallel accounts with different licenses or roles	Agree the create-or-skip rule in writing with the Entra admin team
Ambiguous match	Who resolves two Entra accounts matching one authentik user	Wrong account receives group memberships or access	Define a manual review step and an owner for exceptions
Service and shared accounts	Whether service accounts are excluded by filter or by attribute	Service identities provisioned into Entra with interactive rights	Confirm the filter option and test with a tagged test account

How sync timing and deletion behave in each situation

When a user or group is created in authentik and falls within the provider's scope, the Enterprise Entra ID provider is expected to create a matching object in the target tenant on its next sync. Before that first push, the admin decides whether the provider should link to an existing Entra ID account with the same identifier or create a new one, since a new object alongside an existing account is a common source of duplicate identities. The first sync is also the point where property mappings determine what the Entra ID object looks like.

Matching rules: Confirm which attribute the provider uses to match existing Entra ID accounts, and test a case where the account already exists.
Property mappings: Check that the user principal name, display name and mail values are populated the way your tenant expects.
Group creation: Confirm whether groups are created as separate objects and whether members are added in the same run as the group.
Sync trigger: Confirm whether the push runs on a schedule, on save, or both in your authentik version.
Test case: Create one user and one group in authentik, then confirm the objects, their identifiers and memberships in the test tenant.

Confirm exact sync intervals and matching behavior in the Entra ID provider settings and documentation for the authentik version you run.

Filtering service accounts before they reach Entra ID

Service accounts and break-glass accounts usually should not be provisioned into an Entra ID tenant at all. Accounts used by scripts, integrations and automation rarely have a named human owner, and break-glass accounts exist to sign in when federated sign-in is unavailable. If authentik pushes these identities into Entra ID, a failure in the sync path or in the cloud tenant can remove the access you rely on in an emergency. Decide the population before you configure the Enterprise Entra ID provider: list every account type in authentik that must stay local, name an owner for each category, and record that decision alongside the provider configuration so reviewers can trace it later.

Scope the provider so only intended identities are pushed. In authentik, the usual levers are the groups or attributes the provider's sync scope is built from, and the property mappings that decide what each pushed object carries. Confirm the exact filter options available in your authentik release and in its Entra ID provider documentation before you design around them, and prefer a dedicated group that represents "synced to Entra ID" membership so the rule is visible to administrators. Do not rely on naming conventions alone, because a renamed account can slip into scope without anyone noticing.

A filter change can orphan accounts that were already provisioned. When an identity drops out of scope, the tenant copy may be left in place, disabled or removed depending on how the provider's deletion behavior is configured, so review that behavior before any change. Build a copy of the intended scope in a test tenant or with a representative subset of users, apply the new filter, and compare the resulting objects against the expected list before touching production. Keep a record of current membership, and plan a rollback path for groups that were removed by mistake.

Securing the provisioning path

The Enterprise Entra ID provider gives authentik write access to a production directory, so the connection deserves the same care as the identity source itself. The cards below cover the Entra application, its credentials, who can change provider settings in authentik, the logs that record changes, and the worker and database that hold the configuration.

Dedicated Entra application

Create a separate app registration for authentik provisioning rather than reusing a sign-in application or an administrator's account. Grant only the directory permissions the provider needs to create, update and disable users and manage the groups it owns, and confirm the exact permission set with the provider documentation before consent. Review the consent grant after each authentik upgrade, because new provider behavior can require different permissions.

Credential type and rotation

Confirm which credential type the Enterprise Entra ID provider accepts in your version, whether a client secret, a certificate or another method, and store it only in authentik's configuration path that your team controls. Set an expiry date on the credential in Entra, record the owner, and schedule rotation before expiry so provisioning does not stop silently. Rotation should be tested in a staging tenant first.

Restricting provider edits in authentik

Provider settings decide which Entra objects authentik can change, so editing them is an administrative action. Limit the authentik roles that can create or modify Entra ID providers, property mappings and the sync scope to a small named group. Keep the service account that runs provisioning out of the administrator group, and review membership of both groups on a fixed schedule.

Audit logging on provider changes

Enhanced audit logging is an Enterprise feature, so confirm it is in your subscription before relying on it for provider changes. Ask which events record creation, edits and deletion of the Entra provider, its mappings and its bindings, and where those events are forwarded. Without a record of who changed the filter or the mappings, a later deletion event in Entra is hard to explain.

Protecting the worker and database

The worker container runs background tasks, including provider sync jobs, and PostgreSQL stores all authentik configuration, including the Entra provider settings. Restrict network access to both to the authentik components that need them, keep database backups encrypted, and limit who can reach the worker host. Treat a compromise of either as a compromise of the directory credential.

Reviewing Entra provisioning logs

Check the provisioning and audit logs in Entra ID on a regular schedule for changes made by the authentik application. Look for unexpected user creation, group membership changes, disabled accounts and failed provisioning attempts, and compare them against authentik's own sync history. Agree in advance who receives alerts and what volume of changes counts as unusual for your tenant.

Common Entra ID provisioning failures and fixes

This table pairs common Entra ID provisioning symptoms with their likely causes and fixes in an authentik deployment. Start with the authentik worker logs and the Entra provisioning logs, since most failures show a clear error there before they show up as user complaints. Work down the rows in order of how often each cause appears in practice.

Symptom	Likely cause	First checks and fix
Provisioning never starts	The Enterprise license is not active, or the Entra ID provider is not attached to the application or the sync is not enabled	Confirm the Enterprise license is active and the provider is bound to the application. Then check the worker container logs for task errors and the Entra provisioning logs for a job that never ran.
Duplicate users appear in Entra ID	The matching key differs between authentik and the existing Entra accounts, such as UPN versus email or a different object identifier	Compare the identifier authentik sends with the one already on the Entra user. Align the property mapping and matching attribute before the first full sync, and clean up duplicates in Entra ID deliberately.
Groups exist but have no members	Member users were not in scope when the group was synced, or the group was synced before its users existed in Entra ID	Confirm both the users and the groups are assigned to the application and included in the sync scope. Trigger a full sync after correcting assignments, then check the Entra provisioning logs for skipped group members.
Users deactivated after a filter or scope change	A narrowed filter or changed group scope removed users from sync, and Entra ID disabled accounts that fell out of scope	Review the filter and group scope change in authentik and the deprovisioning settings in Entra ID before saving. Restore the previous filter if needed, and confirm which accounts were affected in the provisioning logs.
Permission errors from the Entra tenant	The app registration or service principal lacks the directory permissions or admin consent that provisioning requires	Check the app registration's granted permissions and admin consent in the Entra admin center, and confirm the tenant URL and credentials in the authentik provider. Re-test the connection after any change.
Changes lag after an upgrade	A new authentik release changed behavior, or the worker was not restarted or updated, so queued tasks did not run	Confirm the server and worker containers run the same version, check the release notes for provisioning changes, and review worker logs for failed or retried tasks. Trigger a sync manually to confirm recovery.

Questions teams ask before connecting authentik to Entra ID

Does the authentik Entra ID provider require an Enterprise license?

Yes. According to the authentik pricing page, Microsoft Entra ID integrations are an Enterprise-only feature, so the Entra ID provider is not part of the Open Source edition. The Enterprise edition is listed there at $5 per user per month billed annually, plus $0.02 per external user per month. Confirm the current terms with authentik before budgeting, because the license is separate from the implementation work. Code in the authentik/enterprise/ directory falls under its own enterprise license, which your legal or procurement team should review alongside the pricing terms.

What work is involved in syncing users and groups to Entra ID?

The work covers configuring the Enterprise Entra ID provider, deciding which authentik users and groups should exist in the tenant, matching accounts that already exist in Entra ID, designing filters that exclude service accounts and out-of-scope groups, and testing the sync before it touches production. Effort is driven by the number of tenants, the number of groups and the depth of nested membership, how many existing Entra ID accounts need matching, how complex the filter and property mapping logic is, and how much testing your change process requires. A fixed-scope agreement lists each of these items so the quote can be compared against your own estimate.

Can our own team set up the Entra ID provisioning without a partner?

Yes, if your team has administration skills in both Microsoft Entra ID and authentik. The work requires knowledge of Entra ID app registrations, permissions and tenant policies, along with authentik providers, property mappings, sources and the sync behavior of the Enterprise provider. Teams without experience in one of the two systems usually spend most of their time learning rather than configuring, so a short review of the design before go-live is a common middle option. Decide early who owns the Entra ID side, who owns the authentik side, and who signs off on the group model.

What does DeployOpen need from our team to start?

DeployOpen needs access to the Entra ID tenant with rights sufficient to create and test the provisioning application, and access to the authentik instance with administrative rights to configure the provider. A test tenant or a clearly separated pilot group is strongly recommended so that sync behavior can be verified without affecting production users. You also need named owners for the groups that will be provisioned, for the filters that decide which accounts are in scope, and for the decision on how deletions and suspensions should be handled. Confirm these owners and access paths in writing before work starts.

What determines the quote for an Entra ID provisioning engagement?

A quote follows from the written scope. The main inputs are the number of Entra ID tenants, the number of authentik applications or groups that will feed into them, how many existing accounts require matching and reconciliation, the complexity of filters and attribute mappings, and the testing requirements, including whether you need a test tenant, a pilot phase or documented test evidence for an internal review. Ask for the quote to separate one-time design and build work from any recurring support or retainer, and ask what is excluded, such as Entra ID licensing or changes to downstream applications.

What should we check about deletion and service accounts before go-live?

Check how the provider treats users removed from authentik and whether deletion or deactivation is the desired outcome in Entra ID, since reversing a deletion can affect licenses, group memberships and sign-in history. Confirm which accounts are filtered out, including service accounts, break-glass accounts and test users, and verify that the filter matches what your directory actually contains. Test with a small set of accounts first, and record the results so an internal or external reviewer can see how the behavior was verified. Confirm the exact behavior with authentik documentation for the version you run, because the provider's options can change between releases.

Scoping this integration with DeployOpen

DeployOpen plans and implements the authentik to Microsoft Entra ID provisioning setup inside your own infrastructure and your own Entra ID tenant. That covers the authentik side of the work (the Enterprise Entra ID provider, its property mappings and group filters, and the service accounts and application registration that authentik uses to write to the tenant) and the Entra ID side (the enterprise application, its permissions, and the assignment rules that determine who is provisioned). The work runs in your accounts and under your change control, so the people who approve tenant changes stay in the loop for every step. Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. A useful first step is to write down which users and groups must reach Entra ID, which must never leave authentik, and who owns each decision about deletion and filtering, because those answers define the statement of work.

DeployOpen does not issue audit reports, attestations or certifications for the controls this setup produces. Provisioning changes which accounts exist in Entra ID, how long they remain there, and which privileges they inherit, so your auditors or assessors will want evidence that the configuration matches your access policy. DeployOpen can prepare that evidence as part of the delivery, including configuration exports, a record of the matching and filtering rules, and test results for joiner, mover and leaver cases. An independent auditor or certification body then evaluates those controls and decides what they conclude. Before you request a quote, confirm with your assessor which evidence they expect, and ask the implementation partner to list the artifacts it will hand over.

How DeployOpen delivers and supports authentik provisioning

DeployOpen plans, implements, documents and supports self-hosted open-source platforms in infrastructure you control, and authentik provisioning into Microsoft Entra ID follows the same method. We start from written scope, build the Enterprise Entra ID provider against a tenant you designate, and hand over the configuration, runbooks and test evidence your team needs to operate it.

How we scope

Confirm which authentik groups and users are in the sync, and which are excluded such as service accounts.
Document the matching rule for existing Entra ID accounts and who approves it before any write happens.
Agree in writing the deletion behavior, sync timing expectations and the Entra ID tenant and permissions involved.

How we build

Configure the Enterprise Entra ID provider and property mappings in a non-production tenant first.
Test matching, group membership changes, suspension and deletion cases with named sample accounts.
Confirm the Enterprise license requirement for the Entra ID integration with your authentik edition before build starts.

How we hand over

Deliver a written configuration record covering mappings, filters, sync settings and the service account used.
Provide a runbook for diagnosing failed pushes, mismatched accounts and unexpected deletions.
Walk your identity and Entra ID administrators through the test results and the rollback steps.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover authentik version upgrades, provider changes and re-testing after Entra ID tenant changes.