How Proxmox VE SSO replaces local accounts with your directory
Proxmox VE authenticates users against Linux PAM, its built-in authentication server, LDAP, Microsoft Active Directory and OpenID Connect realms, so connecting it to your identity provider is a realm configuration plus a role mapping. The realm tells the cluster where to verify a password or token, and role assignments decide what an authenticated user may do on nodes, guests, storage and pools. Both halves matter: a working login with no role mapping gives people access to nothing, and a correct mapping on a realm that is misconfigured gives you a second, unmanaged login path. The work is harder than it looks because four settings interact. Realm options such as the directory server address, bind account, user search base and group attributes determine which identities exist in Proxmox VE at all. Group-to-role mapping determines what those identities can do, so a group that is too broad or a missing group quietly changes access. Lockout risk sits on the root account and the API paths: if the directory is unreachable or a mapping removes your own administrative rights, you may be locked out of the web interface and API tokens that automation depends on. Two-factor enforcement then adds a further condition on top of the realm. Each of these can work alone and still fail in combination, so test them together before cutover.
Before changing anything in production, confirm the exact screens, realm fields and permission options in the Proxmox VE administration guide for the 9.x release you run, since these details differ between versions. Ask whether the directory bind account needs read access only, which groups must be present, and how the root account and a break-glass local administrator will remain usable if the directory fails. Record these answers in the change plan. The software is the same across all subscription tiers, so the choice of realm and mapping does not depend on which support level you buy. A subscription changes support entitlements and access to the enterprise repository, not the authentication features. Your team can build and test the realm on a non-production cluster first, using a test directory group, before applying the same configuration to production nodes. Treat the first realm rollout as a controlled change with a rollback path. Keep a local administrator with a tested second factor, confirm that a leaver's directory account stops working in Proxmox VE, and check that an administrator without the right group is denied the actions you expect. These checks are the evidence that the integration removes local accounts as intended, and they should be repeated after every realm or mapping change.
Which Proxmox VE realms and login components are involved
Proxmox VE sign-in is handled by realms, each of which checks credentials against a different source. Users, groups, roles and two-factor settings then decide what an authenticated person can do, so these components need to be designed together before any directory is connected.
Linux PAM and built-in realms
The Linux PAM realm authenticates against local operating system accounts on the nodes, and the built-in Proxmox VE authentication server keeps accounts inside the platform itself. Both remain useful as fallbacks when the directory or identity provider is unavailable, which is why they are normally kept enabled. Check which accounts exist in each, who holds them, and that break-glass access is documented and tested before the external realms go live.
LDAP realm
The LDAP realm lets Proxmox VE verify users against a generic LDAP directory. Connection settings, bind credentials, encryption and the search scope determine whether lookups succeed and how much of the directory is exposed to the cluster. Confirm the exact field names and their behavior for your version in the user management wiki, and test with a non-administrative account first.
Active Directory realm
The Microsoft Active Directory realm is the realm most organizations with Windows identity use for Proxmox VE sign-in. It handles directory-specific account structures, so the domain controllers it reaches, the account used to query them and the base search location need review by the directory team. Confirm the supported options for your version in the user management wiki and check how disabled or locked accounts are handled.
OpenID Connect realm
The OpenID Connect realm delegates authentication to an external identity provider, so users sign in through the provider's own login and multi-factor flow. It requires an application registration at the provider, a redirect address that matches the Proxmox VE web interface, and a decision on which claims supply usernames and group names. Confirm the client settings and claim handling for your version in the user management wiki before relying on it for administrators.
Users, groups, roles and paths
Permissions in Proxmox VE are granted by assigning roles to users or groups on paths, such as the datacenter, a pool, or an individual VM or container. External groups can be mapped onto this model so that directory membership drives access, but the mapping must be designed rather than inherited from the directory. Review which roles are granted at the datacenter level, since they reach every node and guest in the cluster.
Second-factor options
Proxmox VE supports TOTP, WebAuthn, YubiKey OTP and recovery keys as second factors, and these apply to users of the platform's own login flow. Decide which accounts must enroll, who issues and stores recovery keys, and how lost hardware tokens are replaced. Confirm how enforcement and enrollment behave for your version in the user management wiki, and test recovery before administrators depend on it.
Proxmox VE SSO realm options and what each costs you to run
This table compares the built-in, LDAP, Active Directory and OpenID Connect realms against the conditions that favor each one and the operational work each adds. Read each row as a question to answer for your own directory before choosing a realm. The main takeaway is that every external realm adds a login dependency, so administrator access should stay on a separate path from general user access.
| Option | When it fits | Operational cost | If the provider is down |
|---|---|---|---|
| Built-in Proxmox VE realm | Small administrator group, break-glass access, or environments with no central directory to integrate | Local accounts are managed on each cluster, passwords and TOTP or WebAuthn enrollments are maintained by hand, and offboarding must be done in Proxmox VE itself | Unaffected by directory outages, so it is the usual fallback for administrators who need access during an identity incident |
| LDAP realm | Directory without Active Directory features, such as OpenLDAP or another LDAP-compatible service | A read-only bind account with a stored credential that needs rotation, TLS trust for the directory certificate on every node, and group mapping that must be kept current | Logins against that realm fail, while existing sessions and the built-in realm keep working, so confirm which accounts stay local |
| Microsoft Active Directory realm | Existing Active Directory forest where group membership already drives access to other systems | A service account with bind rights, certificate trust for LDAPS or StartTLS, and coordination with directory administrators on group naming and nested groups | Domain controller or network path failures block AD logins, so confirm reachability and which domain controllers Proxmox VE can reach |
| OpenID Connect realm | Cloud or federated identity provider that issues tokens and supports single sign-on across applications | Client registration and secret handling at the identity provider, redirect URI configuration for each cluster name, token lifetime settings, and certificate trust for the provider endpoint | Every login depends on the identity provider, so an outage or expired client secret blocks all realm users until fixed |
| Break-glass built-in account | Any production cluster, kept as a separate administrator path that does not depend on an external provider | Stored credential and second factor held offline, periodic test logins, and a documented procedure for who may use it and when | Remains available when external realms fail, provided its password and second factor are still known and the node is reachable |
| Separate admin and user realms | Organizations that want administrators to authenticate through a stronger path than general users | Two authentication paths to document, monitor and review, plus role mappings for each realm | Limits the blast radius of a provider outage to general users while administrators keep a controlled route to recover |
How to set up a Proxmox VE SSO realm step by step
This sequence connects Proxmox VE to LDAP, Active Directory or OpenID Connect in an order that proves each layer before the next one depends on it. It ends with directory-backed users, least-privilege group roles and a tested local recovery path.
Confirm directory prerequisites before changing Proxmox
Your directory team or identity provider administrator prepares the inputs: a read-only service account for LDAP or Active Directory, a group structure that matches the roles you plan to grant, and TLS trust so Proxmox VE can validate the directory certificate. For OpenID Connect, register the Proxmox VE web interface address as a redirect URI with the provider, and confirm the exact value against the user management documentation for your version. Done means a Proxmox node can reach the directory, bind with the service account, and list the expected test groups. Record these values in a build sheet before continuing.
Create the realm on a test node first
On a single test node, or on one node of a test cluster, create the LDAP, Active Directory or OpenID Connect realm under the datacenter permissions section using the values from the first step. On a single node, the change applies only to that host. On a multi-node cluster, realm configuration replicates to every node through the Proxmox Cluster File System, so the test covers the whole cluster, but you still confirm the login screen works from more than one node's web interface. Done means the realm shows as configured and a test bind or redirect completes without error.
Configure default and sync options
Set the realm's default behavior: whether it is the default realm on the login screen, the base and user search paths, the attribute used as the username, and the sync options for group membership and user attributes. Decide how users removed from the directory are handled, and confirm that behavior in the documentation for your version. Limit the first sync to test users, run it, and check the resulting user list. Done means the expected test users and groups appear with the correct usernames and no duplicate accounts from the built-in realm. On a cluster, run the sync once, because the results are shared across nodes.
Map directory groups to roles on specific paths
Grant permissions by assigning directory groups to Proxmox VE roles on specific paths, such as a test pool or a test range of guest IDs. Create one group per job function, for example a read-only auditor group and a virtual machine operator group, and assign the narrowest built-in role that covers the work. Avoid granting on the root path during testing. Done means a member of the operator group can manage guests in the test pool and sees no other pools. Document every group, role and path pair, because reviewers will ask for that mapping during access reviews.
Test non-admin login and denied actions
Sign in as a test user in the operator group and as a test user who belongs to no mapped group. The operator should complete the allowed actions on the test pool, such as starting a test container. The user with no group should be refused access or see no resources. Next, attempt an action outside the operator's role, such as changing a node network setting, and confirm it is denied. Repeat one allowed call through the API with the same user, because automation runs under the same permissions. Done means each allowed action succeeds, each denied action returns a permission error, and results are written into the test record.
Enable and test second factors
Enable second-factor authentication for administrator accounts and test users, choosing among TOTP, WebAuthn and YubiKey OTP according to your identity policy and the factors your version supports. Confirm whether enforcement will happen in Proxmox VE, in the identity provider's multi-factor policy, or in both, because the answer determines where a future change could weaken protection. Test a first login that prompts for enrollment, a login with the registered factor, and a login using a recovery key. Done means a user without a registered factor is prompted to enroll, and a login without the factor is refused.
Keep a local break-glass administrator
Create a local administrator in the Proxmox VE built-in realm, with a strong password held in a sealed record and a hardware security key kept separately from daily admin devices. Store the recovery keys under the same access controls, and write a procedure that names who may invoke the account, how it is logged, and who is notified. Test the break-glass login from outside the normal admin workflow, then confirm it still works while the directory-backed admin path is disabled in the test environment. Done means the local account logs in, the procedure is approved, and the recovery keys are verified. Repeat this review whenever directory or identity provider settings change.
How group sync maps directory groups to Proxmox VE roles
Group sync is the point where your directory decides who can do what in Proxmox VE. The model has three parts: a directory group or an OpenID Connect claim identifies a set of users, Proxmox VE grants that set one or more roles, and each role applies to a path such as the datacenter root, a resource pool or an individual node. Permissions are therefore only as narrow as the combination of group, role and path you configure. Before you touch the realm settings, write down which groups will exist in the directory, which roles each one needs and where on the path tree those roles apply.
Apply least privilege at every step. Map each directory group to the narrowest built-in or custom role that covers its work, and avoid assigning the Administrator role through a broad group such as all IT staff or every member of a domain admins style group that exists for another purpose. Keep the people who run virtual machines separate from the people who administer the cluster or the authentication realms. A VM operator who can start, stop and console guests in one pool does not need rights to edit realm settings, create users or change cluster membership. Review these mappings with the owners of each group, because a group that was harmless in the directory can become a privileged path once it is connected to Proxmox VE.
Removal is the part most teams test last and should test first. When a user leaves a directory group, the access they gained through that group should disappear at the next sync, and any access granted directly to the user in Proxmox VE should be reviewed separately. Confirm this in your own environment with a test account: remove it from the group, wait for the sync or trigger one manually, then check the effective permissions in the web interface and through the API. Sync frequency, handling of deleted users and the behavior of group membership changes depend on the realm settings and the Proxmox VE version you run, so do not rely on documentation alone or on a result from a different cluster.
API tokens for automation are a separate identity path and must be reviewed on their own. A token carries its own permissions and does not disappear when the directory account that created it is disabled, so a removed employee's script can keep working. List every token, its owner, its role and its path, decide who approves new tokens and set an expiry or review date where your process requires one. Also confirm which of your directory groups can create tokens at all. Treat token scope the same way as group scope: a token that manages one pool should not hold rights across the datacenter.
What drives SSO effort and cost in a Proxmox VE project
This table lists the factors that change how much work an LDAP, Active Directory or OpenID Connect integration with Proxmox VE takes. Read each row as a question to answer in your own environment before asking a partner for a scope. The main takeaway is that a small role catalogue, one identity source for administrators and a test cluster usually reduce effort more than any other choice.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of realms and identity providers | Each LDAP, Active Directory or OpenID Connect realm needs its own connection settings, sync behavior, test logins and fallback plan. Mixed sources multiply the checks. | Limit realms to the identity sources that are truly needed. Keep one identity source for administrators and treat others as exceptions. |
| Directory complexity (nested groups, multiple domains or forests) | Nested groups, cross-domain membership and multiple forests affect how group names map to Proxmox VE roles and how far the search base must reach. | Map a small set of flat, well-named groups to roles. Confirm group structure with the directory owner before design starts. |
| Number of roles and paths to design | Every role and permission path needs a definition, a test and a reviewer. Custom roles on many paths grow the review set quickly. | Start from a small role catalogue covering administrator, operator and read-only use. Add roles only when a documented need exists. |
| Two-factor policy scope for administrators | Enforcing TOTP, WebAuthn, YubiKey OTP or recovery keys for some realms or groups requires enrollment, recovery procedures and help desk steps. | Apply two-factor enforcement to the administrator realm first. Confirm which second factors your help desk can support. |
| Existing Proxmox VE version | Proxmox VE 8 reached end of life in August 2026 according to the Proxmox VE FAQ. If the cluster runs an unsupported release, a major upgrade may need to happen before SSO work starts, and the two efforts should be scoped separately. | Confirm the installed version and Debian release. Ask for the upgrade and SSO work to be quoted as separate components. |
| Number of clusters and environments | Each cluster and each environment (test, pre-production, production) needs its own realm configuration, role mapping and verification run. | Build and prove the configuration on a test cluster, then reuse the same documented settings in other environments. |
| Need for compliance evidence | Assessors usually expect records of configuration, role assignments, access reviews and two-factor settings. Collecting and retaining this evidence adds documentation and review time. | Export configuration and role lists as part of the build. Agree the evidence list with your assessor before work begins. |
| Effort figures and quotes | Effort figures should come from a written scope that states assumptions, environments and included components. | Ask for effort estimates by component (realm setup, role design, two-factor enforcement, testing, documentation and handover). |
Enforcing two-factor authentication for Proxmox VE administrators
Single sign-on moves Proxmox VE authentication to a directory or identity provider, which also moves the risk to the places where those logins are verified and configured. The cards below cover the identity-specific controls that protect administrator accounts, from second factors and recovery keys to the bind credentials, client secrets and realm settings that sit behind every login.
Require second factors for privileged roles
Proxmox VE can enforce TOTP, WebAuthn, YubiKey OTP or recovery keys as second factors, but the requirement has to be set for the accounts and roles that hold high privilege, such as Administrator and roles that can manage realms or permissions. Confirm which users in each realm are exempt from the second factor and why. Check the enforcement by signing in as a privileged user from a clean browser session and confirming the second factor is requested.
Choose the second factor method
TOTP works with most authenticator apps and needs no special hardware, while WebAuthn and YubiKey OTP bind the login to a physical key and resist phishing better. Decide per role which methods are allowed, and confirm which hardware keys your browsers and administrators actually use. Avoid a method that administrators cannot use from their own devices, because that pushes them toward shared workarounds.
Protect recovery keys like root credentials
Recovery keys let an administrator regain access when the primary second factor is lost, so anyone holding one can bypass the protection it supports. Store them in the same vault, with the same access approval and rotation rules, as the root password and the break-glass procedure. Record who generated each set and confirm that old sets are revoked when an administrator leaves or loses a device.
Guard LDAP bind and OIDC client secrets
The LDAP bind account and the OpenID Connect client secret let Proxmox VE query your directory or exchange tokens with your identity provider, so they are high-value credentials. Use a dedicated, read-only bind account with the narrowest directory scope that group sync needs, and keep the secret out of shared documents and tickets. Plan a rotation date for each and confirm that rotating them does not break logins for existing sessions.
Verify TLS trust for directory connections
An LDAP or Active Directory realm that accepts an untrusted certificate can let an attacker on the network impersonate the directory and capture bind credentials. Configure the realm to validate the server certificate against your internal certificate authority, and test with a certificate that is not trusted to confirm the connection is refused. For OpenID Connect, confirm the issuer URL and certificate chain match the identity provider you expect.
Limit who can change realm configuration
Anyone who can edit a realm can change the directory server, the default group mapping or the second factor policy, which can grant access without touching a single user account. Restrict realm and permission management to a small named group, and keep that group separate from day-to-day virtual machine administrators. Review changes to realm settings against a change record so a silent edit does not go unnoticed.
Audit role assignments and realm changes
Group sync and role assignments determine who can administer the cluster, so they need a recurring review, not only a setup check. Export the current permission assignments and compare them with directory group membership on a fixed schedule, and note any group that grants administrator rights by default. Confirm where Proxmox VE logs authentication and permission changes in your environment, and that those logs reach your central log store.
How to test Proxmox VE SSO logins and fail-safe access
Test every identity path before any realm becomes the way administrators sign in to Proxmox VE. The goal is to prove two things: the directory integration grants exactly the access the design intends, and a failure in that integration never removes every way into the management interface. Write this test plan into the scope, and have the security owner sign off the acceptance criteria before testing starts, so that a pass means the same thing to everyone who reviews it. Build a login matrix with one row per realm in use. That means the Linux PAM and Proxmox VE authentication server realms if they remain enabled, plus each LDAP, Active Directory or OpenID Connect realm. For each realm, include a test user inside each mapped group and a test user outside every mapped group. Confirm that inside users receive the roles you mapped to their group, and that outside users either get no access or only the default role you chose. Record the realm, the group mapping, the role granted and the pool or path it applies to, so a reviewer can trace each result back to a permission decision.
Add the exception cases that most often break in production. Test an administrator with two-factor authentication enrolled and one without, and confirm that the second factor is enforced for the roles that require it. Test a disabled directory account and confirm that Proxmox VE refuses the login, not just the next directory sync. Remove a test user from a mapped group, wait for the next synchronization, and confirm the role is withdrawn. Finally, present an expired or deliberately wrong bind password or client secret to the realm, and confirm that the failure is logged and that no cached session survives longer than your policy allows. Record how the directory sync interval affects each of these results, since a removal may take effect only at the next sync.
Test a directory outage deliberately, by stopping or blocking access to the LDAP or Active Directory server, or by making the identity provider unreachable for OpenID Connect. Confirm that the failed realm does not lock out every administrator. Local accounts in the Proxmox VE authentication server realm and the designated break-glass account should still sign in, and their permissions should still work on the nodes they are meant to manage. Before any enforcement change goes live, including requiring two-factor authentication for all administrators or disabling a legacy realm, confirm that the local break-glass account, its password and its recovery keys work end to end. Store the recovery keys under the same controls as other privileged credentials and record who can retrieve them.
Turn the matrix into acceptance criteria. Each row should have an expected result, the observed result, the evidence (for example, a screenshot of the permissions page, a login log entry or a Proxmox VE task log entry) and the tester. Confirm with the security owner that the criteria cover every realm in scope and that any gap is recorded as an accepted risk with an owner. Ask your implementation partner or internal team to confirm which Proxmox VE release and realm options your environment uses, since login behavior and available second factors should be checked against that version's documentation rather than assumed from this plan.
What to review, document and repeat after SSO goes live
This sequence keeps Proxmox VE sign-in through LDAP, Active Directory or OpenID Connect correct after go-live, by checking role mappings, log signals, credentials, recovery paths and documentation on a fixed rhythm. Each step ends with a record that shows the check was done.
Review group-to-role mappings on a set schedule
The Proxmox VE administrator and the directory owner compare each realm's group mappings against the current role catalogue, on a schedule the team sets in its access policy and again after any directory reorganization, such as renamed groups, moved accounts or retired OUs. Confirm that every mapped group still exists, that no group grants more than its intended role on a path, and that disabled accounts no longer hold active sessions. Done when the review record lists each mapping, its owner, the date reviewed and any changes made.
Monitor failed logins and realm errors
The Proxmox VE administrator reviews authentication failures and realm errors in the Proxmox VE system logs, and the directory team reviews bind failures and account lockouts in the directory logs for the same time windows. Look for repeated failures against one account, bind errors after a password or certificate change, and OpenID Connect callback errors after a client change. Set up alerts for these patterns where your monitoring stack allows it, and confirm which log sources your team can retain and search. Done when the team has a written list of recurring error types, the response for each, and a named owner for the review.
Rotate LDAP bind and OpenID Connect secrets
The directory team and the Proxmox VE administrator rotate the LDAP bind account password and the OpenID Connect client secret under the team's credential policy, using a planned change window. Update the realm configuration, test a fresh sign-in with a non-administrator account, and then revoke the old secret or password. Store the new values in your approved secrets vault and record who performed the change. Done when a test login succeeds on each realm, the old credential no longer authenticates, and the change record is filed.
Retest break-glass access and recovery keys
The administrator confirms that the local break-glass account and the stored recovery keys for second-factor enrollments still work, without relying on the directory being available. Test that the break-glass path can sign in while the external realm is intentionally unreachable in a non-production copy or during a planned window, and confirm that the recovery keys are stored in the correct custody. Record which keys were tested, when, and who witnessed the test. Done when the test result is recorded and any gaps are assigned to an owner with a deadline set by your team.
Document realm settings, role catalogue and owners
The platform owner writes down the configuration of each realm, including server addresses, base distinguished names or issuer URLs, attribute and group mappings, default realm for sign-in, the role catalogue with its privileges, and the enforcement policy for two-factor authentication on administrators. Name an owner for each realm, each mapping group and each role. Store the document under change control with the Proxmox VE configuration backup reference. Done when a second administrator can rebuild the realm and role setup from the document without asking the original author.
Re-run the verification matrix after each change
After each Proxmox VE upgrade and after each change in the identity provider, such as a new directory forest, a changed token claim or a new OpenID Connect client, the team re-runs the verification matrix it built during rollout. The matrix covers sign-in for each realm, group-to-role outcomes for test accounts in each group, two-factor enforcement for administrators, API token behavior and the break-glass path. Done when every row of the matrix has a dated pass or a logged defect, and no realm is left unverified after the change.
Check support and repository terms against these tasks
If your organization has chosen a Proxmox VE subscription, the platform owner reviews the enterprise repository access and support tier against this list of recurring tasks. Confirm that the enterprise repository is the one used for production updates, that the support tier and ticket allowance match the response expectations in your operating model, and that the support path covers identity-related incidents. Ask the vendor to confirm current tier terms in writing, since pricing and entitlements can change. Done when the review confirms which tasks are covered internally, which need vendor support and who owns each.
What buyers ask before bringing in Proxmox VE SSO help
Can our own team build Proxmox VE SSO without an outside partner?
Yes, if your team has two things: directory skills (LDAP or Active Directory administration, and OpenID Connect provider configuration) and Proxmox VE administration experience, plus a test cluster where changes can be tried before production. Proxmox VE supports Linux PAM, its built-in authentication server, LDAP, Microsoft Active Directory and OpenID Connect realms, so the configuration itself is well documented. The harder parts are group design, role mapping and testing login failures, lockouts and administrator recovery. If any of those skills are thin, a partner is most useful for the design and test steps, and your team keeps ownership of the directory.
Skills to confirm: directory administration, Proxmox VE roles and permissions, and a non-production cluster that matches production.
Do we need a Proxmox VE subscription to use SSO?
No. All Proxmox VE subscription tiers include the same software features, so SSO, group-based permissions and two-factor options are not locked behind a paid tier. Subscriptions differ in support entitlements and access to the enterprise repository, which Proxmox recommends for production. The software itself can be run without a subscription, but that means using the no-subscription repository, which is described as suited to testing and non-production use. Whether that fits your change control and patching policy is a decision to make before the project starts, and it should be confirmed against current terms on the Proxmox pricing page.
What drives the cost and timeline of an SSO project?
The main drivers are the number of identity sources, how many groups and roles must map to Proxmox VE permissions, how many clusters and nodes need the change, and how much of the directory design is already settled. Cost comes from the time of the people doing the work: someone must review the directory structure, design the realm and group mapping, build it in a test environment, test login and failure cases, and hand over documentation. Work is quicker when group membership is clean and owners are available for sign-off. It slows down when directory data is inconsistent or when several teams must agree on who gets administrator rights. Ask any partner to split the quote into design, build, test and handover.
What does the client need to provide for SSO implementation?
Plan to provide directory access, service accounts for binding, a group design that defines which directory groups map to which Proxmox VE roles, a non-production Proxmox VE cluster for testing, and named sign-off owners for identity and for the platform. Service account rights should be limited to reading what Proxmox VE needs. Confirm early whether you use LDAP, Active Directory or OpenID Connect, because each path needs different details such as base distinguished names, attribute names, client registration and redirect URIs. Having a recovery path, such as a local administrator account protected by a second factor, is also a prerequisite.
How do fixed-scope engagements define deliverables before work starts?
DeployOpen's engagements are usually fixed-scope, which means the scope, deliverables and timelines are agreed in writing before work begins. For SSO, a written scope normally names the identity sources in use, the realms to configure, the group-to-role mapping, the two-factor requirements for administrators, the test cases to run, the documentation to hand over and the clusters covered. Anything not listed, such as additional realms or clusters added mid-project, should be handled through a written change. Read the deliverable list closely and confirm who signs off each item, because that is where disagreements usually start.
What should we ask a partner to include in an SSO quote?
Ask for a quote built from a written scope, not a per-hour estimate with no boundaries. It should list the identity sources and clusters in scope, the group and role design work, the build steps in test and production, the test cases including failed logins and lockout recovery, the documentation and knowledge transfer, and what the client must supply. Ask which items are one-time work and which recur, such as periodic reviews of group mappings or two-factor enrollment support. Also ask how changes to scope are priced and approved. DeployOpen does not publish a price list, so a quote follows from the agreed scope.
Does enforcing two-factor authentication for administrators affect SSO design?
Yes. Proxmox VE supports TOTP, WebAuthn, YubiKey OTP and recovery keys as second factors, and the choice affects enrollment, helpdesk load and recovery planning. Decide which administrator roles require a second factor, how users enroll, and who can reset a factor when a device is lost. Test the recovery path before enforcement, including the break-glass account that works if the identity provider is down. Enforcing the factor too early, before enrollment is complete, is a common cause of locked-out administrators.
How DeployOpen scopes, builds and hands over Proxmox VE SSO
DeployOpen connects Proxmox VE to the identity provider you already run, whether that is LDAP, Microsoft Active Directory or an OpenID Connect provider, inside your own infrastructure. We start from a written scope that names the realms, group mappings, roles and second-factor policy for your administrators, then build, test and document the integration so your team can operate it after handover.
How we scope
- Inventory the identity sources, directory groups and users who need Proxmox VE access before any configuration begins.
- Map each directory group to a Proxmox VE role and path, so permissions follow least privilege rather than shared administrator accounts.
- Agree in writing which realm types, fallback local accounts and two-factor methods are in scope, and what is excluded.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts. Ongoing support is available as a retainer.
How we build
- Configure LDAP, Active Directory or OpenID Connect realms on a non-production Proxmox VE cluster first, then move the settings to production.
- Test group sync and role assignment with named pilot accounts, confirming that each group grants only the intended permissions.
- Enforce two-factor authentication for administrators using the methods your policy allows, such as TOTP, WebAuthn or YubiKey OTP, with recovery keys handled under documented control.
- Verify login, token expiry and lockout behavior against the identity provider, and record the results as test evidence.
How we hand over
- Deliver a configuration record covering realm settings, bind accounts, group-to-role mappings and two-factor enrollment steps.
- Walk your administrators through the login flow, role model and the procedure for adding or removing directory groups.
- Document a break-glass procedure for local administrator access if the identity provider is unavailable, and confirm who holds it.
- Hand over the test scripts and checklists so your team can repeat the verification after upgrades or directory changes.
How we support
- Review realm and role configuration after each Proxmox VE upgrade, since authentication behavior should be retested on every new release.
- Track changes to directory groups and OpenID Connect client settings so access stays aligned with your joiner and leaver process.
- Confirm with your identity team how certificate renewals, bind account password rotation and provider changes will be handled.
- Ask your Proxmox subscription provider which support tier you need, because subscription support and DeployOpen support are separate.
