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

admin user active, staff and superuser flags are removed when LDAP authentication is used #5143

New Issue
Closed
opened 2025-12-29 19:24:47 +01:00 by adam · 6 comments
adam commented 2025-12-29 19:24:47 +01:00
Owner
Copy Link

Originally created by @karlism on GitHub (Aug 5, 2021).

NetBox version

v2.11.10

Python version

3.6

Steps to Reproduce

  1. Use LDAP authentication
  2. Upgrade NetBox from 2.11.9 to 2.11.10

In our case we are using FreeIPA where admin user exists by default and LDAP user flags by group are following:

AUTH_LDAP_USER_FLAGS_BY_GROUP = {
    "is_active": "CN=ipausers,CN=groups,CN=accounts,DC=example,DC=com",
    "is_staff": "CN=infra,CN=groups,CN=accounts,DC=example,DC=com",
    "is_superuser": "CN=infra,CN=groups,CN=accounts,DC=example,DC=com"
}

Unfortunately this admin user account is not member of any of these groups and after NetBox upgrade active, stuff and superuser flags are removed for admin user.

I guess this is related to this PR: https://github.com/netbox-community/netbox/issues/5442

Expected Behavior

admin user should always have active, stuff and superuser flags, as in our case this is fallback user for cases when there are problems with LDAP authentication

Observed Behavior

admin user active, stuff and superuser flags are removed

Originally created by @karlism on GitHub (Aug 5, 2021). ### NetBox version v2.11.10 ### Python version 3.6 ### Steps to Reproduce 1. Use LDAP authentication 2. Upgrade NetBox from 2.11.9 to 2.11.10 In our case we are using FreeIPA where `admin` user exists by default and LDAP user flags by group are following: ``` AUTH_LDAP_USER_FLAGS_BY_GROUP = { "is_active": "CN=ipausers,CN=groups,CN=accounts,DC=example,DC=com", "is_staff": "CN=infra,CN=groups,CN=accounts,DC=example,DC=com", "is_superuser": "CN=infra,CN=groups,CN=accounts,DC=example,DC=com" } ``` Unfortunately this `admin` user account is not member of any of these groups and after NetBox upgrade `active`, `stuff` and `superuser` flags are removed for `admin` user. I guess this is related to this PR: https://github.com/netbox-community/netbox/issues/5442 ### Expected Behavior `admin` user should always have active, stuff and superuser flags, as in our case this is fallback user for cases when there are problems with LDAP authentication ### Observed Behavior `admin` user active, stuff and superuser flags are removed
adam added the type: bugstatus: needs ownerpending closure labels 2025-12-29 19:24:47 +01:00
adam closed this issue 2025-12-29 19:24:47 +01:00
adam commented 2025-12-29 19:24:48 +01:00
Author
Owner
Copy Link

@karlism commented on GitHub (Aug 5, 2021):

Judging by PostgreSQL logs it is also attempting to update admin account user password each time API requests to NetBox API are made, for example this request:

$ curl -H "Authorization: Token XXX" 'https://netbox2.example.com/api/ipam/ip-addresses/?limit=0&assigned_to_interface=True'                                                          
{"error": "cannot execute UPDATE in a read-only transaction\n", "exception": "InternalError", "netbox_version": "2.11.10", "python_version": "3.6.8"}%

It fails because in our case netbox2.example.com is read-only backup NetBox server in maintenance mode with read-only PostgreSQL replica database, and this is what I can see in PostgreSQL logs:

< 2021-08-05 12:55:03.673 UTC > ERROR:  cannot execute UPDATE in a read-only transaction
< 2021-08-05 12:55:03.673 UTC > STATEMENT:  UPDATE "auth_user" SET "password" = 'pbkdf2_sha256$XXX', "last_login" = '2017-08-02T13:41:25+00:00'::timestamptz, "is_superuser" = false, "username" = 'admin', "first_name" = '', "last_name" = 'Administrator', "email" = '', "is_staff" = false, "is_active" = true, "date_joined" = '2017-08-02T13:40:08+00:00'::timestamptz WHERE "auth_user"."id" = 1
@karlism commented on GitHub (Aug 5, 2021): Judging by PostgreSQL logs it is also attempting to update `admin` account user password each time API requests to NetBox API are made, for example this request: ``` $ curl -H "Authorization: Token XXX" 'https://netbox2.example.com/api/ipam/ip-addresses/?limit=0&assigned_to_interface=True' {"error": "cannot execute UPDATE in a read-only transaction\n", "exception": "InternalError", "netbox_version": "2.11.10", "python_version": "3.6.8"}% ``` It fails because in our case `netbox2.example.com` is read-only backup NetBox server in maintenance mode with read-only PostgreSQL replica database, and this is what I can see in PostgreSQL logs: ``` < 2021-08-05 12:55:03.673 UTC > ERROR: cannot execute UPDATE in a read-only transaction < 2021-08-05 12:55:03.673 UTC > STATEMENT: UPDATE "auth_user" SET "password" = 'pbkdf2_sha256$XXX', "last_login" = '2017-08-02T13:41:25+00:00'::timestamptz, "is_superuser" = false, "username" = 'admin', "first_name" = '', "last_name" = 'Administrator', "email" = '', "is_staff" = false, "is_active" = true, "date_joined" = '2017-08-02T13:40:08+00:00'::timestamptz WHERE "auth_user"."id" = 1 ```
adam commented 2025-12-29 19:24:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 6, 2021):

