IWA Health Check fails: Error_to_auth_result(), mapping unknown error code 39756033 to AUTH_E_ONBOX_UNMAPPED

Products

ProxySG Software - SGOS

Issue/Introduction

The health check fails with the following message.

Enabled Check failed DOWN
Last status: The IWA direct realm encountered an unmapped error code, contact your system administrator.
Successes (total): 0 (last): Never (consecutive): 0
Failures (total): 411 (last): Mon, ## Sep 2023 ##:##:00 GMT (consecutive): 411 (external): 0
Last response time: 0 ms Average response time: 0 ms
Minimum response time: 0 ms Maximum response time: 0 ms

Request that require authentication are not possible any longer.

Resolution

Investigating the LSA debug log reveals the below error, and more.

####.###_Error_to_auth_result(), mapping unknown error code 39756033 to AUTH_E_ONBOX_UNMAPPED_ERROR 2425352
####.### LW_GSSAPI_Service_context::Initialize: gss_acquire_cred failed. Major: 0xD0000, Minor: 0x25EA101(39756033). No principal in keytab matches desired name

The "No principal in keytab matches desired name (disp_status.c: 156)" error happens when there is a mismatch between the principal name specified and the principal names stored in the keytab file.

Here are some common reasons and steps to resolve this issue:

Check the Service Principal Name (SPN): Ensure that the SPN (Service Principal Name) used in your application matches the SPN stored in the keytab file. The SPN should be specified in the correct format, such as HTTP/hostname@REALM for HTTP services.

Keytab File Mismatch: Verify that you are using the correct keytab file. Make sure that the keytab file you are using matches the service and host for which it was created.

Correct Principal Name: Ensure that the principal name used in your application code matches the principal name stored in the keytab. The principal name consists of the service name and hostname (e.g., HTTP/hostname@REALM).

Keytab File Location: Double-check the path to the keytab file in your application code. Ensure that the file exists at the specified location.

Keytab File Permissions: Verify that the keytab file has the correct permissions, allowing the application to read it. Incorrect permissions can lead to authentication failures.

Host Name Resolution: Ensure that the hostname used in the SPN and keytab matches the actual hostname of the server where the service is running. Hostname resolution issues can cause this error.

Realm Configuration: Ensure that the Kerberos realm configuration is correctly set up on the server and client sides. Verify that the realm name specified in the SPN and keytab matches the actual Kerberos realm.

Debugging: Enable debugging for Kerberos (e.g., by setting the KRB5_TRACE environment variable) to get more detailed information about the error. This can help pinpoint the exact issue.

Check for Typos: Carefully check for any typos or syntax errors in your code, SPN, and keytab file references.

Recreate the Keytab: If you suspect that the keytab file is corrupted or mismatched, you may need to recreate it using the correct service principal and hostname.

Verify Kerberos Configuration: Ensure that the Kerberos configuration files (typically krb5.conf) are correctly configured with the realms and KDC information.

Check DNS Configuration: Ensure that DNS resolution is working correctly, and hostnames can be resolved to IP addresses.

If you have access to the Kerberos KDC (Key Distribution Center) and realm configuration, you may need to work with your Kerberos administrator to ensure that the keytab and realm settings are correctly aligned with your application's requirements.

Also, the HTTP Service Principal Name (SPN) of the ProxySG may be missing in the Key Distribution Center (KDC). To fix this, please follow the guidance in the Tech, Article below.

Kerberos authentication fails against ProxySG with error

Please ensure the appliance can communicated with the AD DC and please rejoin the appliance to the domain.

Workaround: Utilize NTLM for authentication.

Note: We do not see a product issue, from the data shared.

In a particular use case, rejoining the appliance back to the domain resolved the issue.