Determining IWA Implementation

I work with a few client software and web applications that aren't clear on which type of IWA they allow for authentication. I've read the manuals/guides to no avail. They contain checkbox features labeled "Enable IWA", and the IWA does seem to work as advertised when authenticated to the machine/domain.

Based on what I know and research I've done, there are two types of IWA: NTLM and Kerberos. I'm familiar with the IIS settings for enabling Negotiate to use either/or NTLM/Kerberos. I'm also familiar with using klist to determine if kerberos tickets are being requested/utilized on domain authenticated systems.

Where I get confused is when a scenario presents itself where an application isn't IIS based (aka can't check Negotiate settings) and where the klist output shows no kerberos tickets and IWA still works. Is this situation always assumed to be IWA NTLM? Are there other forms of IWA that I'm not aware of? I know web applications can pull the currently authenticated user from javascript, but that's a pretty insecure practice and also doesn't seem to be the case here as I've inspected the javascript.

Summary of Questions:

• Are there other forms of IWA that I'm not mentioning here?
• How do I check the IWA type if non-IIS/klist verifiable IWA is being utilized?
• What's the easiest way to check if NTLM is being used that doesn't require me to perform a packet capture?

1. Are there other forms of IWA that I'm not mentioning here?
   A. No other forms - your research was correct and you listed both forms of IWA: NTLM and Kerberos.

2. How do I check the IWA type if non-IIS/klist verifiable IWA is being utilized?
   A. klist verifies Kerberos was used as the IWA type. If klist shows no Kerberos tickets and single sign-on to the web application worked without the HTTP client ever presenting a dialog box asking for username and password, then the authentication type must have been NTLM.

3. What's the easiest way to check if NTLM is being used that doesn't require me to perform a packet capture?
   A. The easiest way to know is to know by circumstance: When the klist output shows no kerberos tickets and IWA still works (no pop-up dialog box), that means NTLM must have been used. NTLM was invoked whenever SSO worked and klist shows no Kerberos ticket to the web application (as in Answer #2 above). That this can be confused though by the existence of a session key in the browser cache, the only way to to truly tell for sure is through either observation of a network trace or server log analysis at the trace/debug level. I'll add though, that if a dialog box asking for username and password does present itself, then the authentication type was not IWA and was most likely was either Basic Authentication or LDAP authentication (Basic auth and LDAP auth are not SSO protocols).