@tobiasge could you take a look at this please? Seems to be related to PR #6580.

@jeremystretch commented on GitHub (Aug 6, 2021): @tobiasge could you take a look at this please? Seems to be related to PR #6580.
adam commented 2025-12-29 19:24:48 +01:00
Author
Owner
Copy Link

@tobiasge commented on GitHub (Aug 6, 2021):

To solve the immediate problem on your read-only server you can set the AUTH_LDAP_ALWAYS_UPDATE_USER to False. See the documentation.

The underlying problem is a bit more complicated.
In the UI it is working, because the authenticate method tries all authentication methods in order. So the LDAP backend fails for your "admin" user and he is not updated. Then the next authentication method (which is the Postgres database) is tried and your "admin" is logged in.

When the API uses the token to authenticate the user, we do not have the information if the user was originally from the database or the LDAP.

We could prevent the update of the user, when he is authenticated with a token in the API. But that would also enable users to use the API even when rights in the LDAP have been removed, as long as the user doesn't try to login to the UI.

@tobiasge commented on GitHub (Aug 6, 2021): To solve the immediate problem on your read-only server you can set the `AUTH_LDAP_ALWAYS_UPDATE_USER` to `False`. See the [documentation](https://django-auth-ldap.readthedocs.io/en/latest/reference.html#auth-ldap-always-update-user). The underlying problem is a bit more complicated. In the UI it is working, because the `authenticate` method tries all authentication methods in order. So the LDAP backend fails for your "admin" user and he is not updated. Then the next authentication method (which is the Postgres database) is tried and your "admin" is logged in. When the API uses the token to authenticate the user, we do not have the information if the user was originally from the database or the LDAP. We could prevent the update of the user, when he is authenticated with a token in the API. But that would also enable users to use the API even when rights in the LDAP have been removed, as long as the user doesn't try to login to the UI.
adam commented 2025-12-29 19:24:48 +01:00
Author
Owner
Copy Link

@karlism commented on GitHub (Aug 11, 2021):

To solve the immediate problem on your read-only server you can set the AUTH_LDAP_ALWAYS_UPDATE_USER to False. See the documentation.

@tobiasge, thanks for the suggestion, but on our backup read-only server this value is already set to False, yet I see that it attempts to update users in database:

$ cat ldap_config.py | grep AUTH_LDAP_ALWAYS_UPDATE_USER
AUTH_LDAP_ALWAYS_UPDATE_USER = False

The underlying problem is a bit more complicated.
In the UI it is working, because the authenticate method tries all authentication methods in order. So the LDAP backend fails for your "admin" user and he is not updated. Then the next authentication method (which is the Postgres database) is tried and your "admin" is logged in.

When the API uses the token to authenticate the user, we do not have the information if the user was originally from the database or the LDAP.

We could prevent the update of the user, when he is authenticated with a token in the API. But that would also enable users to use the API even when rights in the LDAP have been removed, as long as the user doesn't try to login to the UI.

That's a good point and I agree that it is probably better idea to check user every time.

What I'm more concerned about is that admin superuser is being deactivated in our case. I guess that as a workaround I can change username from admin to something else that is not present in our LDAP database.

@karlism commented on GitHub (Aug 11, 2021): > To solve the immediate problem on your read-only server you can set the `AUTH_LDAP_ALWAYS_UPDATE_USER` to `False`. See the [documentation](https://django-auth-ldap.readthedocs.io/en/latest/reference.html#auth-ldap-always-update-user). @tobiasge, thanks for the suggestion, but on our backup read-only server this value is already set to `False`, yet I see that it attempts to update users in database: ``` $ cat ldap_config.py | grep AUTH_LDAP_ALWAYS_UPDATE_USER AUTH_LDAP_ALWAYS_UPDATE_USER = False ``` > The underlying problem is a bit more complicated. > In the UI it is working, because the `authenticate` method tries all authentication methods in order. So the LDAP backend fails for your "admin" user and he is not updated. Then the next authentication method (which is the Postgres database) is tried and your "admin" is logged in. > > When the API uses the token to authenticate the user, we do not have the information if the user was originally from the database or the LDAP. > > We could prevent the update of the user, when he is authenticated with a token in the API. But that would also enable users to use the API even when rights in the LDAP have been removed, as long as the user doesn't try to login to the UI. That's a good point and I agree that it is probably better idea to check user every time. What I'm more concerned about is that `admin` superuser is being deactivated in our case. I guess that as a workaround I can change username from `admin` to something else that is not present in our LDAP database.
adam commented 2025-12-29 19:24:48 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 11, 2021):

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.

@github-actions[bot] commented on GitHub (Oct 11, 2021): 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 19:24:49 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 11, 2021):

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 (Nov 11, 2021): 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#5143
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?