Kerberos token failure for LDAP authentication ... caddr is []
Article ID: 403535
Updated On:
Products
Issue/Introduction
Customer had a succesful policy that used Kerberos authentication, specifically the policy includes the following snippet:
...
Require Windows Integrated Authentication Credentials
Request: Authenticate against XXXXX Active Directory
...
One day, they started seeing we are seeing below exception in SSG for kerberos authentication. According to the feedback, there were calls went successfully, however many more failed:
2025-06-30T14:30:34.469-0400 INFO 995 com.l7tech.server.message: Processing request for service: XXXXXXXXService [/XXX/XXXX
edulingService]
2025-06-30T14:30:34.469-0400 INFO 995 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -4: Protocol: TLSv1
2025-06-30T14:30:34.469-0400 INFO 995 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: -4:
2025-06-30T14:30:34.469-0400 INFO 995 com.l7tech.server.policy.assertion.credential.http.ServerHttpNegotiate: 4100: Authentication
required
2025-06-30T14:30:34.469-0400 WARNING 995 com.l7tech.server.policy.assertion.credential.http.ServerHttpNegotiate: 8200: Could not proc
ess Kerberos token (Negotiate); error is 'KrbException: Incorrect net address (38)'
2025-06-30T14:30:34.469-0400 INFO 995 com.l7tech.server.MessageProcessor: 3017: Policy evaluation for service WFMSchedulingService
[9d7fa696f3c3ac7fa159b7e1208ebaaa] resulted in status 401 (Authentication Required)
2025-06-30T14:30:34.469-0400 WARNING 995 com.l7tech.server.message: Message was not processed: Authentication Required (401)
It is also worthwhile to mention that for those users that worked originally, log out and log back in would face the same failure situation.
After using the following KB
Enable Kerberos debug on CA APIM layer7 gateway
to enable the kerberos debug log, we received the following:
2025-07-02T11:32:22.274-0400 INFO 293 STDOUT: default etypes for permitted_enctypes: 18 17 16 23.
2025-07-02T11:32:22.274-0400 INFO 293 STDOUT: >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
2025-07-02T11:32:22.275-0400 INFO 293 STDOUT: MemoryCache: add 1751470341/001191/533F8D482F02318309637FDA4D1FDCB5/[email protected] to [email protected]|HTTP/[email protected]
2025-07-02T11:32:22.276-0400 INFO 293 STDOUT: >>> KrbApReq: initiator is /999.999.999.999, but caddr is []
2025-07-02T11:32:22.277-0400 INFO 293 com.l7tech.server.message: Processing request for service: XXXXService [/XXX/XXXXX
edulingService]
Environment
Component: APIM Gateway
Cause
In some case, customer reported back that the Microsoft Defender for Endpoint enabled the following regkey on the Active Directory Domain Controller:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
KdcUseClientAddresses REG_DWORD 0x1
KdcUseClientNetBIOSAddresses REG_DWORD 0x1
Resolution
After removing the following regkey on the Active Directory Domain Controller, the issue was resolved:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
KdcUseClientAddresses REG_DWORD 0x1
KdcUseClientNetBIOSAddresses REG_DWORD 0x1
Note that the KdcUseClientAddresses default value is 0x0.
Please refering to the following Microsoft document for more details:
Kerberos protocol registry entries and KDC configuration keys in Windows
Feedback
