Reporting using User name through Transparent Mode and HTTPs

You are mixing multiple concepts:

• Proxy mode:   Standard vs Transparent.   I recommend using both, and I have seen no reason to abandon either one.
• HTTPS scanning ON or OFF.   When HTTPS scanning is on, you will need more intensive management, because some websites and web-based software will not work and will require exceptions.   I have had it on in the past, but am currently discouraged and am running with it off.
• Authentication Method.   All of the authentication modes work with either proxy mode, but AD SSO authentication is more complicated with HTTPS scanning OFF.

Specifically:   When HTTPS Scanning is OFF and a user accesses an HTTPS website:

• You cannot filter on the path or querystring portion of the web request, because only the host name is outside of the encrypted content.
• The log contains one entry for an entire web session.   The entry is posted when the session closes and the size parameter is the total bytes transferred during the session.
• You lose visibility to the AD SSO username, because the NTLM information is in the encrypted portion of the packet.   UTM assumes that the username is the same as the last-known username in an HTTP packet from the same IP address.  If there is no prior HTTP packet, the request is processed as an unauthenticated user.  This works pretty well for personal devices, but it is not very workable for shared devices like Remote Desktop Services.

There are several possible approaches to the username problem:

• Add an HTTP request to your organization's list of startup pages.   It should not matter if the site (e.g. google.com) redirects to https, as long as the initial attempt is HTTP.
• Add a Policy and Filter Action for unauthenticated users.
• Try to explain to your users that they need to do an HTTP request before any others. (Yuk!)
• Use a different authentication method than AD SSO (Yuk!)
• Continue using HTTPS Inspection.

My research has shown that there is a lot of non-browser traffic which ignores Standard Proxy settings.   This includes fat-client applications, anti-virus and other automatic update applications, and some operating system overhead.   I recommend using Transparent Mode to ensure that this traffic is monitored, and I recommend implementing an unauthenticated users policy for Transparent Mode to ensure that this traffic is allowed.

At the same time, I recommend using Standard Mode for browser-based traffic, because it monitors non-standard ports.

Finally, you must have a firewall rule to block UDP 443 or the Chrome QUIC protocol will be used to bypass your web filter completely.

Other issues:

A Transparent Mode Filter Profile also acts as a Standard Mode Filter Profile (undocumented feature).   So if you really want to switch, you have to remove the Standard Mode settings from your clients.   Removing the settings is also important for performance reasons.

Create an Exception object that bypassess all features, and migrate your proxy script "DIRECT" sites into that exception.   This will have the same effect and will work equally well, whether using Standard Mode, Transparent Mode, or both.   The Transparent Mode Skip list is unsuitable because it is based on IP address rather than URL. 

Proxy script exceptions are unsuitable it Both mode because the Standard Mode exceptions will fall into Transparent Mode, where the script exception only bypasses Standard Mode.