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

Improve handling of password-less (remote) users #8481

New Issue
Closed
opened 2025-12-29 20:37:16 +01:00 by adam · 5 comments
adam commented 2025-12-29 20:37:16 +01:00
Owner
Copy Link

Originally created by @pv2b on GitHub (Aug 17, 2023).

NetBox version

v3.5.8

Feature type

New functionality

Proposed functionality

The proposed functionality is to improve handling of password-less users by:

  1. Allowing an administrator to remove a password for a user where a password already exists (similar to the /admin/auth/user/ID/change view)
  2. Adding a column to the /admin/auth/user view to easilly be able to audit which users have local passwords set.
  3. Disabling the "password" tab on the /user/profile/ view for users that have no password set. (And thus are unable to change it.)

Use case

As previously discussed in FR #11672, it is a commonly requested scenario to want to restrict the use of local authentication, for organizations that are using SSO. The Netbox development team have responded that they will not be adding an option to completely disable local authentication or the login form. Instead, the intended solution for an administrator desiring this kind of setup is to disable or remove all locally defined accounts.

(Note: A local account is created whenever a user first signs in with a social account, however, local login is prevented by the fact that this user has no password set.)

In order to better support that scenario, there are a few gaps in the current setup:

  1. If a local user was created, and then was subsequently associated with a social user, that user will have a password, and there is no way to remove that password through the UI, once it's been set. For the use case where users were initially created in Netbox, but then are migrated over to SSO, it'd be useful to be able to remove their passwords, after the fact, thereby forcing those users to log in through SSO in future, without breaking any history.

  2. For purpose of security auditing, it's neccessary to be able to see what users can bypass the SSO system and log in locally. It'd be convenient to be able to see this as an extra "checkbox" column on the admin view, instead of having to click every individual user.

  3. For users that log in through SSO, and have no local passwords set, they will never be able to change their password anyway, so hiding this option in the UI is a good way to reduce clutter and confusion.

The underlying requirement is to be able to fulfill security standards in organization that, for example, require Netbox to be accessed from authorized devices only, in a zero-trust type scenario. In this case, the authentication provider ensures that logins happen only from authorized devices (outside the scope of Netbox), and local authentication needs to remain effectively disabled to maintain that security control, and regular audits need to be kept in place in order to ensure it remains disabled.

Database changes

None. This can all be done at the UI level.

External dependencies

None.

Originally created by @pv2b on GitHub (Aug 17, 2023). ### NetBox version v3.5.8 ### Feature type New functionality ### Proposed functionality The proposed functionality is to improve handling of password-less users by: 1. Allowing an administrator to remove a password for a user where a password already exists (similar to the `/admin/auth/user/ID/change` view) 2. Adding a column to the `/admin/auth/user` view to easilly be able to audit which users have local passwords set. 3. Disabling the "password" tab on the `/user/profile/` view for users that have no password set. (And thus are unable to change it.) ### Use case As previously discussed in FR #11672, it is a commonly requested scenario to want to restrict the use of local authentication, for organizations that are using SSO. The Netbox development team have responded that they will not be adding an option to completely disable local authentication or the login form. Instead, the intended solution for an administrator desiring this kind of setup is to disable or remove all locally defined accounts. (Note: A local account is created whenever a user first signs in with a social account, however, local login is prevented by the fact that this user has no password set.) In order to better support that scenario, there are a few gaps in the current setup: 1. If a local user was created, and then was subsequently associated with a social user, that user will have a password, and there is no way to remove that password through the UI, once it's been set. For the use case where users were initially created in Netbox, but then are migrated over to SSO, it'd be useful to be able to remove their passwords, after the fact, thereby forcing those users to log in through SSO in future, without breaking any history. 2. For purpose of security auditing, it's neccessary to be able to see what users can bypass the SSO system and log in locally. It'd be convenient to be able to see this as an extra "checkbox" column on the admin view, instead of having to click every individual user. 3. For users that log in through SSO, and have no local passwords set, they will never be able to change their password anyway, so hiding this option in the UI is a good way to reduce clutter and confusion. The underlying requirement is to be able to fulfill security standards in organization that, for example, require Netbox to be accessed from authorized devices only, in a zero-trust type scenario. In this case, the authentication provider ensures that logins happen only from authorized devices (outside the scope of Netbox), and local authentication needs to remain effectively disabled to maintain that security control, and regular audits need to be kept in place in order to ensure it remains disabled. ### Database changes None. This can all be done at the UI level. ### External dependencies None.
adam added the type: featurepending closure labels 2025-12-29 20:37:16 +01:00
adam closed this issue 2025-12-29 20:37:16 +01:00
adam commented 2025-12-29 20:37:17 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Aug 17, 2023):

I agree with this for another usecase.

"service" accounts. ie users that are created just for API access and to show it was "app name" that made changes in the changelog.
those service account users shouldn't ever be able to be logged into so shouldn't have to have a password assigned.

@ITJamie commented on GitHub (Aug 17, 2023): I agree with this for another usecase. "service" accounts. ie users that are created just for API access and to show it was "app name" that made changes in the changelog. those service account users shouldn't ever be able to be logged into so shouldn't have to have a password assigned.
adam commented 2025-12-29 20:37:17 +01:00
Author
Owner
Copy Link

@pv2b commented on GitHub (Aug 17, 2023):

I agree with this for another usecase.

"service" accounts. ie users that are created just for API access and to show it was "app name" that made changes in the changelog. those service account users shouldn't ever be able to be logged into so shouldn't have to have a password assigned.

For that use case you'd ideally need to add another line item to the proposed functionality:

  • When adding a user through /admin/auth/user/add, allow that user to be created with no password.

This could also support the idea of pre-creating users you expect to show in in social auth, so you can assign permissions to them before their first login.

But this might be best tracked as a seperate FR?

@pv2b commented on GitHub (Aug 17, 2023): > I agree with this for another usecase. > > "service" accounts. ie users that are created just for API access and to show it was "app name" that made changes in the changelog. those service account users shouldn't ever be able to be logged into so shouldn't have to have a password assigned. For that use case you'd ideally need to add another line item to the proposed functionality: - When adding a user through `/admin/auth/user/add`, allow that user to be created with no password. This could also support the idea of pre-creating users you expect to show in in social auth, so you can assign permissions to them before their first login. But this might be best tracked as a seperate FR?
adam commented 2025-12-29 20:37:17 +01:00
Author
Owner
Copy Link

@pv2b commented on GitHub (Aug 17, 2023):

For reference, if anyone needs to be able to do 1 and 2, pending this FR, this can be done through nbshell.

  1. To get a list of users who have local passwords set:
[u.username for u in AdminUser.objects.all() if u.has_usable_password()]
  1. To remove a password for a single user:
u = AdminUser.objects.get(username='ExampleUsername')
u.set_unusable_password()
u.save()
@pv2b commented on GitHub (Aug 17, 2023): For reference, if anyone needs to be able to do 1 and 2, pending this FR, this can be done through [nbshell](https://demo.netbox.dev/static/docs/administration/netbox-shell/). 1. To get a list of users who have local passwords set: ```python [u.username for u in AdminUser.objects.all() if u.has_usable_password()] ``` 2. To remove a password for a single user: ```python u = AdminUser.objects.get(username='ExampleUsername') u.set_unusable_password() u.save() ```
adam commented 2025-12-29 20:37:17 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 16, 2023):

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Nov 16, 2023): 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:37:17 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 16, 2023):

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.

@github-actions[bot] commented on GitHub (Dec 16, 2023): 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 type: feature
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#8481
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?