How Airflow 3 signs users in against Active Directory or OpenLDAP
If your organization already runs Active Directory or OpenLDAP, Airflow 3 can authenticate users against that directory, but only through the FAB auth manager. Airflow 3 defaults to the Simple auth manager, and only one auth manager can be active at a time, set by the auth_manager option. Choosing LDAP therefore means setting Airflow to the FAB provider and configuring LDAP in webserver_config.py. The directory answers two questions: who the user is at sign-in (authentication), and which Airflow roles that user holds (authorization, once group-to-role mapping is in place). Your team should decide early whether directory groups will drive roles, because that choice shapes the rest of the configuration.
Active Directory Domain Services and OpenLDAP both speak LDAP, so the same general login pattern applies to both, although the attribute names, group structures and bind accounts will differ between them. Active Directory is a Windows Server role that replicates directory data to every domain controller in a domain, and Microsoft notes that most on-premises applications authenticate against it with LDAP, Windows-integrated authentication or header-based authentication. Sign-in to SaaS-style applications takes a different path. Microsoft describes AD FS as the federation system that Active Directory needs for SaaS apps, and Microsoft Entra ID as the cloud identity service that existing Active Directory estates sync to with Microsoft Entra Connect. If your Airflow sign-in must go through AD FS or Entra ID, the LDAP approach in this section is the wrong starting point, and the Entra ID and OIDC-based pages in this group cover that path.
Before you commit to this design, confirm three things with your directory team: which LDAP endpoint and bind account Airflow will use, whether the directory's group membership is complete for the people who need Airflow roles, and which Airflow version and FAB provider release your platform will run. Check the FAB provider's current webserver authentication documentation for the exact LDAP setting names in your release. The FAB webserver authentication documentation lists the supported options for database, LDAP, OAuth and REMOTE_USER login, and it is the reference your configuration must match.
What you need before configuring LDAP login
LDAP login touches the Airflow version, its metadata database, the FAB provider, the directory itself and the certificates that protect the bind. Settle these before editing webserver_config.py, because most failed logins trace back to one of them.
Airflow 3 and supported Python
Plan on Airflow 3, whose current patch release is 3.3.2, and run it on Python 3.10 to 3.14. Airflow 2 reached end of life on April 22, 2026, so an LDAP build started on 2.x would be built on a line that gets no fixes. If you are upgrading, the Airflow 3 upgrade guide requires being on Airflow 2.7 or later first. Confirm the Python version against the prerequisites page for the exact patch you install.
PostgreSQL or MySQL metadata database
The metadata database stores users and role assignments that FAB writes at login, so it must be durable. Use PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or an Innovation release. SQLite is for testing only and MariaDB is not supported as the metadata database. Ask your DBA to confirm backup and restore for this database, since losing it resets every synced role.
FAB provider installed
Airflow 3 ships with the Simple auth manager and allows one auth manager at a time, selected through the auth_manager option. LDAP login needs the FAB auth manager from the FAB provider package, so install that provider in the same environment as Airflow and pin it with your Airflow constraints file. Confirm the provider version against the FAB documentation before you rely on its LDAP settings.
Directory server and its lifecycle
Decide whether logins go to Active Directory domain controllers or to an OpenLDAP slapd deployment. Active Directory Domain Services runs as a Windows Server role, and Windows Server 2022 mainstream support ends on October 14, 2026. OpenLDAP current releases are 2.7.1 and 2.6.15 (LTS). Confirm the directory version and lifecycle with your vendor before go-live, not after.
Read-only service bind account
Airflow binds to the directory with a service account to search for users and read their group membership. Give it read rights only, scoped to the user and group containers Airflow needs, and no write or password reset permissions. Store its password in your secrets store, rotate it on a schedule you can name, and record who owns it so a lockout does not stop every login.
Directory group design
Map each Airflow role to one directory group, for example a group for Admin, one for Op and one for Viewer, and nest them only if your directory already does. Decide who may read DAGs but not trigger them, and create those groups before you configure mapping. Group names become configuration values, so changing them later means editing the mapping and re-testing every role.
CA certificate for LDAPS or StartTLS
Credentials for the bind account must travel over an encrypted channel, either LDAPS on port 636 or StartTLS on the standard port. Obtain the CA certificate that signed the domain controllers or slapd server, install it on every Airflow web host, and test the chain with the exact hostname in the certificate. Without it, the bind fails in ways that look like bad passwords.
Configuring LDAP login in webserver_config.py
This sequence takes Airflow 3 from a default Simple auth manager to LDAP sign-in through the FAB provider, with directory groups mapped to Airflow roles and a break-glass admin in place before cutover. Each step ends with a check you can run before the next one starts.
Install and verify the FAB provider
Install the FAB provider package into the same Python environment as Airflow 3, using the constraints file that matches your Airflow version. Confirm the auth manager class is importable from that environment on every host that runs the API server, since the scheduler and DAG processor do not read the login settings. The step is done when the import check succeeds on each API server host and the package version matches the one in your change record. Note that the FAB provider is separate from core Airflow, so a missing package is the most common reason the auth manager fails to load.
Set the auth manager and LDAP auth type
Set the auth_manager option in airflow.cfg to the FAB auth manager class, because Airflow 3 allows only one auth manager at a time and defaults to Simple. In webserver_config.py, set AUTH_TYPE to the LDAP constant. Keep the Simple auth manager settings out of the configuration on the same host so there is no ambiguity about which login path is active. The check is that the API server starts cleanly and the login page shows a username and password form rather than the Simple auth manager's page.
Set the LDAP server URI and TLS
Set AUTH_LDAP_SERVER to an ldaps:// URI that points at a domain controller or a load balancer in front of your directory, and set the certificate options so the API server validates the directory's certificate against your internal CA. Do not send bind credentials over a plain connection. Ask your directory team which domain controllers and ports are approved for this traffic, and whether a global catalog endpoint is needed if users come from several domains. The check is an openssl s_client handshake from the API server host that completes and shows the expected issuer.
Configure the service bind and search base
Create a low-privilege service account in the directory with read access to user and group objects, and no interactive login rights. Set AUTH_LDAP_BIND_USER and AUTH_LDAP_BIND_PASSWORD from your secrets store rather than typing them into the file, then set AUTH_LDAP_SEARCH to the base distinguished name for users and AUTH_LDAP_UID_FIELD to the attribute that holds the login name. Run ldapsearch from the API server host with the service account against the search base and filter for one known test user. The check is that the search returns exactly one entry with the expected attributes.
Map directory groups to Airflow roles
Build AUTH_ROLES_MAPPING as a dictionary from directory group distinguished names to Airflow role names such as Admin, Op, User and Viewer, and confirm the role names against your Airflow version. Keep the mapping to the smallest set of groups that the platform team needs, and decide in advance which group receives Admin. Retrieve the group membership of a test user with ldapsearch, using the memberOf attribute or your directory's group lookup, and compare it with the mapping entries. The check is that the test user's expected groups appear exactly as written in the mapping, including case and full distinguished names.
Enable role sync and user registration
Set AUTH_ROLES_SYNC_AT_LOGIN to True so roles are re-read from the directory on every sign-in, which means removing someone from a group takes effect at their next login. Set AUTH_USER_REGISTRATION to True if first-time directory users should get an Airflow account automatically, and set AUTH_USER_REGISTRATION_ROLE to the lowest role that fits your policy. Confirm with your security team whether registration should be restricted to specific groups, since the provider's behavior for users with no mapped group should be tested rather than assumed. The check is a login from a test account in a mapped group that lands with the expected role, followed by a second login after removing that account from the group, which should downgrade or deny access.
Create the break-glass admin before cutover
Create a local database user with the Admin role before you switch the production login path, and store its credentials in a sealed location that two named people can access. Choose a login method for it that does not depend on the directory, so that an LDAP outage, a locked service account or a bad certificate cannot remove all administrative access. Document who is authorized to use it, when it is tested and how its use is recorded. The check is a successful login with the local account on the test environment while the directory is intentionally unreachable from that host, which proves the fallback works before production changes.
Test with a pilot group and cut over
Run a pilot with a small directory group that includes one Admin, one Op and one Viewer test user, and confirm each role's access to DAGs, connections and variables on the test API server. Repeat the sign-in and role checks after an API server restart and after a credential rotation for the bind account, since both are common failure points. When the pilot passes, widen the group mapping in a change window and keep the previous configuration file available for rollback. The step is complete when the pilot results and the break-glass test are recorded together in your change record.
Mapping directory attributes and groups to Airflow roles
This table compares each directory field or group input with the Airflow setting that consumes it and the decision you need to make. Read it as a checklist to fill in with values from your own directory before you write webserver_config.py. The main takeaway is that role mapping depends on how your directory returns group membership, so confirm nested group behavior before you rely on it.
| Input | What Airflow uses it for | Decision or check before go-live |
|---|---|---|
| Username attribute | Identifies the Airflow user at login, usually sAMAccountName in Active Directory or uid in OpenLDAP | Pick the attribute that is unique and stable in your directory, and test with a real account |
| Email attribute | Stored on the Airflow user record for notifications and audit | Confirm the attribute is populated for all accounts that need access |
| Display name attribute | Shown in the Airflow user interface and audit views | Decide whether to use displayName, cn or a combined given and surname field |
| Group DN or CN | Matched against AUTH_ROLES_MAPPING keys to assign Airflow roles | Choose full DN or short CN consistently, and keep the mapping keys identical to the directory values |
| Admin role | Full administrative control of Airflow | Map only a small, named administrator group and keep it separate from daily operators |
| Op, User and Viewer roles | Operator, pipeline author and read-only access levels | Define each group's purpose in writing so access reviews can be repeated |
| Public role | Minimal access for anonymous or least-privilege users | Confirm it grants nothing your organization does not intend to expose |
| Nested group membership | Determines whether users inherited through child groups receive the parent group's role | Confirm with your directory administrator how nested groups resolve in your environment, and test a user in a nested group |
| Default role for registered users | Applied to users created at first login when registration is enabled | Set the lowest role that works, and review whether new users should be created at all |
Hardening the directory connection
The directory connection is a trust boundary: Airflow holds a bind credential, accepts logins on the strength of directory answers, and can grant Admin rights from group membership. The cards below cover transport, the service account, what the mapping can reach, and a way back in when the directory fails.
Validate certificates on LDAPS or StartTLS
Send bind requests and user passwords only over an encrypted channel. Use LDAPS on port 636 or StartTLS on the standard port, and make Airflow validate the directory server certificate against your internal CA rather than accepting any certificate. Confirm with your directory team which TLS versions and cipher suites the domain controllers or slapd instance offer. OpenLDAP slapd supports certificate authentication through TLS, so ask whether client certificates are an option for the bind.
Use a least-privilege bind account
The bind account only needs to search for users and read group membership under the search base. Give it read-only rights, no membership in privileged groups, and a password that expires on a schedule your directory team can rotate. Store that password in a secrets backend and inject it at runtime, not in webserver_config.py committed to source control. Ask whether your directory supports SASL-based binds, which avoid sending a reusable password in the clear.
Restrict who can reach Admin
Mapping a directory group to the Admin role is the highest-impact decision in this setup. Limit Admin to a small, named group that is reviewed on your normal access cycle, and keep Viewer or Op as the default for everyone else. Check that nested group membership is resolved the way you expect, because a group nested inside an admin group can grant Admin without anyone noticing. Re-test the mapping after each directory change.
Disable referrals and anonymous binds
Turn off LDAP referral chasing unless you have a documented need, since a referral can send the bind to a server outside your control. Confirm that anonymous binds are rejected both at the directory and in the Airflow configuration, so a blank password cannot pass as a successful login. Test both settings with a deliberately wrong password and an empty password before you go live.
Keep a separate break-glass admin
Keep one local database admin account with a long, unique password held in your password vault, and test that it can sign in while the directory is unreachable. Store it outside the LDAP path, restrict its use to documented emergencies, and alert on every login. Review whether AUTH_USER_REGISTRATION could let an unknown user become a new account, and disable it if your access process does not require it.
Active Directory or OpenLDAP: choosing the directory side
When domain controllers already hold your users and groups, Active Directory is the source of truth and Airflow should authenticate against it. Active Directory Domain Services replicates directory data to every domain controller in a domain, so Airflow can point at a reachable controller, but the bind and search settings must match how your domain is laid out. Microsoft notes that most on-premises apps authenticate against Active Directory with LDAP, so this is a well-trodden path.
- Bind account: use a dedicated, low-privilege service account with read access to users and group membership, never a domain administrator. Store its password in a secret store rather than in plain text in
webserver_config.py. - Search base and filter: scope the search to the OU that holds Airflow users and groups, and confirm with the directory team which attribute carries the login name.
- Controller addressing: prefer LDAPS or StartTLS to named controllers, and confirm which controllers each Airflow component can reach through its network path.
- Nested groups: confirm whether role mapping must resolve nested group membership, since that changes how the group search is written.
Ask the directory team to confirm the service account's rights, the OU scope and the controller names in writing before any Airflow configuration starts.
Linux-centric organizations often run OpenLDAP or FreeIPA. The current OpenLDAP feature release is 2.7.1 and the long term support release is 2.6.15. slapd implements LDAPv3 with strong authentication through SASL and certificate authentication through TLS. FreeIPA bundles LDAP with Kerberos, certificates and host access policy, and it can establish a cross-forest trust with an Active Directory domain on Windows Server 2008 R2 or later.
- Release choice: 2.6.15 is the LTS branch and 2.7.1 is the feature line. Confirm which branch your distribution packages before you build against it.
- Schema and object classes: confirm the login attribute (often
uid) and the group object class that Airflow's group lookup will expect, including whether groups are posixGroup or groupOfNames. - Replication: slapd supports multi-provider replication where a single point of failure is not acceptable, so point Airflow at a failover or load-balanced name rather than one node.
- Retired components: OpenLDAP 2.7 retired the back-sql and back-perl backends and deprecated GnuTLS integration, so check your build and TLS library before adopting it.
Ask the directory team which branch, replication topology and TLS library they run, and confirm the attribute names before writing any search filters.
Many organizations run Active Directory for Windows and a Linux directory or Linux hosts on the same network. Microsoft describes Linux integration with Active Directory as either third-party tooling or configuring Linux to authenticate against Active Directory as a Kerberos realm, because Windows devices can be domain-joined and managed with Group Policy in a way Linux hosts generally cannot. Airflow's login does not depend on how Linux hosts authenticate, but that decision determines which system holds the identity records Airflow relies on.
- Ownership of Linux identities: decide whether Linux hosts keep local or FreeIPA identities while Airflow logs in against Active Directory, so one person does not have two sources of truth.
- Kerberos realm or third-party tooling: pick one route, document its support owner and keep it separate from the Airflow bind design.
- Trust path: a FreeIPA cross-forest trust lets Active Directory users reach Linux resources, which may matter if Airflow workers or their hosts run on Linux.
- Cloud identity sync: if Microsoft Entra ID is planned, Microsoft Entra Connect syncs existing Active Directory identities to the cloud, which is a separate path from LDAP login.
Before writing role mappings, confirm which system is authoritative for group membership, because Airflow will only be as accurate as that source.
The FAB auth manager can authenticate users directly against LDAP through webserver_config.py. Alternatively, a federation layer such as Keycloak or authentik can sit between the directory and Airflow and hand Airflow an OAuth or OpenID Connect sign-in. Microsoft notes that Active Directory needs a federation system such as AD FS for SaaS applications, so the same question appears on-premises. The FAB webserver authentication documentation covers both approaches, and each one has costs.
- Direct LDAP: this has the fewest components, but Airflow holds the bind credential and needs network paths to every directory server it uses.
- Federation layer: a broker can front Active Directory or OpenLDAP and give Airflow a single sign-in, but it adds a service to patch, back up and upgrade.
- Multi-factor sign-in: a plain LDAP bind checks passwords only, so multi-factor requirements usually point toward a federation layer or a separate control. Confirm what your policy requires.
- Audit trail: decide which system records sign-in events and group changes, since that determines where you collect evidence.
Choose the path with your security team before the build, because it decides where the bind secret lives and which logs an auditor will ask for.
Why LDAP login fails and how to fix it
This table lists the failures teams most often hit when wiring Airflow's FAB auth manager to Active Directory or OpenLDAP, with the likely cause, a diagnostic step and the fix for each. Work through the rows in order: transport and bind problems block everything, so confirm them before checking search scope, group mapping and role sync.
| Failure | Likely cause | Diagnostic step | Fix |
|---|---|---|---|
| Certificate chain errors on LDAPS | The CA that signed the directory server certificate is not trusted by the Airflow webserver or API server container or host. | Test the TLS handshake from the Airflow host against the LDAPS port and read the certificate chain the server presents. | Add the full issuing CA chain to the trust store used by Airflow, then confirm the TLS handshake succeeds before changing any other setting. |
| Wrong bind DN or password | The service account DN is written in the wrong format, the account is disabled or locked, or the password has been rotated without updating Airflow. | Bind with the same DN and password using a separate LDAP client from the Airflow host and review the directory's failed bind events. | Correct the bind DN in webserver_config.py, store the password in a secret source rather than plain text, and confirm the account is enabled and not locked. |
| User search base too narrow | AUTH_LDAP_SEARCH points at an organizational unit that does not contain every user who needs Airflow access. | Run the same user filter against the directory with the search base and check whether the target user's entry is returned. | Widen the search base to the parent container that holds all intended users, and tighten the filter on a user attribute rather than on location. |
| Group DN mismatch in AUTH_ROLES_MAPPING | The mapping keys use a group name or CN that differs from the full distinguished name the directory returns for membership. | Read the user's memberOf attribute (or equivalent) and compare each value character by character with the keys in AUTH_ROLES_MAPPING. | Replace the mapping keys with the exact group DNs returned by the directory, including case and spacing, and test with a non-admin account first. |
| Users locked out by role sync | AUTH_ROLES_SYNC_AT_LOGIN is enabled and a group is missing, renamed or unreadable, so the user's role is reduced to nothing or a default role. | Compare the user's directory groups before and after a failed login, and check the Airflow user record and its role assignments after the sync. | Keep the mapping complete for every group that grants access, verify group reads with the bind account, and agree a default role for users who match no group. |
| No Admin left after misconfiguration | The only account mapped to Admin was removed from its group, or a mapping change removed the Admin role from every user. | Check which accounts still hold Admin in the Airflow metadata database and whether any directory account still maps to Admin. | Restore the Admin group membership, then use a break-glass local admin account kept outside the directory flow and tested before go-live. |
| Nested group gaps | The directory groups a user through nested membership, but the attribute Airflow reads lists only direct groups. | Compare a user's direct memberOf values with what the group actually grants in the directory, and identify which parent groups are missing from the results. | Confirm with the directory team whether nested resolution is available and supported for your setup, or map roles to the groups users are directly placed in. Test each nested case before relying on it. |
| Login works for some users but not others | Users sit in different domains, OUs or referral chains, or the directory returns referrals that the bind account cannot follow. | Test a failing user and a working user side by side with the same filter and bind account, and note which search base and domain each belongs to. | Align the search base and bind permissions with every population that needs access, then review referral handling with the directory administrator. |
Questions buyers ask before configuring LDAP login
Does the FAB auth manager support LDAP login for Airflow 3?
Yes, the FAB auth manager supports LDAP as one of its authentication options, alongside database passwords, OAuth and REMOTE_USER, all configured in webserver_config.py. FAB is provided by the FAB provider package, and Airflow 3 allows only one auth manager at a time, selected with the auth_manager option. That means LDAP login is a choice of auth manager for the whole deployment, not an add-on you can enable beside the Simple auth manager. Confirm the provider version you will run against your Airflow 3 release before you commit to the design, since the auth manager documentation is the place to check supported settings.
How much effort does LDAP login setup take?
Effort depends less on the Airflow settings themselves and more on what sits behind them. The main drivers are the directory structure (one domain or several, nested groups, multiple organizational units), how many Airflow roles you need and how cleanly directory groups map to them, the TLS trust chain between Airflow and the domain controllers, and whether a directory administrator can quickly confirm bind accounts and search bases. A small, well-documented directory with a short role list is a much smaller job than a multi-domain forest with inconsistent group naming. Ask any provider to break its quote into directory discovery, configuration, certificate work, role mapping and testing, so you can see which part your team can absorb.
How long until users can sign in with LDAP?
The time to a working login is driven by how quickly the inputs arrive, not by the configuration step itself. A login can work once the bind account, search base, TLS certificate and a first test user are in place, but the role mapping usually takes longer because it depends on group names that the directory team has to confirm. Delays commonly come from waiting for a bind account with the right read scope, from certificate chains that need an internal CA update, and from groups that were never designed for Airflow. Ask for a timeline that lists these dependencies as milestones, and ask who owns each one on your side.
What do we need to provide before the work starts?
Plan to supply four things before work begins:
- A directory administrator who can answer questions about the domain, the search base and group nesting.
- A dedicated, least-privilege bind account with read access to users and the groups you will map.
- The CA certificate or chain that signs your domain controllers' LDAPS certificates, so Airflow can verify the connection.
- A written list of the directory groups that should map to each Airflow role, with the named owner of each group.
Also provide a test set of accounts in each group, so role mapping can be verified before users rely on it. Any provider should confirm these inputs in writing as part of the scope.
Can our internal team configure Airflow LDAP login alone?
Often, yes, if your team already runs Airflow and has someone who understands the directory, certificates and the FAB provider configuration. The work is well-bounded: it is a single configuration file plus directory and certificate coordination. The harder parts are usually the ones outside Airflow, such as agreeing on group design, validating TLS in a test environment and documenting the break-glass procedure so it survives staff changes. Assess honestly whether someone on your team has recently done LDAP troubleshooting, and whether there is a non-production Airflow where role changes can be tested first. If those gaps exist, a partner can cover them within a fixed scope.
How does a fixed-scope quote for LDAP login get built?
A fixed-scope quote follows from a written scope that lists the environment, the Airflow and FAB provider versions, the directory type (Active Directory or OpenLDAP), the number of Airflow roles and directory groups to map, the TLS approach and the deliverables. DeployOpen does not publish a price list, so a quote is produced only after that scope is agreed. Ask the provider to state what is excluded, such as directory remediation, changes to group structure, and support after go-live, and whether a break-glass admin test and documentation are included. Ongoing support is handled separately as a retainer if you want it.
What breaks most often with LDAP and Active Directory login?
The failures that surface most often are predictable. TLS verification fails because the internal CA is not trusted by the Airflow host. The bind account works but cannot read group membership, so users sign in with no roles. Group names differ between the directory and the mapping file, often through case or prefix differences. Role sync at login is not enabled, so a removed user keeps old permissions. And no one tests the break-glass admin until the day it is needed. Ask your team to test each of these on a staging Airflow before go-live, and check that the directory-side logs show the bind and search attempts you expect.
Should we use Active Directory or OpenLDAP as the login source?
Choose the directory your organization already runs as the system of record for identities, because that keeps joiners, movers and leavers in one place. For most organizations that is Active Directory, which Microsoft describes as the on-premises directory that most applications authenticate against with LDAP. OpenLDAP is a reasonable choice where the identity source is already a Linux-based directory, and the OpenLDAP project publishes a current feature release and a long term support release that you should check before selecting a version. Confirm the group schema and the search attributes with whichever directory you choose, since Airflow mapping depends on them.
Keeping a break-glass admin when the directory is down
A break-glass admin account must exist before the LDAP or Active Directory integration goes live, because if the directory, the bind account or the TLS chain fails, nobody can sign in to Airflow to fix the configuration. The FAB auth manager reads its login methods from webserver_config.py, and the account you keep for emergencies should come from a path that does not depend on the directory, such as a database password user created with the Admin role. Store its credentials in a sealed, access-logged vault that is separate from the Airflow configuration repository, and record who can retrieve it and under what approval. Name exactly one or two people who hold the account, and document the rotation schedule in your own change management process.
Before relying on that account, confirm which login methods your FAB provider version can run side by side, since the configured auth manager and the password and LDAP login paths interact differently across releases. Check the current auth manager documentation for your installed provider version, and test the combination in a non-production environment first. Then test the break-glass path on a schedule, for example by signing in with the local account in staging and confirming that the admin role works, without changing the directory settings or disabling LDAP in production. Keep the test narrow so that the directory path stays the normal way engineers sign in.
Review every use of the break-glass account in the Airflow logs and in your central log platform. Alert on any successful login by that identity, and require a ticket or incident reference that explains the reason. Confirm during the review that the account's login events carry enough detail to identify the person and the time, and that the events reach a store that engineers running Airflow cannot edit. Ask your DeployOpen team, or your own security group, to verify this logging path as part of acceptance testing, because a break-glass account you cannot audit is a standing risk to the platform.
How DeployOpen scopes and delivers Airflow directory login
DeployOpen plans and implements Airflow directory login as part of a self-hosted platform inside your own infrastructure. We start from your directory design, the group structure that maps to Airflow roles, and the TLS and bind requirements of your environment, then build and document the FAB configuration with a tested break-glass path.
How we scope
- Engagements are fixed-scope, with the directory type, bind account, TLS setup and role model agreed in writing before work starts
- The written scope lists which Active Directory or OpenLDAP groups map to Admin, Op, User and Viewer roles, and who approves each mapping
- We confirm the Airflow version and auth manager setting, and whether your environment uses the FAB provider as planned
- Ongoing support, upgrades and continuous testing are available as retainers, and the scope states what each retainer covers
How we build
- We build webserver_config.py for LDAP with a service bind account, certificate validation and a tested search filter for your directory
- We configure AUTH_ROLES_MAPPING and AUTH_ROLES_SYNC_AT_LOGIN against a group list you review, with registration settings set deliberately
- We test sign-in with users from each group, including users who should be denied, and record the results for your review
- We set up a break-glass administrator account that does not depend on the directory, and verify it works during the test cycle
How we hand over
- You receive the configuration files, a group-to-role mapping table and the directory query settings in a documented form
- The runbook covers adding or removing users from groups, rotating the bind password and handling certificate renewal
- We document the break-glass procedure, where its credentials are stored and how access to it is logged and reviewed
- Handover includes a walkthrough with your identity and Airflow administrators so the team can operate the setup without us
How we support
- Support covers reviewing the configuration after Airflow and FAB provider upgrades, since auth settings can change between releases
- Directory changes such as renamed groups or moved organizational units are reviewed against the role mapping before they reach production
- Retainers can include periodic checks of bind account permissions, certificate expiry and break-glass access tests
- Each change is documented so your compliance and audit teams can see who changed the mapping, when and why
