Active Directory auth failing

[benwa]

I've been having some weird auth issues for a couple of days now after updating to 2.3.0.
I have all of my users as AD auth'd, except for the admin account and one other account.

System info

root@netbox [ ~/netbox-docker ]# uname -a
Linux netbox 5.10.152-3.ph4-esx #1-photon SMP Fri Nov 11 02:55:53 UTC 2022 x86_64 GNU/Linux
root@netbox [ ~/netbox-docker ]# docker --version
Docker version 20.10.14, build a224086
root@netbox [ ~/netbox-docker ]# docker-compose --version
Docker Compose version 2.11.0
root@netbox [ ~/netbox-docker ]# docker image ls
REPOSITORY               TAG          IMAGE ID       CREATED        SIZE
postgres                 14-alpine    664ff9e724c9   4 days ago     216MB
redis                    7-alpine     96a149ad0157   4 days ago     28.4MB
netboxcommunity/netbox   v3.3-2.3.0   7f19625357e4   13 days ago    570MB
netboxcommunity/netbox   latest       d260fbc6366f   2 weeks ago    571MB
caddy                    2-alpine     006d393a4e6a   4 weeks ago    46.8MB
redis                    6-alpine     48822f443672   5 weeks ago    25.5MB
postgres                 <none>       aac01494762a   5 weeks ago    216MB
netboxcommunity/netbox   v3.1-1.5.1   39df74517134   9 months ago   456MB

Domain Controllers are all Windows Server 2019, Forest Functional Level at 2016.

Configs

root@netbox [ ~/netbox-docker ]# cat docker-compose.override.yml
version: '3.4'
services:
  netbox:
    restart: unless-stopped
    environment:
      REMOTE_AUTH_ENABLED: "True"
      REMOTE_AUTH_BACKEND: "netbox.authentication.LDAPBackend"
      AUTH_LDAP_SERVER_URI: "ldaps://REDACTED.com"
      AUTH_LDAP_BIND_AS_AUTHENTICATING_USER: "True"
      AUTH_LDAP_USER_SEARCH_BASEDN: "DC=REDACTED,DC=com"
      AUTH_LDAP_GROUP_SEARCH_BASEDN: "DC=REDACTED,DC=com"
      AUTH_LDAP_GROUP_TYPE: "NestedActiveDirectoryGroupType"
      AUTH_LDAP_ALWAYS_UPDATE_USER: "True"
      AUTH_LDAP_REQUIRE_GROUP_DN: "CN=NetBox,OU=NetBox,OU=Security Groups,OU=No Replication,DC=REDACTED,DC=com"
      AUTH_LDAP_IS_ADMIN_DN=CN: "NetBox - Administrators,OU=NetBox,OU=Security Groups,OU=No Replication,DC=REDACTED,DC=com"
      AUTH_LDAP_IS_SUPERUSER_DN: "CN=Domain Admins,CN=Users,DC=REDACTED,DC=com"
      LDAP_IGNORE_CERT_ERRORS: "True"
      LOGLEVEL: "DEBUG"
  netbox-housekeeping:
    restart: unless-stopped
  netbox-worker:
    restart: unless-stopped
  postgres:
    restart: unless-stopped
  redis:
    restart: unless-stopped
  redis-cache:
    restart: unless-stopped
  tls:
    restart: unless-stopped
    image: caddy:2-alpine
    depends_on:
      - netbox
    volumes:
      - ./cert.crt:/etc/ssl/private/cert.crt:ro,z
      - ./key.key:/etc/ssl/private/key.key:ro,z
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
    ports:
      - 80:80
      - 443:443
root@netbox [ ~/netbox-docker ]# cat configuration/ldap/extra.py
####
## This file contains extra configuration options that can't be configured
## directly through environment variables.
## All vairables set here overwrite any existing found in ldap_config.py
####

## This Python script inherits all the imports from ldap_config.py
# from django_auth_ldap.config import LDAPGroupQuery # Imported since not in ldap_config.py

## Sets a base requirement of membetship to netbox-user-ro, netbox-user-rw, or netbox-user-admin.
# AUTH_LDAP_REQUIRE_GROUP = (
#     LDAPGroupQuery("cn=netbox-user-ro,ou=groups,dc=example,dc=com")
#     | LDAPGroupQuery("cn=netbox-user-rw,ou=groups,dc=example,dc=com")
#     | LDAPGroupQuery("cn=netbox-user-admin,ou=groups,dc=example,dc=com")
# )

