How Zitadel LDAP login lets directory users sign in to your applications
Zitadel documents LDAP and OpenLDAP as federated identity provider types, so your directory can keep verifying staff passwords while Zitadel issues the tokens your applications trust. Active Directory must be confirmed against the current Zitadel LDAP provider documentation before design starts, because supported bind methods, attribute names and account state handling should be checked for your Zitadel version rather than assumed from older guides. This page explains how the login flow works, which decisions to settle first and what changes for password policy and deprovisioning. It is written for identity architects, directory administrators and the platform engineers who will run the integration after go-live.
In this model, a user starts sign-in in Zitadel, is routed to the directory provider for the credential check, and returns to Zitadel with a verified identity. Zitadel then maps the directory attributes it receives onto a user record inside the relevant organization, creates that record on first sign-in if it does not yet exist, and issues OpenID Connect or SAML responses to the application. The first decision is which organization owns the directory connection. Zitadel places users and projects inside organizations within an instance, and each organization can use a different identity provider, so a single directory can be scoped to one workforce unit or one customer without exposing it to others. Record that mapping before building anything.
Password handling changes once the directory is the authority. Password rules, lockout behavior and expiry are enforced by Active Directory or OpenLDAP, not by Zitadel's own password settings for these users. Confirm with the current Zitadel documentation which login policy options still apply to directory-backed users, including whether passkeys can be offered and how fallback works. Deprovisioning needs the same care. Just-in-time creation does not remove a Zitadel user when the directory account is disabled or deleted, so you must confirm how and when directory state is re-checked, how existing sessions and grants are revoked, and who owns that process. Plan a test that disables a directory account and records what the application sees.
The remaining sections cover the directory bind account, attribute mapping, TLS for the connection and the operational checks for each phase. Keep scope clear: this integration handles sign-in and first-time user creation, and it does not bulk-load the directory into Zitadel in advance. If you also need lifecycle changes pushed from a source system, Zitadel's SCIM v2 interface is a separate design decision with its own mapping and ownership questions. Before you request a quote from DeployOpen, gather your directory type and version, the number of users and groups in scope, the applications that will trust Zitadel, and your current disablement procedure. Those inputs determine the design work that follows.
What you need in place before you connect Zitadel to your directory
Zitadel can authenticate users against Active Directory or OpenLDAP only after the database, network path, directory access and trust material are settled. The cards below cover what each team must confirm before the first bind test. Work through them in order, because the service account and certificate checks depend on the network path being open.
Supported Zitadel and PostgreSQL versions
Self-hosted Zitadel stores its data in PostgreSQL, and the supported range is PostgreSQL 14 through 18. Choose the PostgreSQL major version from that range before installation, then confirm that the Zitadel release you deploy lists it as supported. Record both versions in your change record, because a later upgrade of either one can change the login behavior you tested. Ask your database team who will own patching within the chosen major version.
Network path to the directory
Zitadel must reach the directory server over the LDAP port your team selects, whether that is the port for LDAP over TLS or another port your directory team approves. Open the path from every Zitadel node, including container or pod egress rules, to each domain controller or OpenLDAP server that will answer. Run the test from the Zitadel host itself, since firewall rules often differ between subnets. Ask whether the directory sits behind a load balancer, because that changes which address Zitadel must reach.
Read-only bind service account
Create a dedicated bind account in the directory with read access to the user search base and the attributes Zitadel maps, such as name, email and login name. Do not reuse a personal administrator account. Confirm that the account cannot write attributes or reset passwords, and record who owns its password rotation, since a failed bind stops every login. Keep the bind credentials in your secrets store, and make sure the rotation plan includes an update to the Zitadel configuration.
CA chain for the directory certificate
Zitadel validates the directory's TLS certificate against the trust store it runs with. Obtain the full chain from the directory team, including any intermediate CA, and confirm that it covers the host name your connection uses. Ask for the chain in the format your platform expects, and check that the certificate has not expired. Test with the same trust store your Zitadel hosts or containers use, because a chain that works on an administrator workstation can still fail inside the service.
Test organizational unit with non-production accounts
Create a test organizational unit or group in the directory that holds only non-production accounts. Include a user with a disabled or locked status if your policy checks those states, plus users with the attribute values you plan to map, such as a missing email address. Point the first Zitadel connection at this scope only. Keep production users out of the test scope until login, attribute mapping and deprovisioning behave as expected in your environment.
Confirm the release and LDAP provider settings
Before configuration, identify the exact Zitadel release you will deploy and read the LDAP identity provider settings in the documentation for that release. Field names, defaults and supported options can change between versions, so do not rely on older guides. Write down the release number, the documentation version you followed and every setting you changed from the default. Your team will need that record to repeat the setup during an upgrade.
Choosing between direct LDAP federation and a bridge directory
The decision is whether Zitadel should bind directly to an Active Directory domain controller or an OpenLDAP server, or whether a directory service should sit between them. Direct federation has fewer moving parts: Zitadel holds the bind account, reads users and authenticates them against the source of truth that already exists. A bridge directory is worth its added cost only when it provides a capability the source cannot offer on its own, such as Kerberos single sign-on for Linux hosts, issued certificates, host-based access policy or a trust with an AD forest. Start by listing the services that need those capabilities. If Zitadel is the only consumer, direct federation is usually the simpler design to test first.
FreeIPA is the bridge option most often considered in this setting. It combines the 389 Directory Server, an LDAPv3 directory that is multi-master and holds users, groups, hosts and policies, with an MIT Kerberos key distribution center for single sign-on, the Dogtag certificate authority and SSSD on clients. The FreeIPA Trusts documentation describes a cross-forest trust with Active Directory built on Samba components. That trust carries a hard constraint: the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Check the planned IPA domain name against every AD forest domain before installation, because the domain name is part of the design and the team should not discover the conflict during the build.
A FreeIPA bridge adds a system to operate. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, dedicated servers without other applications, and at least two DNS servers in each client's resolv.conf. The backup documentation notes that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. These are ongoing responsibilities for a platform or identity team, and they should be budgeted as recurring work rather than as a one-time install.
The Zitadel side of a FreeIPA design still needs confirmation. Before committing, ask the team to verify in a lab whether Zitadel's LDAP identity provider authenticates against the FreeIPA LDAP interface with the bind method and TLS settings you require, whether it maps the group and attribute values your roles depend on, and how accounts that use Kerberos or one-time passwords behave at a password-based login. Also confirm which of your applications actually need Kerberos or host policy. If none do, a bridge that exists only to front Zitadel is hard to justify. Record the decision, the test results and the owner of each system in writing before the build starts.
How to configure the Zitadel LDAP identity provider step by step
This sequence connects Zitadel to your directory in a controlled order, so each layer is verified before the next is added. It produces a tested LDAP login path that is enabled only for the organization that owns those users.
Confirm the directory endpoint and TLS mode
The directory and platform teams confirm the LDAP host name, port, and whether connections use LDAPS or StartTLS. They also confirm that the Zitadel host trusts the certificate chain presented by the directory, and ask which domain controllers or OpenLDAP replicas serve reads. Test a connection from the Zitadel host using the chosen mode. This step is done when the TLS handshake completes, the server certificate validates against your internal certificate authority bundle, and no plaintext fallback is allowed.
Create a bind account with minimal read rights
The directory administrator creates a dedicated service account that Zitadel uses only to search for users before a person authenticates. Grant read access to the user objects and the attributes the login flow needs, and withhold write access and group administration. Store the bind password in your secrets manager and limit who can read it. This step is done when a bind from the test host succeeds with that account and an attempted write is refused.
Set the user search base and filter
Define the directory subtree where login users live, and a filter that matches only enabled, login-capable accounts. Exclude service accounts, computer objects and disabled accounts, using the state flags your directory exposes. The filter must match the login attribute you plan to map in a later step. This step is done when an LDAP search from the test host returns one record for a known test user and returns nothing for an account outside the intended population.
Register the provider in its organization
In the Zitadel console, add an LDAP identity provider using the endpoint, TLS, bind and search settings from the earlier steps. Check the Zitadel documentation for your version to confirm whether providers are created at instance level or organization level, then register it in the organization that owns these users, because each organization can use a different identity provider. This step is done when the provider appears in that organization with the expected host and base settings, and saves without error.
Map the login attribute
Choose the directory attribute users type at sign-in, commonly a username or an email attribute, and map it to the Zitadel login name and profile fields. Decide whether the email address is used to match an existing Zitadel user and how unverified addresses are handled. Settle this before any user signs in, because changing the mapping later can leave duplicate or unlinked accounts. This step is done when a lookup by the chosen attribute returns the same Zitadel user identity on repeated attempts.
Test one account at a time
Start with a single test account in a non-production instance or a dedicated test organization. Sign in through the Zitadel login page with the directory password, and review the Zitadel logs for bind, search and authentication events. Then test a wrong password, a disabled account and a locked account, and record the message each one shows the user. Add a second account only after the first behaves consistently. This step is done when the test account signs in and is linked to the expected user, and each failure case produces the outcome your directory policy requires.
Enable the provider for the target organization
Make the LDAP provider available to the target organization and confirm that its login policy routes those users to it. Decide whether password login stays available as a fallback, and which other sign-in options remain for that organization. Confirm in the Zitadel documentation how existing sessions behave after a directory account is disabled, because that determines how quickly deprovisioning takes effect. This step is done when a pilot group signs in from the production login page through the directory, and users in other organizations keep their existing sign-in path.
Mapping directory attributes to Zitadel user fields
This table pairs each directory attribute concept with example attribute names in OpenLDAP and Active Directory and the Zitadel user field it would populate. Treat the example names as starting points to verify against your own schema, and confirm in the Zitadel release you deploy which attributes are read at login and which are ignored. The main takeaway is that login name, group membership and disabled state need the most checking, because they decide who can sign in and what they can do.
| Directory concept | Example attributes (OpenLDAP / Active Directory) | Zitadel user field | What to confirm |
|---|---|---|---|
| Login name | uid / sAMAccountName or userPrincipalName | Username used at login | Which attribute is the unique login name, and whether the same name can exist in more than one domain |
| mail / mail | Email address on the user | Whether the address is read at login, whether it is verified, and how changes in the directory propagate | |
| Given name | givenName / givenName | Profile given name | That the value is refreshed on later logins, not only when the user is first created |
| Family name | sn / sn | Profile family name | Whether the surname attribute is populated for all accounts, including service and shared accounts |
| Display name | cn or displayName / displayName | Profile display name | Whether Zitadel uses the directory value or derives its own, and how it appears in consoles and audit views |
| Group membership for role decisions | memberOf (overlay) or groupOfNames member / memberOf | Not a native user field; applied through project roles and grants | Whether group membership is read at login, how nested groups are handled, and what mapping logic your team must build |
| Account disabled state | Locked or shadow expiry attributes / userAccountControl disabled flag | Login blocked for the user | Whether a disabled directory account stops new logins only or also ends existing sessions, and how quickly that takes effect |
| Ignored attributes | Any attribute outside the mapping, such as photos or phone numbers | Not mapped | Which attributes the current release reads and which it ignores, so no one assumes a value is synced when it is not |
Just-in-time provisioning without a bulk sync
With just-in-time provisioning, Zitadel creates or links a user only when that person successfully authenticates against Active Directory or OpenLDAP through the LDAP identity provider. Nothing is loaded in advance, so the Zitadel user list fills in as people sign in. A directory account that has never logged in will not appear in Zitadel at all. Before go-live, confirm in your Zitadel version's LDAP provider settings whether automatic user creation is enabled, which organization receives the new user, and which directory attributes are copied into the profile at creation. Verify each answer on a test instance against a real test directory account instead of relying on the documentation alone.
The late appearance of users affects reporting and role grants. Any report built from Zitadel users counts only people who have logged in at least once, so comparing it with directory group membership will show gaps that are normal under this model. Grants are harder. A project role or user grant needs a Zitadel user record, so a grant made before first login either waits for the account or targets a construct that exists independently of the user. Confirm which grant types your version applies to users that do not yet exist, and test what happens to a grant when the first login creates the account. Plan the access model so that no one depends on a role that only takes effect after an unplanned first sign-in.
Duplicate accounts are the most likely defect in a JIT rollout. If an administrator created a local user, or a user already exists from an earlier identity provider or a test, the directory login may create a second record instead of linking to the first one. The result is stranded passkeys, grants and audit history on the wrong account. Find out which attribute Zitadel uses to match an incoming directory identity to an existing user, and whether it is a stable identifier such as the AD objectGUID or the OpenLDAP entryUUID or a mutable value such as email or login name. Test a sign-in for a user who already exists locally, and clean up duplicates before the first production login wave.
Just-in-time creation does not remove accounts, so it cannot drive deprovisioning on its own. If the directory must control when users are created and removed ahead of their first login, compare the LDAP path with SCIM v2, which Zitadel provides as a service provider interface for standardized user provisioning and lifecycle management. SCIM requires a provisioning client that pushes changes, such as an HR system or an identity governance tool, so it moves ownership of the lifecycle to that client. Decide before the build which system is authoritative for creation and removal, whether users must exist before first login, and how quickly a disabled directory account must lose access in Zitadel. Then test both models against the same scenarios.
Security settings for LDAP and Active Directory login
Connecting Zitadel to Active Directory or LDAP gives a new client access to your directory, so transport, credentials, network paths and data scope need to be set before any user signs in. The cards below cover the six controls we check first, in the order most teams apply them. Confirm each setting against the Zitadel release you deploy, because option names and defaults can change between versions.
Encrypted directory transport
Zitadel should reach the directory over LDAPS or StartTLS so that bind passwords and user attributes never cross the network in clear text. Use LDAPS where the directory listens on a dedicated secure port, and StartTLS where it accepts an upgrade on the standard port. Confirm in the current Zitadel documentation which TLS options the LDAP identity provider settings expose before you choose an approach.
Full certificate validation
Keep certificate checks enabled. The Zitadel runtime must trust the certificate authority that issued the directory certificate, and the certificate must match the hostname Zitadel connects to. Turning verification off to get a working connection hides man-in-the-middle exposure and often survives into production. Test with an expired certificate or one issued for another name, and confirm that the connection fails.
Least-privilege bind account
Create a dedicated bind account that can read only the attributes Zitadel maps, with no write rights and no group administration. Keep its password in a secrets store that your team already operates, and supply it to Zitadel at runtime so it stays out of configuration files and version control. Plan a rotation procedure and confirm that the account does not belong to an administrative group.
Restricted network paths
Allow traffic from Zitadel to the directory only on the ports the directory requires and only from the hosts or pods where Zitadel runs. Enforce this with firewall rules or security groups that deny other sources. In Kubernetes, express the restriction as a network policy so it persists through redeployments. Ask the directory team to confirm that no other client can reach the directory on those ports.
Scoped search base
Set the search base to the organizational units that hold people who need Zitadel access. A search base at the directory root lets the bind account enumerate service accounts, contractors and disabled identities. Ask the directory team to list the containers in scope, then test a lookup for a user outside them and confirm that it returns no result. Revisit the base whenever directory structure changes.
Failed bind and lookup logging
Record failed bind attempts, failed user lookups and TLS handshake errors from both Zitadel and the directory. Forward these events to the log platform your security team monitors, and set alerts for repeated failures against one account. Confirm which events each side logs by default, because directory audit logging is often disabled until someone enables it.
What changes for password policy and deprovisioning
For users who sign in through Active Directory or OpenLDAP, the directory checks the password, not Zitadel. Directory rules for lockout thresholds, password expiry, complexity and password history therefore apply to these users, and Zitadel's own password settings may not govern them at all. Before go-live, confirm this for the Zitadel release you plan to run. Test a wrong password until the directory locks the account, an expired password at login, and a password change initiated from the Zitadel login page. Record which system shows each message and which system enforces each rule.
The same test should cover self-service recovery. If a user forgets a directory password, Zitadel's reset flow may not change it, and the help desk or directory self-service portal may be the only path. Decide who owns that path, and make sure the login page does not send users to a reset form that cannot succeed. Also check any Zitadel password or passkey factor enrolled for a directory user. If a second factor or passkey can satisfy login without the directory password, the directory's policy is no longer the only control, and your access review needs to account for it.
Deprovisioning works differently. A disabled directory account stops new logins only if Zitadel checks the directory each time a user authenticates. Confirm this by disabling a test account and attempting a fresh login. Then check whether a session that was already open still works, because Zitadel sessions, access tokens, ID tokens and refresh tokens remain valid until their configured lifetimes end. Review those lifetimes for each application, record the values, and decide what a leaver can still reach during the longest remaining window.
Shorter token and session lifetimes reduce that window but increase re-authentication for users and load on the directory. Where the window is not acceptable, plan explicit revocation steps and consider SCIM v2 for lifecycle events. Confirm which revocation and session termination actions the release exposes, how an administrator triggers them, and whether a directory change reaches Zitadel automatically or only through a scheduled or manual process. Write a leaver runbook that names the owner for each step.
Effort depends on how many applications rely on this login, how many token lifetimes must be reviewed, and whether leavers are already removed by an HR-driven process. Ask any partner for a quote that itemizes the test matrix for lockout, expiry, recovery and deprovisioning, the lifetime review, the runbook, and any SCIM or revocation integration. Recurring work includes rechecking these behaviors after each Zitadel upgrade and after any change to directory policy.
Common Zitadel LDAP login failures and how to fix them
This table lists the login failures teams most often see when Zitadel authenticates users against Active Directory or OpenLDAP. Read each row by symptom, check the likely cause in the directory and in Zitadel's logs, then apply the fix in your own environment. Most failures trace back to the bind account, the TLS chain, the search base or the attribute mapping.
| Symptom | Likely cause | Fix and what to check |
|---|---|---|
| Bind fails with invalid credentials | The bind DN is wrong, the password was rotated or the account is locked or expired in the directory. | Confirm the bind DN format with your directory team and test it with an LDAP client from a host on the same network path. Check the account's lock and expiry state, then update the password in Zitadel's identity provider settings. Look for bind error entries in Zitadel's service logs at the time of the attempt. |
| LDAPS connection fails with a certificate trust error | The directory's certificate chain is incomplete, the hostname is not in the certificate, or the issuing CA is not trusted by the Zitadel runtime. | Retrieve the full chain from the domain controller and verify that the hostname you configured appears in the certificate. Add the internal root and intermediate CAs to the trust store used by the Zitadel container, pod or host. Repeat the test after restart, and confirm the TLS handshake error no longer appears in the logs. |
| User not found on login | The search base is too narrow, the user sits in an organizational unit outside it, or the filter excludes the account type. | Compare the search base with the user's distinguished name in the directory. Test the same filter with an LDAP search tool using the bind account. Widen the base only as far as needed, and check that service accounts and disabled objects are excluded by design rather than by accident. |
| User is found but the login name is rejected | The login name Zitadel uses does not match the attribute the directory stores for it, such as a UPN in one place and a short sAMAccountName in another. | Decide which attribute is the login identifier and confirm its values for a test user in the directory. Align the attribute mapping in Zitadel with that choice. Check the logs for the attribute name and value Zitadel received, since a mismatch usually shows there first. |
| Email or name fields are empty after login | The attribute mapping points to attribute names that the directory does not populate for that user, or the directory stores values in a different attribute. | List the populated attributes for a test user and compare them with the mapping. Correct the mapping for email, given name and family name, and mark fields as required only if your onboarding depends on them. Sign in again with a fresh test account, because values from an earlier login may persist on existing users. |
| Duplicate accounts appear after the first login | A local user or a user from another identity provider already holds the same email address, or the external identifier used to link the account changed. | Search Zitadel for users with the same email and compare their linked identity records. Decide in advance whether accounts should link automatically by email, and document that choice. Merge or remove duplicates through an administrator, and confirm that future logins link to one account. |
| Disabled directory users still sign in during an active session | Zitadel sessions and tokens stay valid until their lifetime ends, and a directory change does not end them automatically in every setup. | Confirm the session and token lifetimes configured in your instance, and shorten them where the risk requires it. Test by disabling a test account and checking whether an existing session still works. Add a documented step that revokes Zitadel sessions for a departing user, and confirm the behavior against your Zitadel version's documentation. |
| Login works for some users and fails for others in the same directory | Different users fall under different organizational units, account types or password states, so one search or policy path does not cover all of them. | Pick one failing and one working account and compare their directory attributes, group memberships and account flags. Adjust the search scope or filter to match the population you intend to allow, then test both accounts again. Keep a short list of test accounts for each directory segment you support. |
Questions buyers ask before connecting Zitadel to Active Directory
What drives the cost and effort of connecting Zitadel to Active Directory?
The main drivers are how many directories, forests and domains are involved, how cleanly user attributes map to Zitadel's model, and how much of the setting-up happens in your environment. Costs split into planning and design, configuration of the LDAP connection and attribute mapping, TLS and certificate work, testing with real accounts, and handover documentation. Some of this is one-time, while operational tasks such as rotating the bind account credential, reviewing certificates and handling changes to directory schema recur. Ask any partner for a written scope that lists each of these items, the systems in scope, and the test cases used to show that login, attribute mapping and deprovisioning behave as agreed. Confirm the supported settings in the Zitadel documentation before you estimate effort.
How long does an Active Directory login integration take to deliver?
The duration depends on the directory layout, the number of environments you need to test, and how quickly your teams can approve the bind account, TLS certificates and change windows. A single domain with a clear service account and a valid certificate chain is simpler than a multi-forest estate with several naming contexts. Scheduling is often the longest step, because directory and security reviews happen on their own cadence. No general duration applies to every organization, so ask for a timeline tied to specific milestones in the written scope, including who approves each step and what must be true before testing starts.
What does the integration need from our directory and security teams?
Your directory team needs to provide a dedicated, least-privilege bind account, the search base and organizational unit structure, the attributes that identify users and their group membership, and a decision on which account states should be allowed to sign in. Your security team needs to approve the TLS approach, including the certificate authority chain Zitadel will trust, how the bind credential is stored and rotated, network paths from the Zitadel hosts to the domain controllers, and logging of authentication events. Both teams should agree the password policy position in advance, because password changes, lockouts and multi-factor rules may remain in Active Directory rather than moving into Zitadel. Confirm the exact requirements against the Zitadel LDAP provider documentation.
Can our internal team connect Zitadel to Active Directory without a partner?
An experienced internal team can often do the work, provided it has people who know Zitadel's self-hosting and identity provider configuration, the directory administrators who can test the bind account, and a non-production environment to validate changes. Teams that lack one of these skills, or that must meet a tight audit or change calendar, commonly bring in a partner for design review or for the configuration and testing. Either way, the decision depends on skills and capacity rather than on whether the product supports the connection. Ask your internal team to list the Zitadel, directory, networking and security tasks and assign an owner to each before deciding.
Does Zitadel connect to Active Directory directly or through a bridge?
Zitadel documents LDAP and OpenLDAP as supported federation options, so an Active Directory domain controller can often be reached through the LDAP provider, but you should confirm the AD-specific settings in the Zitadel documentation and prove them in a test. If your directory is only reachable through another system, such as a FreeIPA server with a trust to Active Directory, that adds a component to build, patch and monitor. FreeIPA documents a cross-forest trust with Active Directory using Samba components and requires an IPA DNS domain that does not overlap with any domain in the AD forest. Whether a bridge is needed is a design decision you should make in the written scope, not after go-live.
How does LDAP login compare with SCIM for user lifecycle?
LDAP login checks credentials when a user signs in, and Zitadel can create or update a user at that moment, which is often described as just-in-time provisioning. That approach does not by itself remove accounts that are disabled in Active Directory or keep every attribute current between sign-ins. Zitadel also provides a SCIM v2 service provider interface for standardized provisioning and lifecycle management, which is the better fit when you need the identity source to push creates, updates and deactivations on a schedule. Many buyers use both, with login federation for authentication and SCIM for lifecycle. Confirm how deprovisioning, group changes and password policy behave in the Zitadel SCIM and identity provider documentation before you design the offboarding process.
How DeployOpen scopes and delivers Zitadel directory integration
DeployOpen plans and delivers Zitadel's LDAP and OpenLDAP login inside your own infrastructure, with the directory connection designed before any configuration starts. Each engagement is fixed-scope, with the directory settings, attribute mapping, provisioning approach and test cases agreed in writing first. We confirm which directory your identities live in before we set the connection, because the bind, attribute and password details depend on it.
How we scope
- The written scope names the directory type, each domain, base DN and user group that can sign in.
- Scope covers bind account settings, LDAP search filters, and whether Zitadel is the sign-in point for one or several organizations.
- Engagements are fixed-scope, and ongoing support after go-live can be added as a retainer.
How we build
- Configure TLS, a dedicated bind account and a tested search path before enabling user-facing login.
- Map directory attributes to Zitadel user fields, then test each mapping with sample accounts from every population.
- Choose provisioning with your team: just-in-time creation at first login, or SCIM v2 for lifecycle changes.
How we hand over
- Deliver the configuration, runbook and test records, with each setting explained against the directory it connects to.
- Document who owns password policy and deprovisioning, and confirm how Zitadel reflects directory changes for each.
- Walk your operations team through the disable, removal and reconnect steps they will run during staff changes.
How we support
- Support can run as a retainer covering Zitadel upgrades, directory changes and login incidents in your environment.
- Re-test the LDAP path after each Zitadel upgrade or directory schema change, before the change reaches production.
- Review the connection's TLS certificates, bind credentials and PostgreSQL backups on the schedule agreed in your scope.
