Is it possible to split authenication to have some devices use NTLM and others to bind to Kereberos. We are having issues with Ipads\ Iphones\ Smart devices basically when using NTLM Authenication. Has this ever been attempted? Or how do most customers deal with smart devices on their network??
Why do you want a split? We use normally kerberos with NTLM fallback, as not just smartphones may have issues with Kerberos, also printers and other embedded devices.
We use Kerberos with NTLM fallback. So w tray first Kerberos, if this does not work: NTLM and if it still not authenticated, send the client a 407
I am clearing up old authentication rules sets in my environment. Prior admin, started going down the route of separating the based on Client IP. We have:
* 407 Proxy-Authenticate - NTLM Challenge currently setup. This serves very well for a Windows-only joined to a Active Directory domain. https://docs.microsoft.com/en-us/openspecs/office_protocols/ms-grvhenc/b9e676e7-e787-4020-9840-7cfe7...
* But we have 407 Proxy-Authenticate - Basic enabled as well. (not sure why its not a separate rule in our environment.).
With the above configuration, Single authentication attempt failure to the proxy causes 2 attempts to be registered in Active Directory before the browser displays a prompt. Depending on your password policy, a small number attempts will lock out the users account. While I am exploring the option of using Kerberos, Adding a third authentication (Kerberos) method will just cause the account to lockout quicker and unnecessarily.
On some iOS and MacOSX devices (apps), the device makes repeated prompts to authenticate and repeatedly known to lockout accounts. I am not even talking about the iOS devices in Single-App Mode that do no present any UserIP/Password dialog to the user. On MacOSX, I could install an FSSO on a Desktop and possibly use Kerberos. But iOS is different. Presenting a consistent user experience would help. I am leaning toward a Cookie with SAML Service Provider.
If you know the Client IP/subnet does not support a particular authentication you can exclude that authentication method for that Client IP/subnet.
@homeuse - Unless you have it setup differently, Kerberos w/NTLM fallback is not a true Try-Auth setup, where any Kerberos failure causes the MWG to attempt NTLM with the client. Rather, it only does a fallback to NTLM in the specific scenario that the client tried to send an NTLM token while specifying it was doing Kerberos with the 'Negotiate' method. Specifically, if the client should send "NTLM TlRM.....", but instead sends "Negotiate TlRM....", we allow the fallback and request the client try again with only NTLM offered. If the client fails Kerberos with a bad ticket, for example: "Negotate YII.....", it will not fallback to NTLM.
@MichaelJames - One of the key benefits of Kerberos is that the MWG does not need to talk directly to the DC (the KDC) at all. The only point that it would is during group lookup if the Kerberos settings are configured to use NTLM to lookup the groups. But this would not happen if it failed to authenticate in the first place, so no added communication to your DCs will take place.
I have seen successful uses of X509 client certificate auth on mobile devices (with setting the cookie for sessions), but not using a SAML provider before. Let me know how it goes or what you find out.