Graylog SSO and identity integration guide

Graylog SSO: which login method fits your identity setup

The right Graylog login method depends on two things: the edition you run and the identity source your staff already use. Per the Graylog authentication documentation, Graylog Open supports Active Directory, LDAP and trusted header authentication, while Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on. If your identity provider is Okta or another OpenID Connect or SAML service, licensing largely settles the question, so start by confirming whether an Enterprise subscription is in scope. If you run Active Directory or LDAP on Open, the next question is how directory groups will reach Graylog roles.

Turning on single sign-on is the easy part. What makes it harder is group mapping, because the roles a user receives in Graylog decide which streams that user can search. A wrong mapping can expose log data to people who should not see it, or hide it from the people who need it during an incident. A misconfigured bind account for LDAP or Active Directory can stop logins entirely, including the administrator logins you would use to fix it. Trusted header authentication is only as safe as the proxy that sets the header, so if the Graylog server accepts that header from any client, anyone can claim to be an administrator.

The work usually sits with two teams. The identity team owns the directory, group membership, the bind account, the identity provider application and its certificates or client secrets. The log platform team owns Graylog roles, stream permissions, server configuration and the reverse proxy in front of the web interface. The two halves meet at the group names, so agree on those names in writing before anyone edits configuration. Ask the identity team who can change group membership and how quickly a removed user loses access, because a slow offboarding path leaves former staff able to search logs.

Before you choose a method, confirm four things in your own environment: which edition you have licensed, which identity source is authoritative, whether nested groups or group-to-role mapping must be supported, and which local account will remain available for recovery. Test the chosen method on a non-production Graylog node first, with one test user per role, and document and test a break-glass local administrator account. When you request a quote, ask for the group map, the scope of the bind account and the proxy trust rules to appear in the written scope, each with a named owner on your side.

The authentication paths and settings Graylog exposes

Graylog exposes several authentication paths. Some are available in Graylog Open, and others are single sign-on providers that come with Graylog Enterprise. Each card names one component, who typically owns it, and what to confirm before you choose a path or change a setting.

Graylog server authentication configuration

This is the server-side configuration that decides which authentication backends are active and the order in which they are tried. It applies to every Graylog server node, so a multi-node cluster must carry the same effective configuration on each node, or users may log in differently depending on which node answers. The platform team owns these changes. After each change, test a login directly against each node and through the load balancer to confirm the result is the same.

Active Directory and LDAP backend

In Graylog Open, Active Directory and LDAP verify user credentials against your directory, so passwords and account state remain there. The identity team owns the service account Graylog uses to query the directory, the search scope and network access from each Graylog node. Confirm with the directory team whether the connection must use TLS, and how disabled or locked accounts behave, because Graylog only sees what the directory returns at login.

Trusted header path behind a gateway

Trusted header authentication lets a reverse proxy or gateway authenticate the user and pass the identity to Graylog in a request header. Graylog accepts that header as proof of identity, so the protection depends on the network path. Any client that can reach Graylog without passing through the gateway could forge the header. The gateway team owns the authentication step, and the Graylog team must confirm that Graylog accepts traffic only from the gateway. Test with a direct request that carries the header.

Enterprise single sign-on providers

Graylog Enterprise adds single sign-on with Okta, generic OpenID Connect and SAML. Each provider needs an application registration in the identity provider, a redirect address that matches the public Graylog URL, and credentials such as certificates or client secrets that must be rotated on a schedule. The identity team owns the registration, and the Graylog administrator owns the connection and its testing. Confirm the edition and license before scoping, because these providers are not included in Graylog Open.

Group-to-role mapping

Mapping directory or identity provider groups to Graylog roles determines what each user can search, view and administer. Access drift often happens here: a renamed group, a removed group or a broad administrator group can change access without any change inside Graylog. Assign one owner for the mapping, keep a written list of each group and the role it grants, and review it during joiner, mover and leaver processes. Test each role with an account that represents the access it should have.

Local accounts for break-glass access

Local Graylog accounts remain available for emergency access when the directory, the gateway or the identity provider is unavailable. Each one needs a named owner, a credential stored under your secrets process and a documented condition for when it may be used. After single sign-on is enabled, confirm which local accounts still exist, disable any that are not needed and review their login activity in your logs. Test the break-glass procedure before you need it.

Which Graylog SSO option fits your environment

