Netbox Active Directory/LDAP Integration

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 Netbox AD/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:

Netbox: Groups for Netbox AD/LDAP authentication in RSAT
Netbox: Groups for Netbox AD/LDAP authentication in RSAT

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:

    # Users can login into Netbox (AD/LDAP Bind account)
    AUTH_LDAP_REQUIRE_GROUP = "CN=grp.netbox,OU=netbox,OU=Applications,DC=[YOUR_DC],DC=[YOUR_DC]"

    # Mapping AD/LDAP to Django
    # is_active    -> Read-Only           -> grp.netbox.ro
    # is_staff     -> Django admin Web UI -> grp.netbox.adm
    # is_superuser -> Read-Write          -> grp.netbox.ro
    AUTH_LDAP_USER_FLAGS_BY_GROUP = {
        "is_active": "CN=grp.netbox.ro,OU=netbox,OU=Applications,DC=[YOUR_DC],DC=[YOUR_DC]",
        "is_staff": "CN=grp.netbox.adm,OU=netbox,OU=Applications,DC=[YOUR_DC],DC=[YOUR_DC]",
        "is_superuser": "CN=grp.netbox.rw,OU=netbox,OU=Applications,DC=[YOUR_DC],DC=[YOUR_DC]"
    }
Netbox: ldap_config.py

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.

Netbox: Verify Login with Administrator account
Netbox: Verify Login with Administrator account

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 URL https://[NETBOX_HOST]/admin/ is not allowed with this user.

Netbox: Verify Login with User account (Read-Write)
Netbox: Verify Login with User account (Read-Write)

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:

Netbox: Verify Login with User account (Read-Only)
Netbox: Verify Login with User account (Read-Only)

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.

Netbox: Verify Login with User account not in group grp.netbox
Netbox: Verify Login with User account not in group grp.netbox

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.

Netbox: Internal groups for read-write and read-only
Netbox: Internal groups for read-write and read-only

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.

Netbox: Internal permissions for read-write and read-only
Netbox: Internal permissions for read-write and read-only

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:

Netbox: Assign AD/LDAP user to Netox-internal group
Netbox: Assign AD/LDAP user to Netox-internal group

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.

Netbox: Verify AD/LDAP User has read-only permissions
Netbox: Verify AD/LDAP User has read-only permissions

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.

Tips

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:

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.


Share: