ERPNext SSO and identity integration guide

Why ERPNext SSO needs a plan before the first login works

An ERP holds your general ledger, stock valuations, supplier bank details and payroll-adjacent records, so the question is not whether users can sign in with corporate credentials but who gets which access and how that access ends when someone leaves. ERPNext supports LDAP login against Active Directory or OpenLDAP through LDAP Settings, with SSL/TLS options and automatic mapping of LDAP groups to ERPNext roles at each login. It also supports Social Login Keys for Google, Microsoft and custom OAuth or OpenID Connect endpoints. The feature set is rarely the blocker, so the work is mostly access design.

The hard part is that a working login proves very little. Role mapping decides what a user can see and post, and a group that was granted for a reporting task can quietly carry accounting or stock permissions if the mapping is broad. Confirm which directory groups exist, who owns them, and which ERPNext roles and user permissions each one should produce before you test a single sign-in. Plan the mapping as a reviewed table, not as a side effect of the first successful test.

Deprovisioning depends on the source system. When LDAP or the OIDC provider disables an account, ERPNext will refuse that user at the next authentication, but sessions and API keys that already exist are a separate question. Ask your identity team how disablement works for contractors and service accounts, and decide whether ERPNext API keys issued to people or integrations need their own review cycle. Do not assume that removing a directory group removes every privilege the user already holds in ERPNext until you have tested it.

Local accounts remain a fallback. The Administrator account and any user created with a password inside ERPNext can still sign in when the directory is unavailable, which is useful during an outage and risky if forgotten. Decide who holds these credentials, where they are stored, how they are rotated, and under what conditions they are used, and record that decision before go-live. Check whether your deployment's password policy and two-factor settings apply equally to local and federated users.

The environment can change the options. On Frappe Cloud public shared benches, Server Scripts are not allowed, so any logic you wanted to place in a script for claim handling or group filtering must move to a custom app or an external service. From version 15, Server Scripts are disabled by default and need the server_script_enabled setting. Plan on ERPNext v15 or v16, since v14 reached end of life on January 31, 2026, and confirm the hosting model before you design the identity flow.

Which ERPNext settings and identity components are involved

Signing in to ERPNext touches several separate components, each with its own settings and owner. Knowing which one controls which decision makes the integration easier to build, test and hand over between teams.

LDAP Settings

LDAP Settings is the ERPNext configuration for logging in against Active Directory or OpenLDAP. It holds the server address, SSL/TLS options, the bind account, the search base, the user and group attributes, and the mapping of directory groups to ERPNext roles, which ERPNext applies at each login. Check the bind account's least-privilege scope and the TLS certificate chain before go-live. The identity team usually owns the directory side, and the ERP admin owns the role mapping.

Social Login Key records

Each Social Login Key record defines one external sign-in provider, such as Google, Microsoft or a custom OAuth or OpenID Connect server. It stores the provider name, the client ID and secret, the endpoints for custom providers, and the user creation behavior that decides whether an authenticated person gets a new ERPNext user. Confirm the redirect URI registered at the provider matches the site URL exactly. The identity team usually owns the provider application, and the ERP admin owns the record.

User and Role records

Every successful login results in a User record in ERPNext, with Role assignments that control what the person can open, create and approve. These records are the effective outcome of LDAP group mapping or social login, so they reflect the upstream configuration. Review them after the first sign-in tests, especially for users who receive roles they should not have. The ERP admin usually owns these records, with input from the business process owners who approve access.

Administrator account and System Manager role

The Administrator account is the built-in superuser that remains available when the identity provider is down or misconfigured. The System Manager role grants broad control over settings, users and customizations, so it should be assigned to a small group. Decide how the Administrator password is stored, who can use it, and how its use is logged before enabling single sign-on. The ERP admin owns this, with the infrastructure team often holding the emergency credential.

Frappe site configuration and Nginx

The site configuration controls the site URL, host name and related settings that the identity provider must match, and Nginx often terminates TLS in front of the Frappe site. Mismatched host names, missing forwarded headers or a wrong public URL are common causes of failed redirects and certificate errors during sign-in. Confirm the public URL, certificate and proxy headers against the provider's callback requirements. The infrastructure team usually owns this layer, in coordination with the ERP admin.

Which identity method fits your directory and risk profile