This table compares the ways to authenticate users into Graylog and shows which options need a Graylog Enterprise subscription. Read each row against your directory, your reverse proxy and your identity provider ownership. SSO needs can also change the edition decision, because Graylog Enterprise is licensed on processed data and starts at 15,000 US dollars per year on the Graylog pricing page.

Option	Fits when	Needs Enterprise	Ongoing operational cost
Active Directory or LDAP	Users sign in through a central directory and group membership should drive Graylog roles	No	Service account bind credentials to rotate, group to role mappings to review, and directory connectivity to keep working
Trusted header behind a proxy	A reverse proxy already authenticates users and passes their identity in a request header	No	Proxy trust boundary to maintain, header handling to verify after proxy changes, and access paths to test
Okta	Workforce identity is managed in Okta and Okta should control sign in and group based access	Yes	Okta app and group configuration maintained by the identity team, plus Graylog changes when claims or groups change
Generic OpenID Connect	Your identity provider supports OpenID Connect and you want standards based sign in beyond Okta	Yes	Client registration, redirect URI and claim mapping to maintain with the identity provider owner
SAML single sign-on	Your identity provider offers SAML and your policy requires it for internal applications	Yes	Metadata and certificate renewal with the identity provider owner, plus attribute mapping checks after changes
Edition decision	SSO requirements may move you from Graylog Open to Enterprise, which is priced on processed data	Not applicable	Confirm with Graylog which edition and processed volume your SSO design requires before the quote is written

How to configure Graylog SSO without locking out administrators

This sequence adds single sign-on to Graylog without cutting off the people who maintain it. Each step ends with a check you can see, so a failed change is caught while a local administrator can still sign in. The output is a tested login path, mapped roles and a staged rollout to users.

Confirm edition and identity source
Confirm which Graylog edition you run and which identity source your users sign in through. Graylog Open supports Active Directory and LDAP authentication and trusted header authentication, while Okta, generic OpenID Connect and SAML single sign-on are listed for Graylog Enterprise. Check the authentication documentation for your exact version, because the current docs cover version 7.2 and your deployment may differ. Ask the identity owner to record the directory host, the domain or search base, and whether multi-factor sign-in is enforced upstream. Done when the edition, backend and version appear together in one change record that the identity owner has approved.
Document groups and the roles each needs
List the directory groups that should reach Graylog and the Graylog role each group needs, such as reader, editor or admin. For each group, include the streams its members may search, because stream permissions decide what a role can see. Keep the list short and name an owner for every group. Store the table with the change record so the mapping in the fifth step can be checked against it. Done when a reviewer can read the table and state, for each group, what a member can do on the first day of access.
Create bind account and secure break-glass admin
Where the chosen method needs a bind, create a dedicated service account in the directory with read-only access to the user and group objects Graylog must query. Do not reuse a personal or administrator account for this purpose. Separately, keep at least one local Graylog administrator with a strong password stored in your vault, and confirm how your version handles local accounts alongside directory sign-in. Record where the credentials live in your break-glass procedure. Done when the bind account returns a successful directory search and the local administrator signs in from a session you control.
Configure the chosen authentication backend
Enable the backend selected in the first step and point it at the directory server, using an encrypted connection and the search base that contains your groups. Confirm the setting names in the authentication documentation for your version, because they can change between releases. Keep local login active for the whole change window. Test the connection from the Graylog server first, then sign in with one directory account. Done when the test connection succeeds and the test account's sign-in result matches what the change record predicts for a user with no mapped role.
Map directory groups to Graylog roles
Map each directory group from the second step to the Graylog role it should receive, and map no other groups. Start each group at the least privileged role that meets its needs, and grant admin only to a named group with a documented owner. Confirm that group membership produces the expected role by checking the user's account in Graylog after a fresh sign-in. Done when a spot check of users from three different groups shows the roles listed in your table, and a group that is not in the table receives no elevated role.
Verify stream permissions follow the roles
Choose a test stream that only one group should reach, then compare what each role can see. Run the same search as a member of the permitted group and as a member of a group outside it. The permitted user should receive results, and the other user should be denied. Check any dashboards or saved searches built on that stream too, since they must not expose data to users who cannot open the stream. Done when both denied and permitted results are recorded in the change ticket with the user, group and stream named.
Test with a non-administrator account
Sign in with a standard directory user who holds the lowest role you plan to grant. Confirm that the login succeeds through the new backend, that the user lands on the expected page, and that administrative areas such as user and system settings are not available to them. Repeat the test with a user from a second group. Keep the local administrator signed out during these tests so you prove the directory path works on its own. Done when both test logins match the role table and any gap has been fixed and retested before rollout begins.
Roll out to users in stages
Enable directory sign-in for a small pilot group first, then widen access in stages after the pilot signs in without support tickets. Agree the length of each stage in writing before you start, and keep the local administrator and break-glass procedure in place throughout. Review failed sign-ins after each stage and fix mapping gaps before adding the next group. Done when every intended user signs in through the new backend, the local administrator has been tested again, and the break-glass procedure is filed with the change record.

