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

API Tokens for LDAP authenticated users don't get group permissions #2514

New Issue
Closed
opened 2025-12-29 18:19:31 +01:00 by adam · 11 comments
adam commented 2025-12-29 18:19:31 +01:00
Owner
Copy Link

Originally created by @tyler-8 on GitHub (Apr 11, 2019).

Environment

  • Python version: 3.6.8
  • NetBox version: 2.5.10

Steps to Reproduce

  1. Setup LDAP authentication with users in security groups mapped to Netbox/Django groups (AUTH_LDAP_FIND_GROUP_PERMS set to true)
  2. Create API token for LDAP user
  3. Via API, try to create object that the LDAP user's group has permissions to create
  4. Observe 403 no permission error

Expected Behavior

Object is created successfully

Observed Behavior

HTTP 403 error received.

This appears to be due to using AUTH_LDAP_FIND_GROUP_PERMS and mapping granular permissions to an LDAP user's group membership. Through the Netbox GUI everything works fine, but the API token doesn't get mapped dynamically to their assigned user group since the LDAP validation never takes place.

Originally created by @tyler-8 on GitHub (Apr 11, 2019). <!-- NOTE: This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.8<!-- Example: 3.5.4 --> * NetBox version: 2.5.10<!-- Example: 2.5.2 --> <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox (or the current beta release where applicable). Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a wrapper like pynetbox. --> ### Steps to Reproduce 1. Setup LDAP authentication with users in security groups mapped to Netbox/Django groups (`AUTH_LDAP_FIND_GROUP_PERMS` set to true) 2. Create API token for LDAP user 3. Via API, try to create object that the LDAP user's group has permissions to create 4. Observe 403 no permission error <!-- What did you expect to happen? --> ### Expected Behavior Object is created successfully <!-- What happened instead? --> ### Observed Behavior HTTP 403 error received. This appears to be due to using `AUTH_LDAP_FIND_GROUP_PERMS` and mapping granular permissions to an LDAP user's group membership. Through the Netbox GUI everything works fine, but the API token doesn't get mapped dynamically to their assigned user group since the LDAP validation never takes place.
adam added the type: bugstatus: needs ownerpending closure labels 2025-12-29 18:19:31 +01:00
adam closed this issue 2025-12-29 18:19:31 +01:00
adam commented 2025-12-29 18:19:32 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Apr 12, 2019):

I think this class is where the potential changes could happen https://github.com/digitalocean/netbox/blob/develop/netbox/netbox/api.py#L53. Just need to determine where in django_auth_ldap we'd need to hook in to. https://django-auth-ldap.readthedocs.io/en/latest/custombehavior.html

@tyler-8 commented on GitHub (Apr 12, 2019): I think this class is where the potential changes could happen https://github.com/digitalocean/netbox/blob/develop/netbox/netbox/api.py#L53. Just need to determine where in `django_auth_ldap` we'd need to hook in to. https://django-auth-ldap.readthedocs.io/en/latest/custombehavior.html
adam commented 2025-12-29 18:19:32 +01:00
Author
Owner
Copy Link

@arionl commented on GitHub (May 2, 2019):

Chiming in with a +1 here. We encountered this issue as well: we use LDAP integration and Active Directory groups to define three primary sets of users: global admins, read-only users, and read-write users. API tokens for global admins work fine but tokens for these other user types don't work and exhibit the behavior showed above (can create/update/delete objects through the web GUI but not through any token they have created).

@arionl commented on GitHub (May 2, 2019): Chiming in with a +1 here. We encountered this issue as well: we use LDAP integration and Active Directory groups to define three primary sets of users: global admins, read-only users, and read-write users. API tokens for global admins work fine but tokens for these other user types don't work and exhibit the behavior showed above (can create/update/delete objects through the web GUI but not through any token they have created).
adam commented 2025-12-29 18:19:32 +01:00
Author
Owner
Copy Link