This table compares LDAP login, Social Login Keys and a custom OpenID Connect provider for ERPNext across fit, operational upkeep, certificate handling, deprovisioning, role mapping and emergency access. Read each row against where your user accounts live and how your offboarding process works, because the answer changes with that. The main takeaway is that the choice also decides where role decisions and offboarding evidence are kept, so confirm both before you pick a method.

Decision area	LDAP against Active Directory or OpenLDAP	Social Login Key (Microsoft or Google)	Custom OpenID Connect provider
Best fit	Existing Active Directory or OpenLDAP directory that staff already sign in to.	Staff whose accounts already sit in a Microsoft 365 or Google Workspace tenant.	Cloud identity provider or external users who need a standards-based sign-in.
Operational upkeep	Bind account rotation, search base and filter upkeep, and directory group changes.	Registering the app with the provider, managing redirect URLs and rotating client secrets.	Maintaining provider endpoints, scopes, claim names and mapping logic in ERPNext.
Certificates and TLS	Trust chain for LDAPS or StartTLS to domain controllers must be installed and renewed.	Public HTTPS on the ERPNext site, plus tracking of client secret expiry in the provider.	Provider signing key and metadata changes must be tracked. Confirm the key rollover process.
Deprovisioning	Disabling the directory account blocks new logins. Confirm how existing sessions and API keys end.	Disabling the provider account blocks sign-in, but the matching ERPNext user should also be disabled.	Depends on provider token lifetime and whether ERPNext checks account status at each login. Confirm.
Group to role mapping	Directory groups map to ERPNext roles at each login, so the directory drives role changes.	Roles are usually set inside ERPNext. Confirm whether a custom app is needed for group mapping.	Group claims can carry role data, but the mapping logic usually lives in a custom app you maintain.
Emergency access	Keep named local admin accounts, since a directory outage otherwise blocks every login.	Keep named local admin accounts, since a provider outage blocks social sign-in.	Keep named local admin accounts and confirm whether the provider is a single point of failure.

How to build ERPNext SSO in the right order

This sequence moves ERPNext from local passwords to directory or identity provider sign-in without locking anyone out. Each step ends with a check, so the team knows the previous layer works before the next one depends on it.

Confirm the ERPNext version and hosting model
Record the ERPNext and Frappe Framework versions in use, whether the site runs on Frappe Cloud, Docker Compose or a manual bench install, and where the public site address and TLS termination sit. Confirm that the version is on Frappe's supported versions list, because the LDAP and Social Login Key settings and the network path to the directory depend on the deployment. The step is closed when the team has a written record of version, hosting model, public URL and the host that will reach the directory.
Map directory groups to ERPNext roles
Export the directory groups that should grant ERPNext access, then work with each business owner to decide which ERPNext role or roles each group receives. Flag groups that would grant broad rights, and agree which users need a manual role instead. ERPNext applies LDAP group to role mapping at each login, so an unclear mapping becomes an access problem in production. The step is closed when a signed-off mapping table exists for every group, including the groups that grant no access.
Test directory bind and TLS from the ERPNext host
Create a dedicated bind account in the directory with read-only access limited to the search base needed for users and groups. From the ERPNext host itself, not a workstation, test that the directory server is reachable on the port for the chosen TLS mode and that the certificate chain is trusted by the host. Check the connection with the bind account and confirm that a search returns the expected test user. The step is closed when the bind and search succeed over the agreed TLS mode and fail cleanly with a wrong password.
Configure LDAP settings on a staging site
On a staging site that mirrors production versions and custom apps, configure LDAP Settings with the directory server, bind account, search base, user and group attributes, and the group to role mapping from the previous step. Log in with one test user per role and confirm the user lands with the expected roles and no extra permissions. Check that a user outside the mapped groups cannot sign in. The step is closed when every role has been tested with a real account on staging and the results are recorded.
Configure the OpenID Connect provider
If the organization uses an OpenID Connect or OAuth provider such as Microsoft or Google, or a custom identity provider, create a Social Login Key in ERPNext and register the application with the provider. Set the redirect URIs to match the public site address exactly, including scheme and path, and confirm the client secret is stored only in ERPNext and the provider. Test sign-in on staging with one user per role. The step is closed when the provider login completes, the redirect returns to the correct site, and the user session is tied to the expected ERPNext user.
Test first-login user creation and role assignment
Sign in for the first time with a user who has no existing ERPNext account, and confirm the account is created with the correct user type, roles and default settings. Repeat the test for a user whose group membership changes between logins, and confirm the roles update as expected. Record any user who is created with unintended access and fix the mapping before continuing. The step is closed when first-login creation and role updates behave as the signed-off table describes.
Confirm disabled directory accounts cannot log in
Disable a test account in the directory, then attempt to sign in through LDAP and through the OpenID Connect provider from a clean browser session. Check that ERPNext refuses the login and that any existing session or API key tied to that user is also revoked or unusable. Document how long a disabled account remains active in ERPNext if it has an active session, and how the team will end that session. The step is closed when a disabled account is refused on both login paths and the session behavior is written down.
Secure the local administrator and break-glass path
Keep the local Administrator account, set a strong password stored in the organization's vault, and enable two-factor authentication on it if the deployment supports it. Document who holds the break-glass credential, under what conditions it is used, and how use is logged and reviewed. Confirm that the local Administrator can sign in with the directory disconnected on staging. The step is closed when the break-glass login is tested and the custody and use procedure is approved by the security owner.
Roll out to production with a rollback plan
Schedule the production change after staging tests pass, and keep local password login enabled until directory and provider login have worked for real users in production. Prepare a rollback that disables LDAP or the Social Login Key without touching user data, and rehearse it on staging. Verify production with one test account per role, then the first real users in a monitored window. The step is closed when production login is confirmed for each role, the rollback has been rehearsed, and local login still works.