What drives Graylog SSO effort and cost

This table lists the factors that change how much work a Graylog SSO integration takes and what it costs to run. Read each row as a lever: the driver on the left, why it matters, and how to keep it under control before the work starts. The main takeaway is that group hygiene and the number of identity sources usually decide effort more than the Graylog configuration itself.

Driver	Why it changes effort or cost	How to keep it down
Identity sources and directories	Each Active Directory forest, LDAP directory or identity provider needs its own connection, bind account, test cases and failure path. Graylog Open supports Active Directory and LDAP authentication and trusted header authentication, so the authentication method chosen per source sets the build work.	Use one authoritative identity source where possible. Confirm with your directory team which forests or domains hold the users who need Graylog access before scoping.
Groups and roles to map	Every directory group that grants Graylog access must be mapped to a Graylog role or permission set. The mapping table grows with each group, and each mapping needs a test to prove the right access is granted and denied.	Clean and rename groups before mapping. Remove stale, nested or duplicate groups, and map only the groups that a Graylog role actually needs.
Graylog server nodes and proxy paths	A multi-node Graylog deployment behind a load balancer or reverse proxy needs the SSO settings, callback paths and trusted header rules consistent on every node. Trusted header authentication depends on the proxy stripping and setting headers correctly on each path.	Standardize one proxy path and one configuration template for all nodes. Confirm the load balancer behavior with the network team before testing.
Enterprise SSO providers and licensing	Okta, generic OpenID Connect and SAML single sign-on are part of Graylog Enterprise, not Graylog Open. Choosing these providers can change the edition and subscription, which is a recurring cost, and the pricing page lists Enterprise from 15,000 US dollars per year with a minimum data volume.	Decide the edition before design starts. If Graylog Open with Active Directory or LDAP meets the access model, avoid licensing Enterprise for SSO alone. Ask the vendor to confirm current edition terms in writing.
Existing identity provider and group hygiene	An identity provider with inconsistent attributes, unused accounts or unclear ownership of groups adds analysis, exception handling and rework across the whole project.	Run an access review of the groups and accounts that will reach Graylog before the project begins. Assign an owner to each group that maps to a Graylog role.
Compliance evidence needs	If auditors or internal control owners expect evidence of who can access log data, the team must produce role mappings, access review records, configuration exports and change records. This adds documentation and sign-off effort. DeployOpen prepares evidence, but independent auditors issue any assessment outcome.	Agree the evidence list with your assessor before build. Ask for the mapping and test records to be produced as part of the build, not after it.
Environments to validate	Each environment, such as development, test and production, needs its own SSO configuration, test accounts, mapping checks and rollback steps. Validation effort rises with each additional environment and each identity source tested in it.	Test the full integration in a non-production Graylog instance first, then promote the same configuration to production. Keep test accounts limited to the roles under test.

How Graylog SSO changes in single node, multi-node and air-gapped setups

On a single Graylog node, the web interface, the API and the login endpoint share one host name, so SSO settings point at one place. Directory bind settings and group mappings are set once, and any trusted header proxy sits in front of that one node. Most of the effort is in testing the whole path on one server before any wider rollout.

Login endpoint: users reach the node directly or through one reverse proxy. The external address must match the public URL configured in Graylog so redirects resolve correctly.
Trusted header proxy: one proxy fronts the node. It must remove any identity header a client sends and then add its own value from the authenticated session.
Directory access: the node needs network reach to the Active Directory or LDAP servers on the ports your directory uses, plus a service account for lookups.
Certificates: if you use LDAPS, the directory CA chain must be in the trust store the Graylog server process reads.

Before you change anything else, confirm that a test user from each mapped group lands in the expected role.

Securing Graylog SSO login paths and service accounts

