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

LDAP group caching no longer works after upgrade to v2.11.10 #5165

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

Originally created by @koratfood on GitHub (Aug 10, 2021).

NetBox version

v2.11.10

Python version

3.8

Steps to Reproduce

  1. Install a new instance of Netbox v2.11.9 (or earlier) with LDAP authentication. Use LDAP config params towards a working LDAP server as suggested by official Netbox documentation, except the following:
AUTH_LDAP_FIND_GROUP_PERMS = False
AUTH_LDAP_CACHE_GROUPS = True
AUTH_LDAP_CACHE_TIMEOUT = 60
AUTH_LDAP_GROUP_CACHE_TIMEOUT = 60
AUTH_LDAP_REQUIRE_GROUP = "CN=Netbox Users,OU=Groups,DC=mycompany,DC=com"
AUTH_LDAP_MIRROR_GROUPS = ["Netbox Admins", "Netbox Users"]
AUTH_LDAP_USER_FLAGS_BY_GROUP = {
        "is_superuser": ["CN=Netbox Admins,OU=Groups,DC=mycompany,DC=com"]
}

Substitute domain and group names as appropriate, and make sure the LDAP account you use for testing is a member of 'Netbox Admins' as well as 'Netbox Users'.

  1. Log in and create an API token for yourself, with "write enabled" and no expiration date.
  2. POST an object via the REST-API (just to rule out potential hiccups with initial POST-request after upgrade)
curl -X POST \
-H "Authorization: Token <insert your token here>" \
-H "Content-Type: application/json" \
-H "Accept: application/json; indent=4" \
https://my-netbox-server/api/ipam/ip-addresses/ \
--data '{
    "address": "10.0.0.1/24",
	"description": "My IP Host 1"
}'
  1. POST another object via the REST-API, and take note of how long it takes to complete
curl -X POST \
-H "Authorization: Token <insert your token here>" \
-H "Content-Type: application/json" \
-H "Accept: application/json; indent=4" \
https://my-netbox-server/api/ipam/ip-addresses/ \
--data '{
    "address": "10.0.0.2/24",
	"description": "My IP Host 2"
}'
  1. Upgrade Netbox instance to v2.11.10 in accordance with official documentation
  2. POST an object via the REST-API (just to rule out potential hiccups with initial POST-request after upgrade)
curl -X POST \
-H "Authorization: Token <insert your token here>" \
-H "Content-Type: application/json" \
-H "Accept: application/json; indent=4" \
https://my-netbox-server/api/ipam/ip-addresses/ \
--data '{
    "address": "10.0.0.3/24",
	"description": "My IP Host 3"
}'
  1. POST another object via the REST-API, and take note of how long it takes to complete
curl -X POST \
-H "Authorization: Token <insert your token here>" \
-H "Content-Type: application/json" \
-H "Accept: application/json; indent=4" \
https://my-netbox-server/api/ipam/ip-addresses/ \
--data '{
    "address": "10.0.0.4/24",
	"description": "My IP Host 4"
}'

Expected Behavior

Netbox takes an (approximately) equal amount of time to return a response in step 7 when compared to step 4.

Observed Behavior

