LDAP binding failed

[EddieSon]

Hello, 

We have 3x Duo authentication Proxy servers
version: 4.6.1
OS: Windows Server 2019 
---------
Config

; Complete documentation about the Duo Auth Proxy can be found here:
; https://duo.com/docs/authproxy_reference

; NOTE: After any changes are made to this file the Duo Authentication Proxy
; must be restarted for those changes to take effect.

; MAIN: Include this section to specify global configuration options.
; Reference: https://duo.com/docs/authproxy_reference#main-section
;[main]

; CLIENTS: Include one or more of the following configuration sections.
; To configure more than one client configuration of the same type, append a
; number to the section name (e.g. [ad_client2])
[main]
debug=true

[ad_client]
host=*DC1 IP*
host_2=*DC2 IP*
auth_type=sspi
search_dn=DC=domain,DC=org
transport=ldaps
ssl_ca_certs_file=C:\Program Files\Duo Security Authentication Proxy\conf\LDAPS_SSC.cer
ssl_verify_hostname=false

; SERVERS: Include one or more of the following configuration sections.
; To configure more than one server configuration of the same type, append a
; number to the section name (e.g. radius_server_auto1, radius_server_auto2)

[radius_server_auto]
ikey=*REDACTED*
skey_protected=*REDACTED*
api_host=api=*.duosecurity.com
radius_ip_1=Firewall1 IP
radius_secret_protected_1=*REDACTED*
failmode=secure
client=ad_client
port=1812
;pass_through_all=true

[sso]
; Remote Identity Key, unique to this authentication source
rikey=*REDACTED*

; Uncomment the service_account_username and service_account_password lines if you are using NTLM or plain authentication.
; Then, enter your Active Directory service account username and password in the spaces provided.

; service_account_username=
; service_account_password=

Background: 
This morning around 9am, we upgraded all 3 of our Duo auth proxies to 6.4.2. We also enabled a GPO to start blocking NTLMv2 Authentication domain wide. Around 2pm, we started receiving reports from end users that they were unable to access SSO Enabled SaaS apps. 

Looking at the logs we saw two major issues stand out:

LDAPMessage(id=7, value=LDAPBindResponse(resultCode=49, errorMessage=b'80090302: LdapErr: DSID-0C0906AC, comment: AcceptSecurityContext error, data 1, v4563\x00'), controls=None)
2025-02-06T18:41:11.217877-0500 [duoauthproxy.lib.log#critical] LDAP bind failed

And an error message stating we're missing the service account & password, even know that we're using integrated auth type. (Still attempting to find this error message to post for context)

Troubleshooting steps:
1)Disabled NTLMv1/2 blocking GPO. ran gpupdate /force on all 3 Auth proxies, and DC. Validated that GPO was disabled through gpresult /r /scope computer 
2) downgraded auth proxy back to 6.4.1
3) reinstalled auth proxy 
4) stopped the auth proxy on all servers but one 
5) attempted plain/clear settings for transport/auth type 
6) validated that DC was talking on required ports. 
7)Validated that Duo Desktop/RADIUS is still working

At this point, we're at a loss for what it could be, we do have a ticket open with support, but given this issue severity, we're looking at all levels of support to get this back up and running. 

Any and all help is appreciated  greatly. Thank you, and have a wonderful night/day. 

[Ken Stieers]

Try using names for the domain controllers.
That makes them use Kerberos instead of NTLM


To verify the kerberos name run

Setspn -L


-L - lists the spns

Your dcs should have some names listed.

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/894d0999-7d79-4e81-a407-7bcf6522b0a7

[EddieSon]

Hey Ken, 

Thanks for the suggestion! We do have FQDNs in for the hosts entries within the config. 

I was able to resolve the issue as, the GPO that was restricting the NTLM versions allowed wasn't enabled correctly. Once I fixed this, the issue was resolved. 

This still leads me to another question, is there ability to limit all communications to only go through kerberos? Or, does it require us to keep NTLMv2 enabled? (I can start another topic if needed.) 

Thank you

[Ken Stieers]

Per the Duomdocs, it should use trynKerberos and falls back to NtLM if you use a name:


"Sspi"

Integrated Windows authentication. The server that hosts the Authentication Proxy must be a Windows server joined to an Active Directory domain. There is no need to provide service_account_username and service_account_password; authentication uses the context of the account that starts the "Duo Security Authentication Proxy" service (defaults to the domain-joined machine account).

If the host value is a domain controller with hostname, the proxy will use Kerberos if an LDAP Service Principal Name (SPN)<> exists for that target DC as ldap/hostname. If no such SPN exists, the proxy falls back to NTLM.

If the host value is an IP address, the proxy will use NTLM.

If the transport type is CLEAR (the proxy default), then the proxy will use LDAP Signing and Encryption (or "Sign and Seal") if the domain controller allows it.

Supported starting with Authentication Proxy v5.0.0.

[DuoKristina]

Ope - I didn't see that you resolved the issue as caused by the NTLMv2 GPO.

Leaving the info below in case it helps someone in the future:

SSO AD auth doesn't use what's in [ad_client].

If you look at your SSO AD auth config in the Admin Panel. is that set to use integrated or something else? The default is integrated (aka SSPI), but if you see an error message for SSO AD auth in authproxy.log that mentions a missing username and password that usually means SSO AD auth is set to use NTLM or Plain.

https://duo.com/docs/sso#active-directory:~:text=the%20entire%20forest.-,Authentication%20type,-Select%20the%20type

Mentioning this because your original post wasn't clear on whether "attempted plain/clear settings for transport/auth type" was done just at the authproxy in [ad_client] (which would have no effect on binds for SSO) or also in the Admin Panel in the SSO AD config.