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

lost superuser / staff roles when logout with LDAP auth #2796

New Issue
Closed
opened 2025-12-29 18:22:14 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:22:14 +01:00
Owner
Copy Link

Originally created by @gismomtl on GitHub (Aug 7, 2019).

Environment

  • Python version:
  • NetBox version: v2.6.1 running in Docker.

Netbox is set with LDAP / ActiveDirectory Auth.
an LDAP account has been set to have superuser & staff rights as he's not part of the AD Groups set as staff/superadmin in the LDAP config.
While connected, its rights are working and he can logout.

As soon as he tried to login again, he lost its rights.. he has only Active rights.. but not superuser/staff.
It has been tested multiple times

Expected Behavior

it should keep the specific roles provided, and not reset to the default roles.

Observed Behavior

Originally created by @gismomtl on GitHub (Aug 7, 2019). ### Environment * Python version: * NetBox version: v2.6.1 running in Docker. Netbox is set with LDAP / ActiveDirectory Auth. an LDAP account has been set to have superuser & staff rights as he's not part of the AD Groups set as staff/superadmin in the LDAP config. While connected, its rights are working and he can logout. As soon as he tried to login again, he lost its rights.. he has only Active rights.. but not superuser/staff. It has been tested multiple times <!-- What did you expect to happen? --> ### Expected Behavior it should keep the specific roles provided, and not reset to the default roles. <!-- What happened instead? --> ### Observed Behavior
adam added the type: bugstatus: needs ownerpending closure labels 2025-12-29 18:22:14 +01:00
adam closed this issue 2025-12-29 18:22:14 +01:00
adam commented 2025-12-29 18:22:14 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Nov 17, 2019):

I'm not quite sure that this is a bug. Given the choice to get permissions for a remote user from the local database vs LDAP, using the latter would make more sense. After all, the remote user was created from LDAP.

For example, a user was accidentally given the superuser role when logging in for the first time via LDAP. Later on, the user is removed from the group mapped to the superuser role but – if the permissions are not updated in NetBox on every login – the user will continue to be a superuser.

My only suggestion to address this issue is to have the local database take precedence over LDAP if a user exists in both. Currently, this isn't the case; if LDAP is configured, the authentication attempt goes through LDAP first followed by local.
a2a83a4a4c/netbox/netbox/settings.py (L332)

If the order is changed to local then LDAP, you'll be able to create a local account for the user and manage their permissions locally. That way, local users -> local permissions, remote users -> remote permissions.

@jeremystretch What do you think? The change is pretty and I'm be willing to test the behavior.

@hSaria commented on GitHub (Nov 17, 2019): I'm not quite sure that this is a bug. Given the choice to get permissions for a remote user from the local database vs LDAP, using the latter would make more sense. After all, the remote user was created from LDAP. For example, a user was accidentally given the superuser role when logging in for the first time via LDAP. Later on, the user is removed from the group mapped to the superuser role but – if the permissions are not updated in NetBox on every login – the user will continue to be a superuser. My only suggestion to address this issue is to have the local database take precedence over LDAP if a user exists in both. Currently, this isn't the case; if LDAP is configured, the authentication attempt goes through LDAP first followed by local. https://github.com/netbox-community/netbox/blob/a2a83a4a4c76c13dec39ea9ac86d6b833a6e4f30/netbox/netbox/settings.py#L332 If the order is changed to local then LDAP, you'll be able to create a local account for the user and manage their permissions locally. That way, local users -> local permissions, remote users -> remote permissions. @jeremystretch What do you think? The change is pretty and I'm be willing to test the behavior.
adam commented 2025-12-29 18:22:15 +01:00
Author
Owner
Copy Link

@LBegnaud commented on GitHub (Nov 18, 2019):

But doesn't the user exist in local after logging in once, thus negating your first point, @hSaria ? Or are you saying to be additive with the permissions? I think that the source of truth should be in only one place (that is of course the netbox mantra, isn't it).

