starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

When LDAP is down, netbox does not allow to login via local super user #6775

New Issue
Closed
opened 2025-12-29 19:45:16 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:45:16 +01:00
Owner
Copy Link

Originally created by @m-ammar on GitHub (Aug 6, 2022).

NetBox version

3.2.7

Python version

3.9

Steps to Reproduce

Steps to reproduce:

  1. Deploy netbox-docker using the docker-compose file provided here: docker-compose.yml
  2. Provide LDAP env variables in the docker-compose file to setup LDAP.
  3. After netbox is up and running, block the connection between Netbox deployment and LDAP server using firewall.
  4. Then try to login with the local super user mentioned here: Super User

Expected Behavior

Netbox should allow local users to login even when connection to LDAP fails.

This is probably the issue: https://github.com/netbox-community/netbox/blob/develop/netbox/netbox/api/authentication.py#L28-L38

There is only a check for presence of LDAP and then try to login via LDAP. There should be a fallback to validate local users in case of connections errors to LDAP. Maybe another if condition?

Observed Behavior

The logion fails and netbox is not able to validate the local user until the connection to LDAP is restored.

Originally created by @m-ammar on GitHub (Aug 6, 2022). ### NetBox version 3.2.7 ### Python version 3.9 ### Steps to Reproduce ### Steps to reproduce: 1. Deploy netbox-docker using the docker-compose file provided here: [docker-compose.yml](https://github.com/netbox-community/netbox-docker/blob/release/docker-compose.override.yml.example) 2. Provide LDAP env variables in the docker-compose file to setup LDAP. 3. After netbox is up and running, block the connection between Netbox deployment and LDAP server using firewall. 4. Then try to login with the local super user mentioned here: [Super User](https://github.com/netbox-community/netbox-docker/blob/release/env/netbox.env#L39-L42) ### Expected Behavior Netbox should allow local users to login even when connection to LDAP fails. This is probably the issue: https://github.com/netbox-community/netbox/blob/develop/netbox/netbox/api/authentication.py#L28-L38 There is only a check for presence of LDAP and then try to login via LDAP. There should be a fallback to validate local users in case of connections errors to LDAP. Maybe another if condition? ### Observed Behavior The logion fails and netbox is not able to validate the local user until the connection to LDAP is restored.
adam added the type: bugstatus: under review labels 2025-12-29 19:45:17 +01:00
adam closed this issue 2025-12-29 19:45:17 +01:00
adam commented 2025-12-29 19:45:17 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Aug 6, 2022):

This is probably the issue: https://github.com/netbox-community/netbox/blob/develop/netbox/netbox/api/authentication.py#L28-L38

That's only for populating users when using the API, so that's not the source of your issue as you specify logging in. Netbox uses djangos AUTHENTICATION_BACKENDS and the normal local auth is always the second entry when using remote auth, so it should handle both auth backends, but maybe django-auth-ldap raises an exception that makes django skip the second auth for some reason.

I don't have time to check right now and wont have for a couple of weeks, but I'll look into it then if no one else has.

@kkthxbye-code commented on GitHub (Aug 6, 2022): > This is probably the issue: https://github.com/netbox-community/netbox/blob/develop/netbox/netbox/api/authentication.py#L28-L38 That's only for populating users when using the API, so that's not the source of your issue as you specify logging in. Netbox uses djangos [AUTHENTICATION_BACKENDS](https://docs.djangoproject.com/en/4.1/ref/settings/#std-setting-AUTHENTICATION_BACKENDS) and the normal local auth is always the second entry when using remote auth, so it should handle both auth backends, but maybe django-auth-ldap raises an exception that makes django skip the second auth for some reason. I don't have time to check right now and wont have for a couple of weeks, but I'll look into it then if no one else has.
adam commented 2025-12-29 19:45:18 +01:00
Author
Owner
Copy Link

@AzyCrw4282 commented on GitHub (Aug 9, 2022):

I actually attempted this yesterday and it worked fine for me. I am working on a task to verify a backdoor access (local/admin) account in the case our LDAP server goes down and the admin account worked fine. I simply blocked the LDAP server's IP on the route level and attempted to login via the admin account and it worked fine. LDAP account didn't work as expected.

Are you sure you are using a right password for the admin account? I reset my password through the Admin UI in Netbox before trying to login.

@AzyCrw4282 commented on GitHub (Aug 9, 2022): I actually attempted this yesterday and it worked fine for me. I am working on a task to verify a backdoor access (local/admin) account in the case our LDAP server goes down and the admin account worked fine. I simply blocked the LDAP server's IP on the route level and attempted to login via the admin account and it worked fine. LDAP account didn't work as expected. Are you sure you are using a right password for the admin account? I reset my password through the Admin UI in Netbox before trying to login.
adam commented 2025-12-29 19:45:18 +01:00
Author
Owner
Copy Link

@t8simon commented on GitHub (Aug 15, 2022):

I just tried it as well. The LDAP requests were blocked by the firewall.
Login in with the local super user was possible, but it took some time (didn't measure, but would say around 60s). Maybe the timeout period could be cut in half there.

@t8simon commented on GitHub (Aug 15, 2022): I just tried it as well. The LDAP requests were blocked by the firewall. Login in with the local super user was possible, but it took some time (didn't measure, but would say around 60s). Maybe the timeout period could be cut in half there.
adam commented 2025-12-29 19:45:18 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 15, 2022):

I'm going to close this out as it does not appear to be reproducible. If anyone can point to a specific change that might need to be made in NetBox, I'm happy to re-open this.

@jeremystretch commented on GitHub (Aug 15, 2022): I'm going to close this out as it does not appear to be reproducible. If anyone can point to a specific change that might need to be made in NetBox, I'm happy to re-open this.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: under review type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6775
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?