SSO / LDAP Issues

LDAP connection fails

Open Administration > Settings > Security, expand the LDAP configuration, and use Test.

• Verify the LDAP URL is reachable from the Vulnotes server, including from its Docker network.
• Check the port: commonly 389 for LDAP or 636 for LDAPS.
• For LDAPS, check that the directory certificate is valid and trusted by the server.
• Verify the bind DN, bind password, and search base.

LDAP test succeeds but login fails

The connection test checks the bind account, not a user's login. Confirm that the user is inside the configured search base and can authenticate to the directory.

Vulnotes matches the supplied username or email against uid, mail, and sAMAccountName. The current interface does not expose a custom search filter.

If the user has no Vulnotes account, check Auto-provision users and the license's available seats. If the account already exists, check that it is active and linked to this provider. An email match alone does not link an existing local account.

Google OAuth redirect mismatch

The Google application's authorized redirect URI must match the callback sent by Vulnotes, including protocol, host, and provider ID. The callback path is /api/auth/sso/callback/PROVIDER_ID. Ask your instance administrator to confirm the public backend URL used for your deployment.

User receives the wrong role

Each provider has its own Default role for newly provisioned users. Change it in that provider's configuration. Existing users keep their assigned roles; edit them in Administration > User Management.

A provider is missing

Google Workspace requires internet access and is hidden in offline editions. SSO is hidden on Air-Gap Workstation. SAML is not currently exposed in the administration interface.