Jump to content

Recommended Posts

Posted

Hi,

 

we are using NTLM authentication (terminal services compat mode) through a non-transparent proxy to smoothwall

Seeing a lot of 407 returned e.g. even to our wsus server

 

In web filter log get various combinations for Username Source-IP and Group e.g. (ip-adr denotes a 172... ip address)

 

Username         Source-IP    Group	
ip-adr           ip-adr       Staff
ip-adr           ip-adr
domain\user      ip-adr       Staff
ip-adr           ip-adr       Unauthenticated IPs

 

Could someone explain these four different "types" of log entry, e.g. the 3rd one, domain\user ip-adr Staff, is what I would expect to see (?)

so what "causes" the other three types ?

 

Most have return 200 so I guess its working ok, would just like to understand what's going on!

 

There's also quite a lot of of 407s eg

 

Username         Source-IP         Group   Code URL                                                   Category
ip-adr           ip-adr                    407	http://wsus-server-dns-name.local:8530/Rep...         -
ip-adr           ip-adr                    407	https://teach.classdojo.com                           ClassDojo App
ip-adr           ip-adr                    407	https://oneclient.sfx.ms                              Microsoft Office 365
ip-adr           ip-adr                    407	https://www.googleapis.com                            Connect for Chromebooks

 

None of them seem to have a Group.

 

Whats the correct way to fix these ?

Posted

The 407s are normal - basically when there is a request that needs authenticating, there will be 2 407s before the request is then again seen as a 200. 407s are proxy auth required. First one is 'I need to know who you are', 2nd is 'This is who I am' and then the request will be served. However in your case, a lot of these 407s are due to the fact that the software cant respond to a NTLM request.

 

The correct way to fix those is to move away from using active proxy auth methods i.e. NTLM or Kerberos - these days it's not just browsers that use HTTP(S), everyone and their grandmother writes apps that use HTTP(S) but none of those apps are likely to have any support for active auth methods on a proxy.

 

I would recommend using our iDex system instead for domain user identification. Raise a case with support or get your Smoothwall account manager to request an auth rework so we can assist in configuring this.

  • Thanks 1
Posted
The 407s are normal - basically when there is a request that needs authenticating, there will be 2 407s before the request is then again seen as a 200. 407s are proxy auth required. First one is 'I need to know who you are', 2nd is 'This is who I am' and then the request will be served. However in your case, a lot of these 407s are due to the fact that the software cant respond to a NTLM request.

 

The correct way to fix those is to move away from using active proxy auth methods i.e. NTLM or Kerberos - these days it's not just browsers that use HTTP(S), everyone and their grandmother writes apps that use HTTP(S) but none of those apps are likely to have any support for active auth methods on a proxy.

 

I would recommend using our iDex system instead for domain user identification. Raise a case with support or get your Smoothwall account manager to request an auth rework so we can assist in configuring this.

 

Or just follow the helpdesk article - it's actually really easy to switch to iDex :)

  • Thanks 1
Posted

Our LEA (who set up the smoothwall for us) recommended not to use iDex as it had a few "issues".

To be fair this was a few years ago so maybe things have moved on.

 

@ibpalle thanks for the 407 info, still a bit confused about the groups logged though e.g. Staff vs Unauthenticated IPs vs "nothing" ?

 

Also is the first 407 coming straight back from the smoothwall and in it's http response it is telling e.g. chrome to provide authentication via NTLM,

so then chrome sends the user as domain\user, smoothie looks them up in AD, assigns to staff group then makes request to web server, all ok 200

so returns page to chrome.

 

But you say "...in your case, a lot of these 407s are due to the fact that the software cant respond to a NTLM request"

by software do you mean the web server ? I thought the NTLM auth request was just for the smoothwall to know who was making the request,

not actually used to get page from server ? (not doing any https inspection for staff in case that makes a difference)

Posted
By software I mean anything that isn't a browser, using HTTP(S) - Things like Microsoft Office 365 apps that can't reply to a NTLM request. Microsoft updates. iTunes. The listgoes on an on.
Posted (edited)

ah ok so its the clients that get the NTLM response from smoothwall (HTTP Proxy-Authenticate response header)

but they aren't "coded" to work with that type of authentication?

 

As far as I'm aware everything is "working" (though maybe not optimal!) using NTLM auth (for domain PCs/ laptops)

(plus ipads / chromebooks are on a transparent proxy (no auth: staff or students for unauth requests))

 

Will put idex on my (long) list of stuff to investigate

Edited by mrstrong
Posted
ah ok so its the clients that get the NTLM response from smoothwall (HTTP Proxy-Authenticate response header)

but they aren't "coded" to work with that type of authentication?

 

Indeed, something I had issues with before was the Teamviewer app. The requests came through as unauthenticated, but all other user requests from the same machine were the IP and username, Teamviewer was just IP. Some things can't respond to NTLM requests like that.

 

Removed that mess when we got rid of an explicit proxy setup!

Posted
Indeed, something I had issues with before was the Teamviewer app. The requests came through as unauthenticated, but all other user requests from the same machine were the IP and username, Teamviewer was just IP. Some things can't respond to NTLM requests like that.

 

Removed that mess when we got rid of an explicit proxy setup!

 

This is the main reason for iDex, login scripts or RADIUS on BYOD. By making the identification/authentication of users happen in a separate process than the actual browsing to avoid issues with apps not understanding active proxy auth methods.

Posted
For ref I don't use a Smoothwall, but other filtering products. I find proper transparent setups far more forgiving in terms of weird niggles like this, but its always a constantly evolving world;)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...