Feature request: LDAP / Active Directory authentication support

[DevlTz]

Summary

I would like to request LDAP / Active Directory authentication support in LightNVR.

In my environment, several internal services authenticate against a local domain via LDAP/AD. For example, NetBox and other internal systems already use domain-based authentication.

LightNVR currently appears to rely on local database users/passwords. It would be very useful to allow users to authenticate using existing LDAP/AD credentials while still keeping LightNVR's local authorization model for roles and stream permissions.

Use case

I manage LightNVR in an environment with multiple users and teams.

Instead of manually creating and maintaining local passwords for each LightNVR account, I would like users to authenticate with their existing domain credentials.

This would improve:

• User management
• Password policy consistency
• Account lifecycle management
• Operational consistency with other internal services
• Security, since credentials would remain centralized in the domain

Suggested design

Add a configurable authentication provider.

Example:

[auth]
provider = local

Or:

[auth]
provider = ldap

Or possibly:

[auth]
provider = local,ldap

When LDAP is enabled:

1. The user enters username and password in the normal LightNVR login screen.
2. LightNVR attempts to authenticate the credentials against LDAP/AD.
3. If LDAP authentication succeeds, LightNVR creates or maps the user to a local LightNVR user record.
4. LightNVR keeps using its existing local authorization/session system.

Important requirement

LDAP should handle authentication only.

LightNVR should still manage authorization locally, including:

• Role: admin, user, viewer, api
• Stream tag restrictions / RBAC
• Allowed login CIDRs
• Account active/inactive status
• Sessions
• API keys
• TOTP/MFA settings, if applicable

This would allow LDAP users to authenticate with domain credentials while the LightNVR admin still controls what each user can access inside LightNVR.

Possible configuration fields

Example:

[ldap]
enabled = true
url = ldap://ldap.example.local:389
start_tls = true
bind_dn = CN=lightnvr-service,OU=Services,DC=example,DC=local
bind_password = change-me
base_dn = DC=example,DC=local
user_filter = (sAMAccountName=%s)
email_attribute = mail
display_name_attribute = cn
default_role = viewer
auto_create_users = true

For Active Directory environments, it would also be helpful to support:

[ldap]
user_filter = (sAMAccountName=%s)
group_filter = (member=%s)

Optional group mapping

It would be useful to map LDAP/AD groups to LightNVR roles.

Example:

[ldap_group_mapping]
CN=LightNVR-Admins,OU=Groups,DC=example,DC=local = admin
CN=LightNVR-Users,OU=Groups,DC=example,DC=local = user
CN=LightNVR-Viewers,OU=Groups,DC=example,DC=local = viewer

Potential future extension:

[ldap_tag_mapping]
CN=LightNVR-Tag-A,OU=Groups,DC=example,DC=local = tag-a
CN=LightNVR-Tag-B,OU=Groups,DC=example,DC=local = tag-b
CN=LightNVR-Tag-C,OU=Groups,DC=example,DC=local = tag-c

Backward compatibility

Local authentication should remain available, at least for the built-in/admin account, to avoid administrator lockout if LDAP is unavailable.

A safe model could be:

• Local only
• LDAP only with emergency local admin fallback
• Local + LDAP

Why this fits LightNVR

LightNVR already has a local user/session/role model. LDAP could be added as an authentication backend while preserving the existing authorization and session system.

The current system can continue to create LightNVR sessions after successful authentication, regardless of whether the password was verified locally or through LDAP.

Security considerations

• LDAP bind password should not be exposed in the UI or logs.
• Support LDAPS and/or StartTLS.
• Avoid logging user passwords or LDAP bind credentials.
• Keep local admin fallback to prevent administrator lockout.
• Consider LDAP connection timeouts and clear error handling if LDAP is unreachable.

[matteius]

I am willing to help review PRs around this or if sponsorship could be made I am willing to work on it. So far lightNVR is a cost leader for me, plenty have signed up for cloud to provision an instance and let it sit there for me to kill of later, and then no responses to my communications from those that filled out the interest form. My secondary concerns are that the LDAP support might further increase scope to not be "lightweight", so worth considering putting some of these things behind compile time flags if they end up being heavier weight or increase the size of binary for embedded devices.

[DevlTz]

Thanks for explaining the situation.

I’m sorry to hear that this has been frustrating. I can understand how discouraging it must be when people show interest, provision cloud instances, or fill out forms, and then stop responding. I appreciate the work you are putting into LightNVR and I do not want to add pressure without understanding the maintenance cost.

Your concern about keeping LightNVR lightweight makes sense. If LDAP/AD support is added, I agree it should not affect the default build. I think it should be optional and disabled by default, probably behind a compile-time flag such as:

ENABLE_LDAP=OFF

My idea would be to keep local authentication as the default and preserve the current local users, roles, stream tags, CIDR restrictions, sessions, API keys, and admin fallback. LDAP would only be used as an optional credential verification backend for environments that already rely on a local domain.

I would be interested in trying to work on a PR for this, starting small and keeping the scope limited. For example:

• Add an optional LDAP build flag.
• Add LDAP config fields only when LDAP support is enabled.
• Keep local auth unchanged.
• Add an LDAP authentication backend that can verify username/password.
• Map or auto-create LDAP-authenticated users into the existing local LightNVR user model.
• Keep local admin fallback to avoid lockouts.

Would you prefer this to start as a small auth backend abstraction first, with LDAP behind a compile-time flag and config-only support, before adding any UI changes?

[matteius]

@DevlTz thanks for offering to work on it -- yes I think what you describe makes sense and can be best applied as the groundwork PR first and we can go from there. Other auth providers such as Google SAML/SSO might be useful in the future so having it pluggable seems important.