What drives the effort and how to keep it down

This table lists the factors that change how much work an ERPNext identity integration takes, and how to reduce each one. Read each row as a lever: the cost driver on the left, why it matters, and the step that keeps it contained. The main takeaway is that role mapping and the number of sites and directories cause most of the rework, so agree those before build starts.

Driver	Why it changes effort	How to keep it down
Directory groups and roles to map	Each LDAP group or identity provider group must map to an ERPNext role, and mismatches cause the largest share of rework and access reviews	Agree a short role catalogue up front, with a named owner for each ERPNext role and each source group
Number of identity providers or sites	Each site has its own LDAP Settings or Social Login Key configuration, testing and sign-in checks	Use one identity provider per site where possible and template the configuration for the rest
Directory type (Active Directory, OpenLDAP or cloud)	Active Directory and OpenLDAP use LDAP settings, while cloud providers need an app registration, redirect URIs and consent from the identity team	Confirm the directory type and the registration owner early, and request the app registration in the same change as the design
Certificate and TLS trust chains	LDAP over SSL/TLS and OpenID Connect endpoints fail when the internal certificate authority is not trusted by the ERPNext host	Install one standard TLS trust bundle on every environment and confirm it with a test connection before role mapping
Hosting constraints	On Frappe Cloud shared benches, Server Scripts are not allowed, so custom mapping logic may need a different hosting model or a custom app	Confirm the hosting model before design, and check whether custom mapping logic must run in a custom app on self-hosted or dedicated infrastructure
Custom mapping logic	Logic beyond standard group to role mapping needs code, testing and upgrade care in every new ERPNext release	Keep mapping rules declarative where possible, and package any custom logic in a version-controlled custom app
Environments (staging, production, disaster recovery)	Each environment needs its own redirect URIs, certificates, directory test accounts and sign-in tests	Write a test matrix once and run it in staging, production and disaster recovery with the same steps and expected results
Compliance evidence requirements	Assessors often ask for access approvals, role change records and proof of disabled leavers, which takes effort to collect	Define the evidence list at scoping and set up change tickets and log retention before go-live

How SSO differs across deployment models

On a single bench or server, ERPNext, the web process, Nginx and the identity connection all run on one host, so the login path is the simplest to trace. The main work is confirming that the host can reach the directory or identity provider and that the public hostname matches the redirect URL registered with the provider.

Outbound reachability: the host must reach the LDAP server on its configured port, or the OpenID Connect discovery, token and key endpoints over HTTPS.
Hostname and redirect URL: the site name, the public address served by Nginx and the redirect URL registered with the provider must match exactly.
TLS trust: the CA chain for the directory or identity provider must be trusted by the Python runtime that ERPNext uses, and the LDAP SSL/TLS options must be tested against it.
Group mapping scope: LDAP group to role mapping runs at each login, so confirm which groups the service account can read and which ERPNext roles they map to.