IMO, if LDAP is enabled then LDAP should define all properties.

@LBegnaud commented on GitHub (Nov 18, 2019): But doesn't the user exist in local after logging in once, thus negating your first point, @hSaria ? Or are you saying to be additive with the permissions? I think that the source of truth should be in only one place (that is of course the netbox mantra, isn't it). IMO, if LDAP is enabled then LDAP should define all properties.
adam commented 2025-12-29 18:22:15 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Nov 18, 2019):

It does create it in the database, but every time you login using the LDAP authentication backend, the user permissions will be updated.

For example, I went into the admin panel and unchecked my superuser permissions. As you can see, the database has reflected this change.

netbox=# select username, is_superuser from auth_user;
 username | is_superuser 
----------+--------------
 hSaria   | f
(2 rows)

I then relogged with LDAP which updated the superuser flag back to true as I'm in the LDAP group that maps to the superuser role.

netbox=# select username, is_superuser from auth_user;
 username | is_superuser 
----------+--------------
 hSaria   | t

I completely agree that if LDAP is enabled, it should be used; the whole point of the directory is to have a single place where you manage the memberships instead of chasing them around. The only reason I suggested changing the behaviour is to allow a locally-defined user to override an LDAP user. At the moment, that can't happen because LDAP takes precedence.

Personally, I would prefer that LDAP is preferred over local (the current behaviour) such that a user that exists in a local database and a central one would be forced with the latter in case their permissions get modified. The only reason I pitched this alternative approach is to solve this "bug."

As I said in my first comment, I wouldn't consider this as a bug. However, it was tagged with type: bug and so I wanted to attempt to "fix" this issue by having local authentication go first to allow an administrators to override what LDAP is doing.

If it was up to me, I would rather disable the ability to modify the permissions of remote users; their permissions live in the directory so manage it there.

@hSaria commented on GitHub (Nov 18, 2019): It does create it in the database, but every time you login using the LDAP authentication backend, the user permissions will be updated. For example, I went into the admin panel and unchecked my superuser permissions. As you can see, the database has reflected this change. ``` netbox=# select username, is_superuser from auth_user; username | is_superuser ----------+-------------- hSaria | f (2 rows) ``` I then relogged with LDAP which updated the superuser flag back to true as I'm in the LDAP group that maps to the superuser role. ``` netbox=# select username, is_superuser from auth_user; username | is_superuser ----------+-------------- hSaria | t ``` I completely agree that if LDAP is enabled, it should be used; the whole point of the directory is to have a single place where you manage the memberships instead of chasing them around. The only reason I suggested changing the behaviour is to allow a locally-defined user to override an LDAP user. At the moment, that can't happen because LDAP takes precedence. Personally, I would prefer that LDAP is preferred over local (the current behaviour) such that a user that exists in a local database and a central one would be forced with the latter in case their permissions get modified. The only reason I pitched this alternative approach is to solve this "bug." As I said in my first comment, I wouldn't consider this as a bug. However, it was tagged with `type: bug` and so I wanted to attempt to "fix" this issue by having local authentication go first to allow an administrators to override what LDAP is doing. If it was up to me, I would rather disable the ability to modify the permissions of remote users; their permissions live in the directory so manage it there.
adam commented 2025-12-29 18:22:15 +01:00
Author
Owner
Copy Link

@smk4664 commented on GitHub (Nov 19, 2019):

I agree with @hSaria, this does not look to be a bug. The resolution would be to add the user to the proper AD group.

@smk4664 commented on GitHub (Nov 19, 2019): I agree with @hSaria, this does not look to be a bug. The resolution would be to add the user to the proper AD group.
adam commented 2025-12-29 18:22:15 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 6, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Dec 6, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:22:16 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 13, 2019):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Dec 13, 2019): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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 pending closure status: needs owner 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#2796
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?