Version Affected: All
Description:
Our standard deployment can use Windows Authentication, sometimes known as Windows SSO in order to allow a User of a domain joined machine to log in with their current credentials. This will attempt to use Kerberos and if that fails, will fall back to NTLM.
Often, it isn't clear that Kerberos is even failing if you have only Windows boxes and the problem only becomes apparent when you add in MacOS devices as these cannot fallback to NTLM.
Our Cloud offering can also have an IWA service to achieve the same result. However, this only supports Kerberos so without the correct Service Principal Names, you won't be able to use it.
Cause:
If Kerberos does not recognise the Service Principal Name, it will not grant a ticket and so the login will not take place.
Resolution:
To see why Kerberos is failing, you can enable additional Kerberos logging on the client side, to see what the issue is.
1. Open Regedit
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
3. Add a new DWORD value called LogLevel
4. Give this a value of 1
5. Reproduce the issue
6. Check the System Eventlog for Kerberos errors
Special Considerations:
Please see this MS article on the same topic
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-kerberos-event-logging
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.