Run these checks on a staging bench first, because a single host gives no second node to fall back to during a failed change. Confirm with your platform team which host terminates TLS and whether a tested local administrator account exists for recovery.

How to lock down login, roles and secrets

Connecting ERPNext to a directory or identity provider moves trust decisions out of ERPNext and into systems you must also protect. The cards below cover the credentials, transport, storage, default access and offboarding paths that decide whether single sign-on actually narrows who can reach your ERP data.

Scope the LDAP bind account

ERPNext uses a bind account to query Active Directory or OpenLDAP for users and groups before it authenticates a login. Give that account read access only to the user and group objects ERPNext needs to map roles, and nothing that allows writes or password resets. Put it in a dedicated service account with a rotation plan your directory team has agreed, and confirm that a rotation does not silently break logins.

Require TLS for directory traffic

LDAP Settings in ERPNext offers SSL and TLS options, and a plain connection would send bind credentials and user passwords across the network. Require encrypted directory traffic on every path from the ERPNext servers to the directory. Where the directory uses an internal certificate authority, confirm the CA certificate is trusted by the ERPNext host and pin it if your environment requires it, then test that an expired or untrusted certificate fails closed.

Keep OAuth and bind secrets out of source

The OAuth client secret for Social Login Keys and the LDAP bind password must not appear in custom apps, fixtures, exported data or version control. Store them in the deployment's secret mechanism and limit who can open them in ERPNext, since database-stored credentials are visible to anyone with access to the relevant settings DocType. Ask who can read these records, and check that exports and backups are handled under the same restriction.

Default new users to minimal roles

When a user first signs in through SSO or is created by an administrator, the roles they receive should not grant access to accounting, stock or payroll data. Review the default role assigned to newly created users and any role mapping rule that could grant broad access from a single directory group. Test a login from a newly provisioned account in a staging site and confirm it reaches only the pages it should.

Protect the Administrator and break-glass accounts

The Administrator account and one local break-glass account keep ERPNext reachable if the identity provider or directory fails. Set long, unique passwords, store them in a sealed credential under dual control, and disable their use for routine work. Configure an alert on any login to these accounts, and test that the alert reaches a person who will act on it, not only a shared mailbox.

Confirm offboarding reaches ERPNext

A disabled directory account should stop ERPNext access, but a cached session or a locally created user can keep working. Disable accounts at the source, then sign in as that user to confirm the login is refused and the ERPNext user record is disabled or no longer mapped. Include contractors and service identities in the same test, since they are often provisioned outside the normal joiner and leaver process.

Review role mapping after group changes

ERPNext maps directory groups to roles at each login, so renaming, nesting or moving a group can grant or remove access without any change in ERPNext. Treat every change to a mapped group as a change to ERPNext permissions. Re-check the mapping table after each directory change, and compare the roles held by a sample of users before and after the change in a staging environment.

How to test that SSO works and fails safely

Test ERPNext SSO with a written matrix, and do not rely on one demonstration login. Every case needs an expected result agreed before the run, a recorded actual result and a sign-off from the people who own the directory and the ERPNext roles. The matrix covers both halves of the design: that the right people get in with the right access, and that everyone else is stopped. A successful login by the project sponsor proves very little about a contractor whose directory account was removed last month, or about a staff member in a group nobody mapped. Agree the scope of the matrix with the directory team before testing starts.

Start with each identity method you have enabled. For LDAP against Active Directory or OpenLDAP, configured through LDAP Settings, run a happy-path login and then one test account in each mapped group. Confirm that the roles each account receives match the group mapping document exactly, with no extra roles carried over from an earlier login. Add one account in no mapped group, one account that is disabled or removed in the directory, which must be blocked, one wrong-password attempt and one expired session. For each Social Login Key covering Microsoft, Google or a custom OpenID Connect provider, run a happy-path login with a user who should succeed and a user whose access should be refused.

Then test the failure modes that tend to go unnoticed. Stop the directory server, or block the network path to it, and record exactly what the login page shows a user. Confirm that the local admin path still works while the directory is unreachable. Present a TLS certificate whose name does not match the directory host, or whose chain your ERPNext server does not trust, and confirm the login fails without falling back to a weaker path. For the OAuth provider, change the redirect URI on either side so it no longer matches, and confirm the provider rejects the request. Record the exact wording of each message in your version, because error text can change between releases.