Netbox takes more than twice as long to return a response in step 7 when compared to step 4. In my specific case (low-spec'ed VM), this translates to step 4 taking around half a second, and step 7 taking over two seconds. I have also reproduced it on a higher-spec'ed bare-metal machine which is naturally faster, but the equation is still the same - i.e. step 7 taking over twice as long as step 4.

Originally created by @koratfood on GitHub (Aug 10, 2021). ### NetBox version v2.11.10 ### Python version 3.8 ### Steps to Reproduce 1. Install a new instance of Netbox v2.11.9 (or earlier) with LDAP authentication. Use LDAP config params towards a working LDAP server as suggested by official Netbox documentation, except the following: ``` AUTH_LDAP_FIND_GROUP_PERMS = False AUTH_LDAP_CACHE_GROUPS = True AUTH_LDAP_CACHE_TIMEOUT = 60 AUTH_LDAP_GROUP_CACHE_TIMEOUT = 60 AUTH_LDAP_REQUIRE_GROUP = "CN=Netbox Users,OU=Groups,DC=mycompany,DC=com" AUTH_LDAP_MIRROR_GROUPS = ["Netbox Admins", "Netbox Users"] AUTH_LDAP_USER_FLAGS_BY_GROUP = { "is_superuser": ["CN=Netbox Admins,OU=Groups,DC=mycompany,DC=com"] } ``` Substitute domain and group names as appropriate, and make sure the LDAP account you use for testing is a member of 'Netbox Admins' as well as 'Netbox Users'. 2. Log in and create an API token for yourself, with "write enabled" and no expiration date. 3. POST an object via the REST-API (just to rule out potential hiccups with initial POST-request after upgrade) ``` curl -X POST \ -H "Authorization: Token <insert your token here>" \ -H "Content-Type: application/json" \ -H "Accept: application/json; indent=4" \ https://my-netbox-server/api/ipam/ip-addresses/ \ --data '{ "address": "10.0.0.1/24", "description": "My IP Host 1" }' ``` 4. POST another object via the REST-API, and take note of how long it takes to complete ``` curl -X POST \ -H "Authorization: Token <insert your token here>" \ -H "Content-Type: application/json" \ -H "Accept: application/json; indent=4" \ https://my-netbox-server/api/ipam/ip-addresses/ \ --data '{ "address": "10.0.0.2/24", "description": "My IP Host 2" }' ``` 5. Upgrade Netbox instance to v2.11.10 in accordance with official documentation 6. POST an object via the REST-API (just to rule out potential hiccups with initial POST-request after upgrade) ``` curl -X POST \ -H "Authorization: Token <insert your token here>" \ -H "Content-Type: application/json" \ -H "Accept: application/json; indent=4" \ https://my-netbox-server/api/ipam/ip-addresses/ \ --data '{ "address": "10.0.0.3/24", "description": "My IP Host 3" }' ``` 7. POST another object via the REST-API, and take note of how long it takes to complete ``` curl -X POST \ -H "Authorization: Token <insert your token here>" \ -H "Content-Type: application/json" \ -H "Accept: application/json; indent=4" \ https://my-netbox-server/api/ipam/ip-addresses/ \ --data '{ "address": "10.0.0.4/24", "description": "My IP Host 4" }' ``` ### Expected Behavior Netbox takes an (approximately) equal amount of time to return a response in step 7 when compared to step 4. ### Observed Behavior Netbox takes more than twice as long to return a response in step 7 when compared to step 4. In my specific case (low-spec'ed VM), this translates to step 4 taking around half a second, and step 7 taking over two seconds. I have also reproduced it on a higher-spec'ed bare-metal machine which is naturally faster, but the equation is still the same - i.e. step 7 taking over twice as long as step 4.
adam added the type: bugstatus: needs ownerpending closure labels 2025-12-29 19:24:58 +01:00
adam closed this issue 2025-12-29 19:24:58 +01:00
adam commented 2025-12-29 19:24:59 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Aug 10, 2021):

Would you be able to upgrade one step at a time, just to verify which release started the regression?

Also: does it affect other endpoints as well? And does the number hold up when inserting 1000 entries (not at once, but in a serial loop)?

@sdktr commented on GitHub (Aug 10, 2021): Would you be able to upgrade one step at a time, just to verify which release started the regression? Also: does it affect other endpoints as well? And does the number hold up when inserting 1000 entries (not at once, but in a serial loop)?
adam commented 2025-12-29 19:24:59 +01:00
Author
Owner
Copy Link

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

I have now tested some more while upgrading one release at a time, and it appears the regression starts in v2.11.10 specifically. Edited my initial post accordingly.

It seems more if not all endpoints are equally affected. So far I have tested a bunch within IPAM, DCIM and Extras.

@koratfood commented on GitHub (Aug 11, 2021): I have now tested some more while upgrading one release at a time, and it appears the regression starts in v2.11.10 specifically. Edited my initial post accordingly. It seems more if not all endpoints are equally affected. So far I have tested a bunch within IPAM, DCIM and Extras.
adam commented 2025-12-29 19:24:59 +01:00
Author
Owner
Copy Link

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

Aight, are create as well as read actions affected?

@sdktr commented on GitHub (Aug 11, 2021): Aight, are create as well as read actions affected?
adam commented 2025-12-29 19:24:59 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Aug 11, 2021):

Are you using LDAP authentication in your NetBox install? As of v2.11.10, API calls now properly check a user's LDAP permissions when using AUTH_LDAP_FIND_GROUP_PERMS.

What is AUTH_LDAP_FIND_GROUP_PERMS set to?

What about AUTH_LDAP_CACHE_TIMEOUT? Setting this to a value > 0 (say 60 seconds) would likely improve performance.

Alternatively, you could set AUTH_LDAP_FIND_GROUP_PERMS = False and use something like

AUTH_LDAP_MIRROR_GROUPS = ("ldap_netbox_group_name", "ldap_netbox_admin_group")

Info on AUTH_LDAP_MIRROR_GROUPS

