SSO / LDAP Issues

LDAP connection fails

If the LDAP test connection fails:

• Verify the server URL is reachable from the Vulnotes server (not just from your laptop). For on-premise deployments, the Docker container needs network access to the LDAP server.
• Check the port: 389 for LDAP, 636 for LDAPS
• For LDAPS, make sure the server's SSL certificate is trusted. Self-signed certificates may need to be added to the container's trust store.
• Verify the bind DN and password are correct. Try connecting with ldapsearch from the command line to isolate the issue.

LDAP login fails but test connection succeeds

The test connection only verifies the bind account. Login failures usually mean the search filter is not matching:

• Check the search base (e.g. ou=Users,dc=company,dc=com). If users are in a different OU, the search will not find them.
• Check the search filter. For Active Directory, (sAMAccountName=) is common. For OpenLDAP, (uid=) is typical.
• Verify the user is not in a disabled state in the directory.

SAML redirect loop

If clicking the SSO button redirects to the identity provider and then back to Vulnotes in a loop:

• Check that the callback URL configured in your IdP matches exactly what Vulnotes expects
• Verify the IdP certificate is correct and not expired
• Check the SAML assertion for attribute mapping issues. The email attribute must be present in the response.

Google OAuth "redirect_uri_mismatch"

This error means the redirect URI configured in the Google Cloud Console does not match the one Vulnotes is sending. Copy the exact redirect URI shown in the Vulnotes authentication settings page and paste it into the Google Cloud Console under Authorized redirect URIs.

User created with wrong role after SSO login

When a user logs in via SSO or LDAP for the first time, they are assigned the default role. An administrator needs to update their role manually in Administration > User Management after the account is created.