If NTLM Authentication fails instead of displaying the "NTLM failed" message, to apply the unauthenticated group permissions
NTLM Authentication fails instead of displaying the "NTLM failed" message, to apply the unauthenticated group permissions or the group permission that unauthenticated requests are mapped to in the authentication policy.
Reasoning behind this is that if a none domain laptop is brought into the school and gets WPAD sending them to the NTLM port. Would like to have the ability to choose if the NTLM Failed message is displayed or if it is allowed through as unauthenticated IP requests.
I know it’s been a while since our last update on this idea. There have been a few tweaks to NTLM and AD authentication since the last update but there are still technical limitations with what we can do with the ageing NTLM protocol.
If you are having issues with NTLM good news is we recently introduced our own Identification system called IDex in the Kenilworth release. This can work either with Client software, like NTLM but without the authentication exceptions. Or you can use an Agent which runs on your AD domain controllers.
Either way you can test IDex out alongside NTLM, instructions are included in our help along with download links. https://help.smoothwall.net/Kenilworth/Content/idex/about.htm
Wayne Campbell commented
A simple, although not necessarily a good solution, would be to have non-domain/guest computers use a non nltm aware browser. Firefox ntlm is disabled by default, so it would use the non authenticated rules by default.
Having the option to use a different authentication method upon failure would be great especially for non-domain/guest devices. And if all authentication methods fail it will return the user to the Unauthenticated state where separate policies can be applied to them rather than having no access.
Chris Hill commented
Not sure if this is technically possible. NTLM / Kerberos *work* by sending a 407 response to the user's browser (Proxy Authentication Required), which the user's browser then respond to *if* they support it with a new request supplying credentials.
I think Smoothwall's 'NTLM Failed' screen *is* the 407 response. If the browser doesn't support it, it displays this response - by which time the connection is closed and Smootwall can't do anything about it.
Read more about it here: http://squid.sourceforge.net/ntlm/client_proxy_protocol.html. Smoothwall may be able to do something I can't think of, but I suspect this one isn't actually possible...
This would be a major help for our site. We are having big issues with office 2010 documents downloading in IE 10/11 using NTLM as main proxy auth on IE 10/11.
NTLM issue looking at the Smoothwall logs Office 2010 is trying to download the documents as the computer and not the user. But when user hits cancel it then gets downloaded by IE as the user.
Using Kerberos authentication seems to let office 2010 authenticate with Smoothwall. But we can’t use Kerberos authentication because of issues with Java on websites and the Citrix Receiver.
Darren Jones commented
Having the option to redirect to another method if one fails would be better IMO.
Or perhaps add the ability to fall back to a non transparent authentication mechanism over HTTPS to capture the users credentials that still utilizes their domain credentials when NTLM/Kerberos Fail before finally falling back to the Unauthenticated Group as a last resort.
Nathan Downes commented
Craig Gibson commented
This change is an absolute must! If I want all users that can't authenticate to be blocked I could set up a rule for that. This is a killer for devices that don't support NTLM. They should be seeing the policy assigned to UnauthenticatedIPs.