Two checks decide whether the design fails safely. First, the break-glass account must log in while the identity provider is down. Confirm that its password is held under your normal secrets control, that its use produces a log entry, and that someone reviews that log. Second, no user should reach the System Manager role through an unmapped group. Create a test account in a group that is absent from the mapping, log in, and inspect its roles. Then change a mapping and confirm that the change applies at the next login, since ERPNext maps groups to roles each time a user signs in.

Record each result against the ERPNext version, the Frappe version, and the identity settings in use, and keep the full matrix as part of the release evidence. Repeat the whole matrix after every minor upgrade in both supported major versions, because Frappe publishes minor releases often and authentication code can change in any of them. A pass on one release says little about the next. Ask whoever runs the tests for the complete pack: the matrix, expected and actual results, versions tested and sign-offs. Confirm with your auditor or assessor which evidence they expect, since they, not the test team, decide whether controls are adequate.

What to monitor, document and hand over after go-live

SSO problems often start quietly after go-live: a rotated secret, an expired certificate or a renamed directory group can lock out staff or assign the wrong roles without any change inside ERPNext. The cards below cover what the operations owner watches, what gets reviewed on a schedule, and what the next team needs in writing.

Failed logins and bind failures

Watch the ERPNext application log and the reverse proxy log for failed login attempts, repeated failures from one address, and LDAP bind failures that show the service account or its password is no longer accepted. Forward both logs to your central log platform and alert on bind failures, because they often appear before users report being locked out. Confirm with your security team which alert thresholds and log retention periods apply in your environment.

Certificate and secret lifecycle

Track expiry dates for the TLS certificate on the directory server, the certificate that the identity provider presents to ERPNext, and the ERPNext site certificate. Store the bind service account password and the OAuth client secret in a password vault with a named owner and a rotation date. After any rotation, update LDAP Settings or the Social Login Key, then test a login with a standard user account before closing the change.

Group to role mapping reviews

ERPNext applies LDAP group to role mappings at each login, so a directory change takes effect on the user's next sign-in. Review the mapping table on a fixed schedule set by your access policy, and again after any directory restructuring such as a renamed group, a moved organizational unit or a new department. Confirm that each mapped role still matches the access the business intends, and that every group that grants a role appears in the mapping table.

Break-glass access testing

Keep at least one local administrator account that does not depend on the directory or the identity provider, and store its credentials in a sealed record under dual control. Test the break-glass login on a schedule and after any change to SSO settings, confirming that the account still works and that its use raises an alert. Record each test and each use, and reset the credentials after any use.

Supported versions and minor upgrades

Confirm that the ERPNext and Frappe version in use appears on the supported versions list, since version 14 reached end of life on January 31, 2026 and version 15 is planned for support until the end of 2027. Both v15 and v16 receive frequent minor releases, including v15.123.0 and v16.51.1, released in October 2026. After each minor upgrade, rerun the SSO test matrix covering LDAP login, Social Login, group mapping and local admin access before accepting the change.

Handover documents for the next owner

Hand over a configuration record listing LDAP Settings, Social Login Key values with secrets removed, TLS settings and the identity provider application registration. Include the mapping table from directory groups to ERPNext roles, and a named owner for each component. Add a runbook for adding a group, covering the request, approval, directory change, mapping entry and test steps, and an offboarding procedure that disables the ERPNext user, reviews the user's document ownership and removes any shared credentials.

Questions teams ask before bringing in a partner for ERPNext SSO

What does ERPNext SSO integration cost and what drives the price?

Cost depends on the scope of identity work, not on an ERPNext license, since ERPNext is free under GPL-3.0 and self-hosting carries no license fee. The main drivers are the directory structure (one forest or several, nested groups, multiple domains), the number of roles that must map from groups, how many identity providers and environments need connecting (staging, production, possibly a second site), where ERPNext is hosted and what the hosting platform permits, and how much testing and evidence your compliance team needs. A fixed-scope quote should itemize each of these, state which environments are included, and separate one-time setup from any recurring support. Ask the partner to name what is excluded, such as ongoing directory changes or new provider onboarding.

How long does ERPNext LDAP or Social Login setup usually take?