@tyler-8 commented on GitHub (Aug 11, 2021): Are you using LDAP authentication in your NetBox install? As of [v2.11.10](https://github.com/netbox-community/netbox/pull/6580), API calls now properly check a user's LDAP permissions when using `AUTH_LDAP_FIND_GROUP_PERMS`. What is [AUTH_LDAP_FIND_GROUP_PERMS](https://django-auth-ldap.readthedocs.io/en/latest/reference.html?highlight=find_group_perms#auth-ldap-find-group-perms) set to? What about [AUTH_LDAP_CACHE_TIMEOUT](https://django-auth-ldap.readthedocs.io/en/latest/reference.html?highlight=find_group_perms#auth-ldap-cache-timeout)? Setting this to a value > 0 (say 60 seconds) would likely improve performance. Alternatively, you could set `AUTH_LDAP_FIND_GROUP_PERMS = False` and use something like ```python AUTH_LDAP_MIRROR_GROUPS = ("ldap_netbox_group_name", "ldap_netbox_admin_group") ``` Info on [AUTH_LDAP_MIRROR_GROUPS](https://django-auth-ldap.readthedocs.io/en/latest/reference.html?highlight=find_group_perms#auth-ldap-mirror-groups)
adam commented 2025-12-29 19:25:00 +01:00
Author
Owner
Copy Link

@koratfood commented on GitHub (Aug 12, 2021):

Aight, are create as well as read actions affected?

It appears so, yes.

@koratfood commented on GitHub (Aug 12, 2021): > > > Aight, are create as well as read actions affected? It appears so, yes.
adam commented 2025-12-29 19:25:00 +01:00
Author
Owner
Copy Link

@koratfood commented on GitHub (Aug 12, 2021):

Are you using LDAP authentication in your NetBox install? As of v2.11.10, API calls now properly check a user's LDAP permissions when using AUTH_LDAP_FIND_GROUP_PERMS.

Yes, I am. Thanks for pointing this out.

It did not occur to me to check this earlier, but if I disable LDAP authentication (REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend') and use a local account/token instead, the problem goes away. So certainly seems related in some way.

What is AUTH_LDAP_FIND_GROUP_PERMS set to?

False.

What about AUTH_LDAP_CACHE_TIMEOUT? Setting this to a value > 0 (say 60 seconds) would likely improve performance.

I already have it set to 60. I had AUTH_LDAP_GROUP_CACHE_TIMEOUT set to 60, but nothing on AUTH_LDAP_CACHE_TIMEOUT. Just tried setting the latter to 60 as well, but it does not seem to make any difference.

Alternatively, you could set AUTH_LDAP_FIND_GROUP_PERMS = False and use something like

AUTH_LDAP_MIRROR_GROUPS = ("ldap_netbox_group_name", "ldap_netbox_admin_group")

This is the setup I am using.

@koratfood commented on GitHub (Aug 12, 2021): > > > Are you using LDAP authentication in your NetBox install? As of [v2.11.10](https://github.com/netbox-community/netbox/pull/6580), API calls now properly check a user's LDAP permissions when using `AUTH_LDAP_FIND_GROUP_PERMS`. Yes, I am. Thanks for pointing this out. It did not occur to me to check this earlier, but if I disable LDAP authentication (REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend') and use a local account/token instead, the problem goes away. So certainly seems related in some way. > > > What is [AUTH_LDAP_FIND_GROUP_PERMS](https://django-auth-ldap.readthedocs.io/en/latest/reference.html?highlight=find_group_perms#auth-ldap-find-group-perms) set to? False. > > > What about [AUTH_LDAP_CACHE_TIMEOUT](https://django-auth-ldap.readthedocs.io/en/latest/reference.html?highlight=find_group_perms#auth-ldap-cache-timeout)? Setting this to a value > 0 (say 60 seconds) would likely improve performance. ~~I already have it set to 60.~~ I had AUTH_LDAP_GROUP_CACHE_TIMEOUT set to 60, but nothing on AUTH_LDAP_CACHE_TIMEOUT. Just tried setting the latter to 60 as well, but it does not seem to make any difference. > > > Alternatively, you could set `AUTH_LDAP_FIND_GROUP_PERMS = False` and use something like > > ```python > AUTH_LDAP_MIRROR_GROUPS = ("ldap_netbox_group_name", "ldap_netbox_admin_group") > ``` This is the setup I am using.
adam commented 2025-12-29 19:25:00 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Aug 12, 2021):

Yeah re-reading the code it doesn't matter the setting of AUTH_LDAP_FIND_GROUP_PERMS - it'll lookup the LDAP groups every time. I am surprised to hear that enabling the cache doesn't improve speeds.

It'd likely have to be a Feature Request - but perhaps the customized LDAP Backend should check if AUTH_LDAP_FIND_GROUP_PERMS is True before using the new style.

@tyler-8 commented on GitHub (Aug 12, 2021): Yeah re-reading the code it doesn't matter the setting of `AUTH_LDAP_FIND_GROUP_PERMS` - it'll lookup the LDAP groups every time. I am surprised to hear that enabling the cache doesn't improve speeds. It'd likely have to be a Feature Request - but perhaps the customized LDAP Backend should check if `AUTH_LDAP_FIND_GROUP_PERMS` is `True` before using the new style.
adam commented 2025-12-29 19:25:00 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 20, 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 20, 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:25:00 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 21, 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 21, 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#5165
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?