Enable SSO with Azure AD / Google

NetLock RMM supports single sign-on via OpenID Connect. This guide covers the two most common providers — Azure AD and Google — as two short sub-flows on the same configuration page. Before you start, read the four caveats below: SSO is the only area in the product where saving a settings change restarts the Console, and there are a few product rules that differ from what other RMMs do.

Before you start — four things to know

1. One provider at a time. Only one SSO provider can be enabled. Turning one on automatically turns the others off.
2. Users must be pre-provisioned. SSO login does not auto-create accounts. Every SSO user must already exist in Users with Auth Mode set to SSO or Password & SSO. The NetLock username must match the email claim the provider returns.
3. Saving restarts the Console. Confirming the save triggers an application restart and all active user sessions are terminated.

Required permissions for this guide: settings_enabled, settings_sso_enabled.

Pre-provision users first

1. Open Users in the navigation.
2. For every user who should sign in via SSO, open or add their account.
3. In the Add / Edit User dialog, set Auth Mode to SSO (SSO only) or Password & SSO (either method). Make sure the username matches the email address the identity provider will return as the email claim. For testing you might want to set it to Password & SSO in case you have to troubleshoot the SSO login to prevent locking yourself out.
4. Save.

If you skip this step, every SSO sign-in attempt is rejected with User is not authorized for SSO login. Please contact your administrator..

Azure AD — Steps

1. Register an application in Azure AD

In the Azure portal, register a new application for NetLock RMM. When asked for a redirect URI, assemble it as https://<your-console-host>/<callback-path> — the Console does not display this URI for you to copy. For Azure AD, the default Callback Path is /signin-oidc, so the redirect URI is typically https://<your-console-host>/signin-oidc.

Record the following values from Azure:

• Tenant ID.
• Application (Client) ID.
• A new client secret.

2. Configure the Azure AD tab in NetLock

1. Open Settings → SSO (route /settings/sso).
2. Switch to the Azure AD tab.
3. Toggle Enable Azure AD on. The info alert on the page reminds you that enabling one provider disables the others.
4. Fill in the required fields:
   • Instance — for example https://login.microsoftonline.com/.
   • Domain — for example your-domain.onmicrosoft.com.
   • Tenant ID — from the Azure portal.
   • Client ID — from the Azure portal.
   • Client Secret — from the Azure portal.
   • Callback Path — typically /signin-oidc.
   • Signed Out Callback Path — typically /signout-callback-oidc.
   • Response Type — typically code.
   • Save Tokens — optional, enable if downstream flows need the provider tokens.
5. Click Save.
6. A confirmation dialog warns: The web console will automatically restart after saving the SSO configuration. All active user sessions will be terminated. Do you want to continue?. Confirm.
7. The Console restarts. Wait a moment and sign back in — the SSO option should appear on the login page.

Google — Steps

1. Configure an OAuth 2.0 Client in Google Cloud

In Google Cloud Console, create an OAuth 2.0 Client ID of type Web application. Add an authorised redirect URI constructed as https://<your-console-host>/<callback-path> — for Google the default Callback Path is /signin-google, giving https://<your-console-host>/signin-google.

Record:

• Client ID.
• Client Secret.

If you want to restrict sign-in to a Google Workspace domain, note the domain name too.

2. Configure the Google tab in NetLock

1. Open Settings → SSO.
2. Switch to the Google tab.
3. Toggle Enable Google on.
4. Fill in:
   • Client ID — for example your-client-id.apps.googleusercontent.com.
   • Client Secret — from Google Cloud.
   • Callback Path — typically /signin-google.
   • Signed Out Callback Path — typically /signout-callback-google.
   • Hosted Domain (Optional) — the Workspace domain if you want to restrict sign-in, otherwise leave blank.
   • Save Tokens — optional.
5. Click Save, confirm the restart warning, and wait for the Console to come back up.

Verify it worked

• The Console's login page shows the SSO option for the provider you enabled.
• Signing in as a pre-provisioned user with the correct email claim succeeds and lands them on the Console.
• A user whose Auth Mode is Password only is rejected with the authorisation error above — this confirms the provisioning rule is active.

Troubleshooting

• Save is blocked by a licence dialog. Apply a valid paid licence first. Community / trial modes do not permit saving SSO configuration.
• Red alert SSO Configuration Error! on the page. The configuration failed to load on startup and SSO is disabled. Re-check all required fields on the active provider tab and re-save.
• User sees User is not authorized for SSO login. The account is missing, or its Auth Mode is Password only, or its username does not match the email claim. Fix in Users and have them try again.
• Redirect URI mismatch at the provider. The callback path you entered in NetLock must match the redirect URI you registered at the provider — path for path, including the leading /.

Related

• Appendix A.4 — Security: IP whitelist & SSO — the full reference for all five supported OIDC providers, IP-whitelist interaction, and per-user Auth Mode.
• Chapter 14 — Users & Roles — pre-provisioning accounts and setting Auth Mode.