## Sets LDAP Flag groups variables with example.
# AUTH_LDAP_USER_FLAGS_BY_GROUP = {
#     "is_staff": (
#         LDAPGroupQuery("cn=netbox-user-ro,ou=groups,dc=example,dc=com")
#         | LDAPGroupQuery("cn=netbox-user-rw,ou=groups,dc=example,dc=com")
#         | LDAPGroupQuery("cn=netbox-user-admin,ou=groups,dc=example,dc=com")
#     ),
#     "is_superuser": "cn=netbox-user-admin,ou=groups,dc=example,dc=com",
# }

## Sets LDAP Mirror groups
AUTH_LDAP_MIRROR_GROUPS = [
    'NetBox - Auth - Admin',
    'NetBox - Auth - Viewer',
    'NetBox - Circuits - Admin',
    'NetBox - Circuits - Viewer',
    'NetBox - DCIM - Admin',
    'NetBox - DCIM - Viewer',
    'NetBox - Extras - Admin',
    'NetBox - Extras - Viewer',
    'NetBox - IPAM - Admin',
    'NetBox - IPAM - Viewer',
    'NetBox - Tenancy - Admin',
    'NetBox - Tenancy - Viewer',
    'NetBox - Users - Admin',
    'NetBox - Users - Viewer',
    'NetBox - Virtualization - Admin',
    'NetBox - Virtualization - Viewer',
    'NetBox - Wireless - Admin',
    'NetBox - Wireless - Viewer'
    ]

Error message

wrongname is an account that doesn't exist. Notice the extra log lines. rightname is an account that does exist. Those extra lines are not there, telling me that the LDAP bind is working and it can find the account via sAMAccountName, but something else is wrong.

