N-central authentication methods

N-central supports multiple authentication methods, giving you the flexibility to match your organization's identity management model whether you operate in a small IT environment, a large enterprise, or a multi-tenant managed services provider (MSP) model. These options range from basic local user credentials to advanced single sign-on (SSO) integrations using SAML or OpenID Connect (OIDC) as well as Microsoft Entra ID.

Each authentication method offers distinct benefits and trade-offs. Some prioritize ease of setup and direct control within N-central, while others provide centralized identity governance, seamless user provisioning, and the ability to enforce multi-factor authentication (MFA) policies from external identity providers. The authentication methods in N-central vary from basic to advanced:

  • Local authentication

  • LDAP or Active Directory authentication

  • OpenID Connect (OIDC)-based Federated Authentication (SSO)

  • N-able Login

  • N-able Login federated with Entra ID

Here is a breakdown of each available authentication method in N-central, including how it works, when to use it, and what security features it supports.

Local authentication

Local authentication means that user accounts, passwords, and login policies are managed directly within N-central. This is the simplest and most self-contained option.

How it works:

  • Admins create users in the N-central UI

  • Passwords are stored and validated by N-central

  • MFA can be enabled per user

Examples of use

  • Small MSPs or internal IT teams

  • Trial or evaluation environments

  • Isolated installations not integrated with external identity systems

Keep in mind

  • No centralized user management across platforms

  • Requires manual onboarding and offboarding

  • Limited to N-central only (not shared across other N-able tools)

LDAP or Active Directory authentication

With LDAP or Active Directory integration, N-central connects to your on-premises directory service. Users log in using their Windows domain credentials.

How it works

  • N-central is configured to communicate with an LDAP server (typically Active Directory).

  • User credentials are validated against the domain controller.

  • Group membership can control access roles in N-central.

Examples of use

  • Organizations using on-prem AD for internal IT identity

  • Environments where cloud IdPs are not used

  • Businesses with strict internal access policies

Keep in mind

  • Requires internal network access to AD

  • No built-in MFA (must be layered through other tools)

  • No support for SSO across other N-able products

OpenID Connect (OIDC)-based Federated Authentication (SSO)

This method enables Single Sign-On (SSO) by integrating N-central with a third-party Identity Provider (IdP) using OIDC. Users log in via the IdP, not directly into N-central.

How it works

  • N-central is configured as a Service Provider (SP).

  • The IdP (e.g., Legacy Azure AD, OKTA, Ping Identity, ADFS) handles user login.

  • The IdP returns an OIDC assertion that N-central validates.

  • Access is granted based on OIDC attributes and assigned roles.

Examples of use

  • MSPs or enterprises with a modern identity strategy

  • Organizations standardizing access via SSO and MFA

  • Environments requiring strong compliance or centralized access control

Keep in mind

  • Requires configuration on both N-central and the IdP

  • Misconfigurations can lead to login issues

  • Complexity increases with multiple tenants or nested roles

N-able Login

N-able Login is the N-able unified identity system used to access multiple N-able products (N-central, Passportal, Cove, etc.). It supports centralized authentication, SSO, and MFA out of the box.

How it works

  • Users sign in through the N-able Login portal

  • Credentials and MFA are managed by N-able

  • Role-based access is controlled per product

  • Admins manage users through the N-able portal

Examples of use

  • MSPs managing multiple N-able tools

  • Organizations transitioning to cloud-first identity

  • Customers who want built-in MFA and centralized control

Keep in mind

  • Users must be invited or migrated to N-able Login

  • MFA enforcement is per-user, not per-product unless configured centrally

N-able Login federated with Entra ID

This is a federated identity configuration where N-able Login delegates authentication to Microsoft Entra ID. It combines the benefits of N-able Login and enterprise SSO.

How it Works

  • N-able Login is configured to trust Microsoft Entra ID as a SAML Identity Provider

  • Users initiate login through N-able Login but are redirected to Entra ID

  • After signing in with their Microsoft 365 credentials, users are redirected back with a validated token

  • MFA and access policies are enforced by Entra ID

Examples of use

  • MSPs and enterprises using Microsoft 365 / Entra ID

  • Organizations requiring SSO + cross-product identity management

  • Businesses enforcing conditional access or Microsoft security baselines

Keep in mind

  • Initial configuration requires coordination between N-able and Entra ID

  • May need tenant-level configuration in multi-organizational setups