Single sign-on moves the trust decision out of Graylog and into the proxy, the directory and the people who administer them. The cards below cover the controls that keep those trust paths narrow, from which proxies can assert identity to how departures and break-glass access are handled.

Restrict trusted header senders

With trusted header authentication, Graylog accepts a username from a request header, so any host that can reach the Graylog server and set that header can act as a user. Limit the trusted proxy addresses to the reverse proxy or load balancer only, and confirm that the proxy strips any incoming copy of the header before it adds its own. Test by sending a forged header from an unlisted host and confirming it is rejected.

Limit the directory bind account

Graylog needs a bind account to search Active Directory or LDAP for users and groups during login. Give that account read access to the required user and group objects only, with no write rights and no membership in privileged groups. Ask the directory team to confirm the account cannot change passwords or modify group membership, since a compromised bind account would otherwise expose the whole directory.

Keep credentials out of config files

The directory bind password, any OpenID Connect or SAML client secret, and the Graylog secret used for signing must not sit in plain text in configuration files or version control. Store them in a managed secrets store, inject them at service start, and restrict who can read them. Confirm the rotation procedure in advance, including how Graylog nodes pick up a new value in a multi-node cluster.

Enforce TLS on every SSO path

Login traffic to the Graylog web interface and the connection to the directory both carry credentials and must be encrypted. Require HTTPS between users and the proxy, and use LDAPS or StartTLS for directory queries, validating the directory certificate chain on the Graylog side. Check that plain LDAP on port 389 and unencrypted HTTP are disabled, and test that certificate expiry is monitored.

Review group to role mappings

Each directory group mapped to a Graylog role grants access to streams, dashboards and data, so mappings drift as teams change. Set a recurring review, typically tied to access recertification, where the security owner and the log platform owner confirm every mapping still reflects the approved role. Remove mappings for groups that no longer have a business purpose and check that no group grants admin rights without an explicit approval.

Remove access when people leave

Because Graylog can hold its own local accounts alongside SSO users, disabling a directory account does not always end access. Confirm how deprovisioning works for each login path, including any local users created for troubleshooting, existing sessions and API tokens tied to a person. Ask the operations team to document this as part of the offboarding checklist and test it with a sample account.

Control break-glass local accounts

A local administrator account lets the team recover Graylog when the directory or SSO provider is unavailable. Keep it disabled by default, store its password in a sealed vault with dual custody, and enable it only through a documented change. Every use should generate an alert and a review ticket, and the account should be tested on a schedule so it works when needed.

How to test Graylog SSO and confirm it fails safely

Test the Graylog login path before users depend on it, and treat the failure cases as seriously as the successful login. Build a written test plan that covers one successful login for each mapped Active Directory or LDAP group, the role and stream visibility each group should see, and a denial for an account outside every mapped group. For Graylog Open, the authentication documentation lists Active Directory, LDAP and trusted header authentication as the supported methods. Confirm in your own environment which group-to-role mappings you configured, then check each test account lands in exactly the role you expect and can open only the streams that role is granted. A user who logs in successfully but sees a stream they should not see is a failed test, even though the login itself worked.

Next, test the failure modes on purpose. Stop or block access to the directory server, or disable the identity path in a test copy, and confirm that the local break-glass administrator account still signs in. Keep the break-glass credential stored outside the directory it protects, and record who can retrieve it and how that access is logged. Then send a trusted header request from an address that is not on your proxy allow list and confirm Graylog rejects it rather than accepting the header as an identity. This matters most when Graylog sits behind a reverse proxy, because a header that a client can inject is an authentication bypass. Ask your proxy team to confirm which addresses are trusted and which headers the proxy strips from inbound requests.

Then test the session lifecycle and the change path. Confirm that sessions expire after the inactivity period you configured, that logout ends the session in the browser and on the server, and that an expired session cannot be reused with an old token or cookie. Finally, move a test user from one mapped group to another in the directory, wait for the change to take effect under your configured refresh behavior, and verify that the user's role and stream access change to match the new group and no longer reflect the old one. Ask the implementation team to confirm how quickly Graylog picks up directory changes in your version, since the answer determines how long a removed user keeps access.