No duration figure is fixed for this topic, so confirm timing during scoping against your own environment. The timeline is set mainly by how quickly your directory and identity provider admins can create the bind account, group list and app registration, how many roles need business sign-off, and how long the test window lasts in staging. A single LDAP directory with a small role set moves faster than a multi-provider setup with custom OpenID Connect endpoints. Ask for a schedule that shows which steps depend on your teams and which depend on the partner, and confirm when the break-glass account is tested.

What does our team need to provide before SSO work starts?

Plan for four inputs. Directory admins need to provide a bind account with read access and a list of the groups that should map to ERPNext roles. An identity provider admin needs to create the app registration and supply redirect details for Social Login Keys. A business owner must approve the role mapping, since each group decides who can see or change accounting, stock or production data. Finally, you need a scheduled test window in a non-production environment with real test users. Missing any of these is the most common cause of delay, so confirm ownership of each input in the written scope.

Can our internal IT team set up ERPNext SSO without a partner?

Yes, for a narrow case. An internal team can usually handle a single LDAP directory or one Social Login provider with a small set of roles, provided it can test against a staging copy of the site and owns the break-glass process. Break-glass means keeping a local administrator account that works when the identity provider is down, with its credentials stored and tested. A partner becomes more valuable when you have several providers, complex nested groups, custom OpenID Connect logic, or audit evidence to produce. Decide based on who will maintain the mapping after go-live.

Does ERPNext support LDAP and OpenID Connect without custom code?

Standard features cover many cases. ERPNext has LDAP Settings for Active Directory or OpenLDAP with SSL or TLS options and maps LDAP groups to ERPNext roles at each login. Social Login Keys support Google, Microsoft, GitHub, Facebook and Frappe, along with custom OAuth or OpenID Connect endpoints. Custom logic changes this picture. Examples include mapping attributes that the standard settings cannot express, provisioning users beyond login, or enforcing rules through Server Scripts, which in version 15 and later are disabled by default and cannot run on Frappe Cloud public shared benches. Confirm your hosting platform and version before choosing a design, and test the mapping with real group membership.

What should we get handed over at the end of an SSO engagement?

Expect a working configuration in each environment, a written record of the LDAP or Social Login settings, and the role mapping table with the business owner's sign-off. Good handover also includes the bind account and client secret ownership and rotation steps, the break-glass procedure with tested local admin access, test cases and results, and a runbook for common failures such as expired credentials or a group rename. Ask whether the scope includes knowledge transfer sessions and what evidence is produced for your compliance reviewers. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any audit report or certification.

What ongoing work follows ERPNext SSO go-live?

Recurring work is smaller than the initial build but not zero. Plan for credential rotation, updates when groups change in the directory, testing after ERPNext minor releases or major upgrades, and checks when the identity provider changes certificates or endpoints. The version 15 and 16 support windows and frequent minor releases mean SSO settings should be retested after upgrades. Ask the partner whether the quote covers any of this, and whether a support retainer or your internal team will own it.

How DeployOpen scopes, builds and hands over ERPNext identity work

DeployOpen plans, implements, integrates, hardens and documents ERPNext identity work inside your own infrastructure, covering LDAP login against Active Directory or OpenLDAP, Social Login Keys for Microsoft, Google or custom OpenID Connect providers, and local admin accounts. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.

How we scope

Map which users sign in through LDAP, which through OIDC or social login, and who keeps local accounts.
Confirm the directory structure, group names and the AD or OpenLDAP attributes used for login and role mapping.
Agree in writing the group to role matrix, TLS requirements and the identity provider's redirect and callback settings.

How we build

Configure LDAP Settings with SSL/TLS options and test bind, search and login against a staging ERPNext site.
Register Social Login Keys for each provider and link returned identities to the correct existing ERPNext user accounts.
Test role assignment at each login, including users who leave a group and should lose the matching ERPNext roles.

How we hand over

Deliver a written configuration record covering LDAP fields, provider settings, group mappings and redirect URIs.
Document the break-glass procedure for local admin accounts, including who holds credentials and how they are stored.
Walk your administrators through troubleshooting failed logins, certificate errors and role mapping mismatches.

How we support

Retest LDAP and social login settings after each ERPNext upgrade so identity flows keep working through the upgrade.
Offer a retainer for ongoing support when providers change, certificates renew or new user groups need updating.
Include login paths and session handling in security testing scope when you want them independently assessed.