Version Affected: All
Overview
SecureAuth's standard on-premises deployment can use Windows Authentication, also known as Windows SSO, to let a user on a domain-joined machine log in with their current credentials. This attempts Kerberos first, and falls back to NTLM if Kerberos fails. It usually isn't obvious that Kerberos is failing when every client is a Windows machine, since NTLM quietly picks up the slack -- the problem tends to surface only once MacOS devices are added, since MacOS cannot fall back to NTLM.
SecureAuth's Cloud IWA service only supports Kerberos, with no NTLM fallback at all -- if the Service Principal Name (SPN) isn't registered correctly, Kerberos cannot grant a ticket, and the login does not happen. This article explains how to enable additional Kerberos logging on the client to help diagnose why Kerberos is failing.
Enable Additional Kerberos Logging
- Open Regedit on the client machine.
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
- Add a new DWORD value named LogLevel.
- Set its value to 1.
- Reproduce the issue.
- Check the System Eventlog for Kerberos errors.
See Microsoft's Kerberos event logging article for more detail on interpreting the results.
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.
Comments
Please sign in to leave a comment.