Record every test as a row with an identifier, the preconditions, the steps, the expected result, the actual result, the tester and the date. Store the expected results before running the tests so that the actual results cannot be shaped to fit them. Keep failed tests and their fixes in the same record, and attach configuration exports, screenshots of role and stream views, and log entries showing denied attempts. This record is the handover evidence your operations team and any internal or external auditor will ask for when reviewing access control for the Graylog platform. Re-run the full plan after each Graylog upgrade, directory change or proxy change, because each of those can alter the behavior you tested.

Decide before testing who owns each pass or fail decision, and what happens to a failed test. A failed denial test or a trusted header accepted from an untrusted address should block go-live, not be queued as a later fix. Confirm with your security team whether the test results need to be retained for a defined period under your own policy, and where they will be stored with access restricted to the people who need them.

Operating Graylog SSO after go-live

Once Graylog SSO is live, most failures show up slowly: a directory account expires, a certificate nears its end date, or an upgrade changes how logins are checked. The cards below cover what to watch, what to back up, how upgrades and group changes are controlled, and what the operating team must hand over.

Monitor failed logins and lookups

Track failed login attempts in Graylog and the directory lookup errors that appear when Active Directory or LDAP is unreachable or a bind fails. Set event definitions or alerts for spikes, not single failures, so a lockout or a directory outage reaches the on-call team quickly. Check that the bind account and the search base still resolve, because a stale bind often looks like a wrong password to users.

Watch certificate expiry for identity metadata

For Graylog Enterprise SAML and OpenID Connect integrations, record the expiry dates of signing and encryption certificates and the identity provider metadata that refers to them. Set reminders well ahead of each date and confirm who rotates the certificate on the identity provider side. An expired certificate stops logins for every user at once, so this check belongs on the same calendar as other renewals.

Back up configuration and role mapping

Back up the Graylog configuration that controls authentication, the group-to-role mapping, and the MongoDB metadata that stores users and roles. Keep bind credentials, client secrets and signing keys out of plain-text backups and store them in the client's approved secrets manager. Test a restore in a non-production environment so that the mapping and the secret references can be rebuilt from the documentation alone.

Plan upgrades that touch authentication

Treat any Graylog upgrade that changes authentication settings, the MongoDB or OpenSearch version, or the identity module as a change that needs its own test. Check the Graylog compatibility matrix for the target release before scheduling, and confirm the supported MongoDB and OpenSearch or Data Node versions. Run the SSO test script against a staging copy of the production configuration, then repeat it on the first node that is upgraded in a rolling sequence.

Request and approve group changes

Every change to a directory group, a Graylog role or a group-to-role mapping should go through a written request with a named requester, a business owner who approves the access level, and a reviewer who applies it. Record the change in the same mapping document the team uses for handover, and review group membership on a fixed schedule. Ask the client's identity team how they expect these requests to arrive, because that determines who can change the mapping.

Hand over the SSO operating pack

The handover should include the current group-to-role map, the name of the owner of the bind account and its renewal process, the break-glass procedure for local administrator access when the identity provider is down, and the test script with its expected results. Store the pack in the client's document system with a review date and an update owner. Confirm that at least two people can run the break-glass procedure and the test script without the original implementation team.

Graylog SSO cost, effort and what you need to provide

Does Graylog Open support Active Directory or LDAP login?

Yes. The Graylog authentication documentation lists Active Directory and LDAP authentication as part of Graylog Open, so directory login does not require an Enterprise subscription. The work is configuration and testing, with no product change needed: a bind account with read access, search bases that match your directory layout, a secured connection to the directory, and a mapping from directory groups to Graylog roles. Most of the effort usually sits in the group mapping, because every group that grants access needs a defined role and a test user who proves that role works. Confirm the exact options for your directory product and Graylog version in the documentation before you write the configuration.

What does Graylog Enterprise add for single sign-on and what does it cost?

Graylog Enterprise adds Okta, generic OpenID Connect and SAML single sign-on, according to the Graylog authentication documentation. The Graylog pricing page lists Enterprise starting at 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Enterprise also includes a data lake with archive restore, data tiering, a correlation engine and 24/7 support. SSO is therefore one input to the edition decision, not the only one. Ask whether your daily volume, retention and support needs justify the subscription on their own, and confirm the current price and minimums on the pricing page before you budget.

What drives the effort of a Graylog SSO integration?

The main drivers are the shape of your identity estate and the number of access rules Graylog has to reflect. Count the directories or identity providers involved, the number of groups that grant Graylog access, and how deeply those groups are nested. Each group that maps to a role adds design, configuration and test cases. The protocol matters too: directory login, OpenID Connect and SAML each need different trust settings, certificates and attribute handling. If a reverse proxy handles authentication, its header rules and its trust boundary add work. Finally, the number of environments (lab, staging, production) and the number of approvers on the change process multiply the testing and sign-off steps.

