Explorer

Solved

Explicit Proxy LDAPS Errors After Upgrading DCs to 2025

7 replies
863 views

We use LDAPS to check users belong to an AD group in our explicit proxy policies. Ever since we replaced our domain controllers with Server 2025, users receive a pop-up saying proxy authentication is required.

We use regular bind type, with our AD CA's certificate. This test OK, and diagnose debug application fnbamd -1 shows the certificate working.

The CNI is cn, but I've tried using sAMAccountName and uid.

Looking in Event Viewer on the DCs, I see lots of event id 1216 and 1535

1535

Internal event: The LDAP server returned an error.
Additional Data
Error value:
00000003: LdapErr: DSID-0C060666, comment: Error decrypting ldap message, data 0, v65f4

1216

Internal event: An LDAP client connection was closed because of an error.
Client IP: <ip of firewall>:17943
Additional Data
Error value:
3 The system cannot find the path specified.
Internal ID:
c06065f

I briefly tried disabling ldapserverintegrity and LdapEnforceChannelBinding on the DCs to see if that was the cause, but no change.

Does anyone have any ideas, or should I just log a ticket with TAC?

hillsitsuppAnswer

Explorer

It turned out to be Kerberos. Server 2025 enforces new Kerberos encryption standards. Resetting the user's password generates new Kerberos keys, and the explicit proxy starts working again. That explains why it was only happening for some accounts - we have some accounts with ancient PasswordLastSet dates.

I noticed after regenerating the Fortigate's keytab, and was testing it using klist get HTTP/< firewall's FQDN> on client PCs.

Troubleshooting wasn't helped by having Zulu Java installed on some PCs, which includes a version of klist.exe that takes precedence and doesn't return Windows Kerberos tickets. This led to red herrings, and mild panic about Kerberos being borked.

Jean-Philippe_P

Staff & Editor

Hello hillsitsupp,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Jean-Philippe - Fortinet Community Team

funkylicious

SuperUser

hi,

have you installed the root ca and any intermediate certs on the FGT from the new DC ?

"jack of all trades, master of none"

hillsitsuppAuthor

Explorer

Yep, I've installed the CA cert. diag deb app fnbamd shows the cert is good. I even got OCSP running on our domain, as the Fortigate tries it for CRL.

LDAPS is connecting OK, but it doesn’t seem to return a matching user Distinguished Name.

funkylicious

SuperUser

i assume that the initial configuration was done following this/a similar guide?

https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/826729/explicit-proxy-authentication

"jack of all trades, master of none"

quintinmorrow

New Member

LDAPS problems after upgrading domain controllers can be tricky because even small changes in certificates or security settings can break authentication. I’ve seen cases where the proxy still trusted the old certificate chain or the DC started enforcing stricter TLS requirements. Double checking the certificate configuration and LDAP settings on both sides usually helps narrow it down.

hillsitsuppAuthor

Explorer

We weren't using LDAPS before. So I changed it to LDAPS, installed the CA cert, and tested with diag deb app fnbamd. The cert checks out OK. I've been through the settings several times, and walked a colleague through it as a form of rubber duck debugging, but the cause is still not apparent [sigh]

I've raised a ticket with TAC.

hillsitsuppAuthorAnswer

Explorer

It turned out to be Kerberos. Server 2025 enforces new Kerberos encryption standards. Resetting the user's password generates new Kerberos keys, and the explicit proxy starts working again. That explains why it was only happening for some accounts - we have some accounts with ancient PasswordLastSet dates.

I noticed after regenerating the Fortigate's keytab, and was testing it using klist get HTTP/< firewall's FQDN> on client PCs.

Troubleshooting wasn't helped by having Zulu Java installed on some PCs, which includes a version of klist.exe that takes precedence and doesn't return Windows Kerberos tickets. This led to red herrings, and mild panic about Kerberos being borked.

Sign up

Login with SSO

Login to the community

Login with SSO