Home / server / Questions / 1081929
In Process
larsks
Asked: 2021-10-28 11:06:08 +0800 CST

Configuring Netbox to get authorization information via REMOTE_AUTH?

  • 772

I'm trying to set up an oauth2 proxy in front of Netbox (to authenticate against a local Keycloak instance). I have the following configuration in the /etc/netbox/config/extra.py:

REMOTE_AUTH_ENABLED=True
REMOTE_AUTH_AUTO_CREATE_USER=True
REMOTE_AUTH_HEADER='HTTP_X_FORWARDED_PREFERRED_USERNAME'
REMOTE_AUTH_GROUP_HEADER='HTTP_X_FORWARDED_GROUPS'
REMOTE_AUTH_GROUP_SYNC_ENABLED=True
REMOTE_AUTH_SUPERUSER_GROUPS=['netbox-admin']
REMOTE_AUTH_GROUP_SEPARATOR=','

Authentication works just fine; I can enter my credentials and Netbox shows my email address in the account menu.

Requests have an X-Forwarded-* headers that look like:

X-Forwarded-Preferred-Username: [email protected]
X-Forwarded-Groups: default-roles-example,offline_access,netbox-admin,uma_authorization,role:default-roles-example,role:offline_access,role:netbox-admin,role:uma_authorization,role:account:manage-account,role:account:manage-account-links,role:account:view-profile

I have verified that these headers are present in requests to Netbox.

I've tried setting REMOTE_AUTH_GROUP_HEADER and REMOTE_AUTH_GROUP_SEPARATOR appropriately, but viewing the account profile (https://netbox.../user/profile/) always shows "Groups: None", and I'm not able to get superuser privileges.

Is there something obvious missing from my configuration?

oauth netbox

1 Answers

  1. I just ran into this issue as well. Not sure if this is still relevant for you, but leaving the solution here for other people who may stumble upon this.

    Turns out that the group sync requires the groups to exist in the backend. By default, netbox is deployed with no groups.

    The solution is to log in using the admin account created on deploy, then go to admin > groups and manually create the named groups you wish to sync.

    In your case, you should create a group called netbox-admin. There is no need to assign any rights to the groups, but they must exist, even if they otherwise do nothing.

    I also noticed that logging in with a user that was already created after fixing this did not assign the group membership or superuser or staff status. I had to delete my user first and log in again via the remote auth before the correct group and status was assigned. It does say in the documentation that it will scrap superuser status when a remote login is made that does not contain the same group(s), but apparently it does not sync the other way.

    • 0