@akhmarov commented on GitHub (Sep 9, 2019):

Hello!

We have the same issue. After we moved from NetBox local permissions to LDAP group based permissions our API access tokens lost all permissions. We have to temporarily duplicate local permissions for remote users

@akhmarov commented on GitHub (Sep 9, 2019): Hello! We have the same issue. After we moved from NetBox local permissions to LDAP group based permissions our API access tokens lost all permissions. We have to temporarily duplicate local permissions for remote users
adam commented 2025-12-29 18:19:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 15, 2019):

Need someone familiar with LDAP authentication to own this. Otherwise it will be closed.

@jeremystretch commented on GitHub (Oct 15, 2019): Need someone familiar with LDAP authentication to own this. Otherwise it will be closed.
adam commented 2025-12-29 18:19:33 +01:00
Author
Owner
Copy Link

@Grokzen commented on GitHub (Oct 17, 2019):

I think view perimssions broke this as well for the same reasons as the original author wrote about, but now it dont even work to view any objects behind a View permission when you are using the dynamic mapping feature from LDAP.

The only current workaround we have is that for API tokens, we create a manual user and add the correct permissions to those accounts. Call it like server or integration accounts if you are wokring on a specific feature or integration with some external system, it is always better to have a unique and specific account that holds the API token for that integration. It is not a optimoal solution but it works as a workaround for now.

@Grokzen commented on GitHub (Oct 17, 2019): I think view perimssions broke this as well for the same reasons as the original author wrote about, but now it dont even work to view any objects behind a View permission when you are using the dynamic mapping feature from LDAP. The only current workaround we have is that for API tokens, we create a manual user and add the correct permissions to those accounts. Call it like server or integration accounts if you are wokring on a specific feature or integration with some external system, it is always better to have a unique and specific account that holds the API token for that integration. It is not a optimoal solution but it works as a workaround for now.
adam commented 2025-12-29 18:19:33 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Oct 17, 2019):

I think view perimssions broke this as well for the same reasons as the original author wrote about, but now it dont even work to view any objects behind a View permission when you are using the dynamic mapping feature from LDAP.

Double check that the casing of the group name in Netbox matches exactly to the casing in your AD/LDAP server. That was a weird side-effect we noticed after going to v2.6.X from v2.5.X.

@tyler-8 commented on GitHub (Oct 17, 2019): > I think view perimssions broke this as well for the same reasons as the original author wrote about, but now it dont even work to view any objects behind a View permission when you are using the dynamic mapping feature from LDAP. Double check that the casing of the group name in Netbox matches exactly to the casing in your AD/LDAP server. That was a weird side-effect we noticed after going to v2.6.X from v2.5.X.
adam commented 2025-12-29 18:19:33 +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:19:33 +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.
adam commented 2025-12-29 18:19:33 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 12, 2020):

Would someone mind sharing their LDAP-specific config please? I'm trying to recreate this issue but everything works as it should via the API just like the web UI with the following config. django-auth-ldap==2.0.0 with 389-ds-base 1.3.9.1-12.el7_7

import ldap
from django_auth_ldap.config import GroupOfNamesType, LDAPSearch

AUTH_LDAP_CACHE_GROUPS = True
AUTH_LDAP_FIND_GROUP_PERMS = True
AUTH_LDAP_GROUP_CACHE_TIMEOUT = 3600
AUTH_LDAP_GROUP_SEARCH = LDAPSearch('ou=Groups,dc=example,dc=com', ldap.SCOPE_SUBTREE, '(objectClass=posixGroup)')
AUTH_LDAP_GROUP_TYPE = GroupOfNamesType()
AUTH_LDAP_MIRROR_GROUPS = True
AUTH_LDAP_USER_DN_TEMPLATE = 'cn=%(user)s,ou=People,dc=example,dc=com'
AUTH_LDAP_SERVER_URI = 'ldap://localhost:389/'

AUTH_LDAP_USER_FLAGS_BY_GROUP = {
    'is_active': 'cn=ggactive,ou=Groups,dc=example,dc=com',
    'is_staff': 'cn=ggreadwrite,ou=Groups,dc=example,dc=com',
    'is_superuser': 'cn=ggadmins,ou=Groups,dc=example,dc=com',
}
@hSaria commented on GitHub (Jan 12, 2020): Would someone mind sharing their LDAP-specific config please? I'm trying to recreate this issue but everything works as it should via the API just like the web UI with the following config. `django-auth-ldap==2.0.0` with `389-ds-base 1.3.9.1-12.el7_7` ```python import ldap from django_auth_ldap.config import GroupOfNamesType, LDAPSearch AUTH_LDAP_CACHE_GROUPS = True AUTH_LDAP_FIND_GROUP_PERMS = True AUTH_LDAP_GROUP_CACHE_TIMEOUT = 3600 AUTH_LDAP_GROUP_SEARCH = LDAPSearch('ou=Groups,dc=example,dc=com', ldap.SCOPE_SUBTREE, '(objectClass=posixGroup)') AUTH_LDAP_GROUP_TYPE = GroupOfNamesType() AUTH_LDAP_MIRROR_GROUPS = True AUTH_LDAP_USER_DN_TEMPLATE = 'cn=%(user)s,ou=People,dc=example,dc=com' AUTH_LDAP_SERVER_URI = 'ldap://localhost:389/' AUTH_LDAP_USER_FLAGS_BY_GROUP = { 'is_active': 'cn=ggactive,ou=Groups,dc=example,dc=com', 'is_staff': 'cn=ggreadwrite,ou=Groups,dc=example,dc=com', 'is_superuser': 'cn=ggadmins,ou=Groups,dc=example,dc=com', } ```
adam commented 2025-12-29 18:19:33 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Jan 13, 2020):

@hSaria are you adding an LDAP-authenticated user to a Django group through Django admin or are you letting django-auth-ldap dynamically map the user to that group? I'll work on getting an export of my config here.

If I manually add a user to a group within Django admin, the API key works, but if the user is just getting permissions via LDAP group mapping, they do not.

@tyler-8 commented on GitHub (Jan 13, 2020): @hSaria are you adding an LDAP-authenticated user to a Django group through Django admin or are you letting `django-auth-ldap` dynamically map the user to that group? I'll work on getting an export of my config here. If I manually add a user to a group within Django admin, the API key works, but if the user is just getting permissions via LDAP group mapping, they do not.
adam commented 2025-12-29 18:19:33 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 13, 2020):

I'm not adding the LDAP-user to a Django group myself. From a fresh state (no groups, no users), here's what I do:

  1. Login with the user which creates the user and any groups it belongs to
  2. Using an admin account, I add some permissions to the remote group of the user (called ggreadonly which has no permissions by default), namely the permission to create an API token and the permission to create an IP
  3. I create a key with the user account and then I create an IP using the following (token of the user)
curl -X POST "http://netbox/api/ipam/ip-addresses/" \
-H "accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: Token e7c480a7cc381dd09d923f0ef04f0c71efaa7b8a" \
-d '{ "address": "1.1.1.1/24"}'
@hSaria commented on GitHub (Jan 13, 2020): I'm not adding the LDAP-user to a Django group myself. From a fresh state (no groups, no users), here's what I do: 1. Login with the user which creates the user and any groups it belongs to 2. Using an admin account, I add some permissions to the remote group of the user (called `ggreadonly` which has no permissions by default), namely the permission to create an API token and the permission to create an IP 2. I create a key with the user account and then I create an IP using the following (token of the user) ``` curl -X POST "http://netbox/api/ipam/ip-addresses/" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -H "Authorization: Token e7c480a7cc381dd09d923f0ef04f0c71efaa7b8a" \ -d '{ "address": "1.1.1.1/24"}' ```
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#2514
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?