netbox-docker-netbox-1  | DEBUG Binding as
netbox-docker-netbox-1  | DEBUG Invoking search_s('DC=REDACTED,DC=com', 2, '(sAMAccountName=wrongname)')
netbox-docker-netbox-1  | ERROR search_s('DC=REDACTED,DC=com', 2, '(sAMAccountName=wrongname)') raised OPERATIONS_ERROR({'msgtype': 101, 'msgid': 2, 'result': 1, 'desc': 'Operations error', 'ctrls': [], 'info': '000004DC: LdapErr: DSID-0C090A5C,
comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563'})
netbox-docker-netbox-1  | search_s('DC=REDACTED,DC=com', 2, '(sAMAccountName=wrongname)') raised OPERATIONS_ERROR({'msgtype': 101, 'msgid': 2, 'result': 1, 'desc': 'Operations error', 'ctrls': [], 'info': '000004DC: LdapErr: DSID-0C090A5C, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563'})
netbox-docker-netbox-1  | DEBUG search_s('DC=REDACTED,DC=com', 2, '(sAMAccountName=%(user)s)') returned 0 objects:
netbox-docker-netbox-1  | DEBUG Authentication failed for wrongname: failed to map the username to a DN.
netbox-docker-netbox-1  | 172.22.0.8 - - [16/Nov/2022:14:42:30 +0000] "POST /login/ HTTP/1.1" 200 9567 "https://netbox.REDACTED.com/login/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.47"
netbox-docker-netbox-1  | DEBUG Authentication failed for rightname: failed to map the username to a DN.
netbox-docker-netbox-1  | 172.22.0.8 - - [16/Nov/2022:14:42:39 +0000] "POST /login/ HTTP/1.1" 200 9568 "https://netbox.REDACTED.com/login/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.47"```

[menckend]

Based on the "failed to map the username to a DN" message, it seems like the search just isn't finding a match. You might want to try a "deeper" base-DN in the "AUTH_LDAP_USER_SEARCH_BASEDN" value. (OU=?,OU=_,etc...,DC=redacted,DC=com)

If you're unsure of the path, I think that "Get-ADuser -Identity rightname" (powershell) would give you the full distinguished name, which you could just trim the CN section off of. (I'm not an AD admin, so I could be barking up the wrong tree.)

[benwa]

Unfortunately, that doesn't seem to be it. Using a known non-existent account produces a different error, which tells me that it can find the account via sAMAccountName.

[menckend]

Fair point, to be sure.

My own frustrations getting it to work left me very dubious that just because the AD/LDAP server accepted what I was providing as the "username" for the purposes of the LDAP bind, that once bound, it would succeed in "mapping the username to a DN."

The more I thought about it, the more reasonable that seemed. If you're using the user's credentials for both the bind AND the subsequent search, the bind needs that username to be presented in such a way that it works for the DN portion of the bind request, but the "search" function needs it to be presented in a way that it works as the value of a single field that you want to search for (name, SamAccountName, UPN, whatever.)

Were you entering the username field with "REDACTED\SamAccountName_value"? Or just "SamAccountName"? (I gather that AD servers will accept "domain\SamAccountName" in place of a full DistinguishedName for a bind request, but I couldn't get it to work.) Anyway, if you had "domain/SamAccountName" in the "username field", I'm I wouldn't be surprised if netbox ended up searching for a "SamAccountName" value of "domain\SamAccountName" (after the bind was completed, and it was time to actually SEARCH for the user.

Long-story short though.... I had a similar experience to you. Couldn't get LDAP auth working correctly until I plugged in a service-account and set AUTH_LDAP_BIND_AS_AUTHENTICATING_USER to "false." At which point, it worked fine for me.

At some point though, I wound up populating the "AUTH_LDAP_USER_DN_TEMPLATE", and once that was in place (and properly formatted), I was able to set ...BIND_AS_AUTHENTICATING_USER back to true and forego the service-account after all. (I didn't even need the "AUTH_LDAP_USER_SEARCH_BASEDN" value any more.)

Of course, that only works (I think?) if your directory structure is "flat" enough that all of your users would match a common pattern for converting their "username" into the complete DN. (Lucky me, ours is.)

[daniel-zook]

I'm struggling with the same problem. I tried your suggestion to populate the AUTH_LDAP_USER_DN_TEMPLATE, but it hasn't helped so far.

Would you share your docker-compose.override.yml file so that others can see what a working configuration looks like?

Thanks.

[menckend]

@daniel-zook .

@daniel-zook -- Configuration parameters below, but what I think I have just now come to realize is that the "AUTH_LDAP_USER_DN_TEMPLATE" (for obvious reasons) has to match the FULL canonical name of the user in order for it be used successfully in taking the user-supplied credentials and using THEM to complete the initial BIND to AD. That works great for me, but other users in my organization are in different OUs, so I can't use the AUTH_LDAP_BIND_AS_AUTHENTICATING_USER=true mode after all -- because I'd need a different AUTH_LDAP_USER_DN_TEMPLATE for different users :(

For me to get LDAP working the way I want (supporting multiple users), I WILL need to revert to using a separate account for binding, although I'm not happy about storing that account password in netbox.env.

Here is what I added to netbox.env (there was nothing in docker-compose.override.yml that was LDAP related) to get AUTH_LDAP_BIND_AS_AUTHENTICATING_USER=true working (for only users in that one specific OU.)

AUTH_LDAP_SERVER_URI=ldaps://I'LL.NEVER.TELL
AUTH_LDAP_BIND_AS_AUTHENTICATING_USER=True
LDAP_IGNORE_CERT_ERRORS=True
AUTH_LDAP_USER_DN_TEMPLATE="CN=%(user)s,OU=OULEVEL2-STRING,OU=OULEVEL1-STRING,OU=ouUsers,DC=NEVER,DC=TELL"
AUTH_LDAP_USER_SEARCH_BASEDN="OU=UserAccts,OU=ouUsers,DC=bcbsnc,DC=com"
AUTH_LDAP_USER_SEARCH_ATTR=sAMAccountName
AUTH_LDAP_ATTR_FIRSTNAME=first_name
AUTH_LDAP_ATTR_LASTNAME=sn
AUTH_LDAP_ATTR_MAIL=mail
AUTH_LDAP_GROUP_SEARCH_BASEDN="DC=NEVER,DC=TELL"
AUTH_LDAP_GROUP_SEARCH_CLASS=group
AUTH_LDAP_GROUP_TYPE=NestedGroupOfNamesType
AUTH_LDAP_REQUIRE_GROUP_DN="GROUPNAME,OU=BLAHBLAHBLAH,OU=ouGroups,DC=NEVER,DC=TELL""
AUTH_LDAP_IS_ADMIN_DN="GROUPNAME,OU=BLAHBLAHBLAH,OU=ouGroups,DC=NEVER,DC=TELL""
AUTH_LDAP_IS_SUPERUSER_DN="GROUPNAME,OU=BLAHBLAHBLAH,OU=ouGroups,DC=NEVER,DC=TELL""

[tobiasge]

From those logs you can't really see whats going on. You could try to set OPT_DEBUG_LEVEL from python-ldap to get more information. Or you could switch to LDAP (without the 'S') and look at the connection with Wireshark (or similar tools).

[benwa]

I added ldap.OPT_DEBUG_LEVEL: 0 and then 255 to ldap_config.py, though nothing different appeared with docker-compose logs -f netbox

Wireshark also didn't give me anything when I switched to a specific domain controller with just ldap. That is until I set AUTH_LDAP_BIND_AS_AUTHENTICATING_USER to false and supplied a service account for binding. That actually worked!

I'm going to monitor for a few days and try to reenable ldaps and pointing to the domain name instead of a single domain controller.

[timrabl]

So in your case there is no auth bind DN set, i.e. NetBox binds itself anonymously to the AD.

See Djando docs for AUTH_LDAP_BIND_DN:

Default: '' (Empty string)

The distinguished name to use when binding to the LDAP server (with AUTH_LDAP_BIND_PASSWORD). Use the empty string (the default) for an anonymous bind. To authenticate a user, we will bind with that user’s DN and password, but for all other LDAP operations, we will be bound as the DN in this setting. For example, if AUTH_LDAP_USER_DN_TEMPLATE is not set, we’ll use this to search for the user. If AUTH_LDAP_FIND_GROUP_PERMS is True, we’ll also use it to determine group membership.

The DN found for the user is used for user authentication. But only for authentication. Not later.
But that's why you set AUTH_LDAP_BIND_AS_AUTHENTICATING_USER to True.

Here is an excerpt from the Django docs about the parameter: AUTH_LDAP_BIND_AS_AUTHENTICATING_USER

Default: False

If True, authentication will leave the LDAP connection bound as the authenticating user, rather than forcing it to re-bind with the default credentials after authentication succeeds. This may be desirable if you do not have global credentials that are able to access the user’s attributes. django-auth-ldap never stores the user’s password, so this only applies to requests where the user is authenticated. Thus, the downside to this setting is that LDAP results may vary based on whether the user was authenticated earlier in the Django view, which could be surprising to code not directly concerned with authentication.

This means, however, only so much, as that no re bind with the found user happens. But a functional bind must still exist to gather the user DN. Anonymous or with a DN shouldn't matter if anonymous binding to the AD is allowed.

Judging by your log excerpts, the first bind already fails. It almost says it:

netbox-docker-netbox-1 | DEBUG Binding as

So at this point there is no bind, you are still unbound. Then NetBox tries a LDAP search in the given Root DN DC=REDACTED,DC=com and the search attribute sAMAccountName in your case with the value wrongname.

netbox-docker-netbox-1  | DEBUG Invoking search_s('DC=REDACTED,DC=com', 2, '(sAMAccountName=wrongname)')

After that you will get a clear error message:

netbox-docker-netbox-1  | ERROR search_s('DC=REDACTED,DC=com', 2, '(sAMAccountName=wrongname)') raised OPERATIONS_ERROR({'msgtype': 101, 'msgid': 2, 'result': 1, 'desc': 'Operations error', 'ctrls': [], 'info': '000004DC: LdapErr: DSID-0C090A5C,
comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563'})

So the above search_s operation raised an OPERATIONS_ERROR basically telling you:

In order to perform this operation a successful bind must be completed on the connection.

At least here it can be said clearly that the error occurs before the search.
So NetBox can not bind to the AD. Possibly the anonymous bind to the AD is not allowed?

I think you can't avoid either binding anonymously or specifying a bind user. You need a valid DN for authentication at the latest for user LDAP authentication. Django doesn't know against which DN you want to authenticate the user.

Theoretically, there is AUTH_LDAP_USER_DN_TEMPLATE for this, but judging by the NetBox docs, this is no longer required for Windows servers newer than 2012.

[MisterInsane]

I had this exact same issue. Same symptoms and all. I would authenticate with my AD account and receive the same message about cannot map username to a DN, but a different message with a fake account name.

We were upgrading our Netbox install, but I wanted to do a greenfield install since we were doing a large upgrade. I found that the ldap_config.py file was to blame.

I took the file from our previous install and replaced the one in the new install, and magically the LDAP auth worked and mapped my username to a DN.