How long does a Graylog SSO integration take to deliver?

The duration depends on the written scope, so this page does not estimate it. A scope limited to directory login with a small set of groups is a different project from one that covers multiple identity providers, dozens of role mappings and several environments. Timing also depends on how quickly your directory, identity provider and network owners can provide access and approve changes, which often sets the pace more than the Graylog configuration does. Ask for a timeline that lists each milestone, the owner of each dependency and the testing evidence that closes each milestone. A fixed-scope agreement in writing is the point at which a duration can be stated with confidence.

What do I need to provide for a Graylog SSO project?

Prepare four things before work starts. First, directory access: a service account with read permission for the users and groups in scope, plus the search bases and attributes that identify them. Second, a group inventory: each group, its membership source and the Graylog role it should receive, agreed by the business owners. Third, identity provider admin access for Okta, OpenID Connect or SAML settings, including the ability to register the Graylog application and read its claims. Fourth, network paths: routes and firewall rules from the Graylog nodes to the directory or identity provider, the correct ports, and the certificates needed to trust those connections. Also name a test group of users and a window for changes.

Can our own identity team set up Graylog SSO without a partner?

Often yes, if the team already runs the directory or identity provider and has someone who administers Graylog. The Graylog documentation is public and covers the configuration options for each method. What a partner adds is a fixed scope agreed in writing, a documented role mapping, test evidence for each role, and a handover that your staff can operate. The questions to answer honestly are whether anyone has built a secured directory bind before, who will review the group mapping, who will rerun the tests after a Graylog upgrade, and how the team will recover if login fails during an incident. If those answers are unclear, a scoped review or a full implementation may be the better fit.

When should Graylog use trusted header authentication behind a proxy?

Trusted header authentication suits a setup where a reverse proxy or gateway already authenticates users and passes the identity to Graylog in a request header. The Graylog authentication documentation lists it under Graylog Open. The engineering risk is header spoofing: if a client can reach Graylog directly, it can send the header itself. The design must therefore ensure that only the proxy can reach the Graylog web interface and that the proxy strips any incoming copy of the header before it adds its own. Test this from outside the proxy path, and confirm the header names and role handling in the documentation for your version before you rely on it.

What recurring work follows a Graylog SSO setup?

Most of the cost is one-time: design, configuration, testing and handover. Recurring work includes certificate renewal for OpenID Connect or SAML and any secured directory connection, reviews of group membership and role mappings as people join and leave teams, and retesting after Graylog upgrades or changes to the identity provider. If you choose Enterprise for SSO, the subscription is a recurring cost priced on processed data, so volume growth changes the bill. Ask any provider to state which items are one-time, which are recurring, who owns each one after handover, and how each change will be tested and recorded.

How DeployOpen scopes, builds and hands over Graylog SSO

DeployOpen plans, builds and documents Graylog SSO inside your own infrastructure, matching the method to your edition: directory authentication and group to role mapping for Graylog Open, or Okta, OpenID Connect and SAML for Graylog Enterprise. Engagements are fixed-scope, with the written scope agreed before work starts.

How we scope

Confirm which Graylog edition you run, since Open and Enterprise support different single sign-on methods.
Inventory your identity provider, directory structure, and the groups that should map to Graylog roles.
Agree in writing which login paths, proxies, and fallback local accounts are in and out of scope.

How we build

Configure Active Directory or LDAP bind settings, search bases, and group to role mappings in a non-production Graylog first.
Set up trusted header authentication only where the reverse proxy strips and sets identity headers reliably.
Test login, role assignment, logout, and access to streams and dashboards with named test accounts before any cutover.

How we hand over

Deliver the mapping table, configuration records, and test results so your team can see which group grants which role.
Document the break-glass procedure and how to recover access if the identity provider or directory is unavailable.
Walk through change steps for adding groups, rotating bind credentials, and onboarding new users with your admins.

How we support

Ongoing support and upgrades are available as a retainer, covering changes to groups, providers, and Graylog releases.
Re-test authentication after each Graylog upgrade or identity provider change, using the agreed test accounts.
Your written scope defines what support covers, so ask for that scope and its response terms in your quote.