Log file for Failed Authentication Attempts?

Jack, I think you can get what you need, but the underlying question is not clear to me.  What question are you trying to answer that leads you to ask this question?

Cheers - Bob

Hey Bob, ok, here is the situation:

We're transitioning over to the UTM from TMG and because we no longer have the TMG Firewall Client providing automatic authentication of any non-proxied applications, we're having to punch holes in the UTM to allow out certain applications that don't know how to authenticate on their own.   Yes, we could use the SAA but it's not automatic and also doesn't log the data quite the same way (shows different username than AD SSO so the data isn't correlated). 

SO, I have a user which has an application which was trying to download files from the internet.  When we tried to use it, it would say "(407) Proxy Authentication Required".  The problem is that I had no idea what URL/IP address it was trying to go to, because the Web Fitlering logs don't show anything when it's just a failed authentication attempt.   It only shows something when the authentication succeeds or if those particular destination URLs (or Source IPs) are exempt from Authentication (which is what i'm trying to add them to). 

I've kinda figured out a workaround now, in that I just punch a hole for the entire IP address of the workstation, let the application get onto the internet and then examine the logs to see where it went.  I was just hoping maybe there was something being logged when a user fails to authenticate to the proxy via the Web Filter module.

Jack, I resolve that issue by configuring the default Profile as Transparent without Authentication instead of Standard with AD-SSO.  If an application doesn't use Windows Internet Settings, the access doesn't get selected by the Standard Profile, so it falls through to the Transparent one.

Cheers - Bob

The problem is that the application itself seems to be Proxy aware, it just doesn't know how to authenticate.  So if I have the proxy settings turned on in IE, it tries to use them and hits the Standard Profile and then fails, with no entry as to where it was trying to go.   

Unfortunatly all this testing has revealed some issues with Transparent vs Standard which I had not noticed in my pre-sales testing, one of which is that it appears the Transparent mode doesn't force any sort of Authentication for HTTPS connections, only HTTP (even with Block Access with failed authentication checked).

You're right.  To get the details of which IPs/FQDNs need an Exception for Authentication, make an Exception for Auth for everything from that workstation - maybe that's what you meant.

Cheers - Bob

To do transparent mode authentication of HTTPS you need to have HTTPS Decrypt and Scan.

One option would be rather than temporarily punching a hole (via exception), try turning off the "Block access on authentication failure".  That would allow the access so that you could see the logs.  In the end its the same result.

I'm not 100% sure but I think that extra logging can be turned on temporarily to find out details of authentication attempts.  If you want to do this log a support ticket and IM me the number.

Regarding extra auth logging (does not apply for AD SSO).

If the information in aua.log is insufficient for identifying the error, debug mode can be activated. This is performed on the command line with the command [removed]
Very detailed information is recorded in the log file. Invoking the command [removed] again deactivates debug mode.

Attention: when using debug mode, passwords can be displayed in clear text.

Note: If authentication problems are incurred in relation to the Web filter/HTTP proxy, it is possible to activate the debug mode here as well.