If you’re running Netbox in a larger environment, you want to manage your Netbox users in a central place, typically in Active Directory or on a LDAP server. In my newest blog post I show how to setup Netbox with Active Directory as backend for users and groups.
I am not running any Windows Server at home, therefore I set up my Active Directory with Samba on two Debian 10 Linux virtual machines. Instructions for Samba as AD Domain Controller are available at the Samba Wiki User Documentation. If you prefer a Windows-based Active Directory, Microsoft offers a 180-day free trial of Windows 2019 Server.
Requirements for Netbox Active Directory/LDAP configuration
Based on the documentation you’ll find at Netbox LDAP Configuration, you need a LDAP bind account (service account) to connect to Active Directory. The LDAP bind account (service account) is used to “bind” to Active Directory for searches if the Active Directory or LDAP does not allow anonymous searches. Four groups are required for the Django authentication system. Details about the Django authentication system are available in their documentation at django.contrib.auth.
The groups are:
netbox_users - A group required to login into Netbox
is_active - This maps to “Active status” in Netbox (“User can log in”)
is_staff - This maps to “Staff status” in Netbox (User has access to Django admin Web UI)
is_superuser - This maps to “Superuser status” in Netbox (User has all permissions)
Adding Netbox groups in Active Directory
For adding groups to Active Directory you can use the samba-tool on the Linux command line or with the Microsoft Remote Server Administration Tools. By the way: To manage a Linux-based Active Directory with Microsoft RSAT tools is just awesome ;) In the Active Directory I’m defining four groups which will be mapped later in the NetboxAD/LDAP configuration file.
The four groups are:
grp.netbox - Users can login into Netbox
grp.netbox.adm - This is mapped to is_staff for Django admin Web UI
grp.netbox.ro - This is mapped to is_active for Read-Only access
grp.netbox.rw - This is mapped to is_superuser for Read-Write access
In my setup I created an OU (Organizational Unit) for all Applications I’m authenticating against Active Directory and another OU inside the “Application OU” for Netbox. In the OU for the application Netbox I’m adding the four groups and adding some users as members. This is how those groups look like on the Samba server with the RSAT “Active Directory Users and Computer” tool:
Setting up Netbox with Active Directory/LDAP
By following the documentation at Netbox LDAP Configuration I’m configuring the ldap_config.py file with my Active Directory users and groups I made earlier. I’m also adding some comment lines which explains how the mapping is done. Please note that this does not control Netbox internal groups which are defined in the Django admin Web UI. Users authenticating against Active Directory can be assigned to a Netbox internal group after their first login which I’m doing later.
The ldap_config.py with the group-specific part looks like this:
Verifying Netbox Active Directory/LDAP logins
1) Administrator account
The first verification test is with the Administrator account. The Administrator account should be able to Login, should be able to make modifications (add/delete/modify) on every object in Netbox and should have full access to the Django admin Web UI.
2) User account (read-write)
The next test is with an User account. This User account should be able to Login, should be able to make modifications (add/delete/modify) but should NOT have access to the Django admin Web UI. As shown in the Screenshot the menu item “Admin” is missing from the Dropdown menu. In addition, a direct access to the URLhttps://[NETBOX_HOST]/admin/ is not allowed with this user.
3) User account (read-only)
The following test is with an User account who should only be able to view every object (read-only) and should NOT have access to the Django admin Web UI. The screenshot shows that the User is able to Login, but not able to view any object in Netbox. This means this User must be assiged to a Netbox-internal group with the proper permissions:
4) User account not in group “grp.netbox”
The last verification test is with an User account which is not in the Active Directory group grp.netbox. This User should not have access to Netbox, but can login into Active Directory or to other Applications (if the User has those group memberships) and so on.
Users, groups and permissions in Netbox
Creating Netbox-internal groups
Now it’s time to make usage of the Administrator account (Login with Active Directory/LDAP) which has access to the Django admin Web UI. In the Netbox/Django backend I’m creating two groups which will control the Netbox-specific permissions to objects like sites, racks, devices, and so on.
Creating Netbox-internal permissions
The next step is to create permissions. In my example I’m creating two permissions, one for read-only (can view) and a second one for read-write (can view/ can add/ can change / can delete). I’m assigning all Objects to the permission and then the group. For the read-only permission I’m assigning the grp.netbox.read-only group and for the read-write permission the grp.netbox.read-write group.
Adding AD/LDAP users to Netbox-internal groups
To assigned an Active Directory user to a Netbox-internal group (with the proper permissions), the AD User must have logged in at least one time to be recognized by Netbox. Afterwards the AD User can assigned to the Netbox-internal group, in this case to grp.netbox.read-only with read-only permissions:
The expectation is now that this Active Directory user has now the Netbox-internal group grp.netbox.ro with the read-only (can view) permission to all Objects assign. A quick check shows now in Netbox that this Active Directory User is now able to view for example the device objects. Please note that the “Add” and “Import” icons in the Menu items are not shown and the function behind those menu items is not accessible.
For other Active Directory users, for example the ones who should have read-write access, I’m repeating the step to add AD/LDAP users to the Netbox-internal groups. Based on the assigned permissions and groups in Netbox, a lot of finer views can be created, for example a group which has only access to IPAM (IP Address Management) or another group which can only view Racks and Devices, and so on.
Read the Netbox documentation about LDAP Configuration and Permissions as well the documentation about the Django authentication system. During my configuration session I found those links quite useful:
NetBox: LDAP Configuration
Django: User authentication in Django
Verify the users, groups and permissions you configured before deploying those in an enterprise environment. Create test users and groups, verify if the permissions work as you wanted them to work and document the process. A test lab with virtual servers which can be restored with Snapshots is helpful.