Skip to main content

LevelBlue Completes Acquisition of Cybereason.  Learn More

LevelBlue Completes Acquisition of Cybereason.  Learn More

Services
Cyber Advisory
Managed Cloud Security
Data Security
Managed Detection & Response
Email Security
Managed Network Infrastructure Security
Exposure Management
Security Operations Platforms
Incident Readiness & Response
SpiderLabs Threat Intelligence
Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Operational Technology
End-to-end OT security
Microsoft Security
Unlock the full power of Microsoft Security
Securing the IoT Landscape
Test, monitor and secure network objects
Why LevelBlue
About Us
Awards and Accolades
LevelBlue SpiderLabs
LevelBlue Security Operations Platforms
Security Colony
Partners
Microsoft Security
Unlock the full power of Microsoft Security
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Loading...
Loading...

INFO: Transparent authentication on SWG and virtual authentication hostname

Expand / Collapse


This article applies to:

  • SWG 9.x deployed in transparent mode
  • SWG 10.x deployed in transparent mode

Question:

  • What is the purpose of virtual redirection hostname ?

Information:

When SWG is deployed transparently, it can't authenticate clients using the "HTTP 407 Proxy Authentication" method that it uses in explicit mode.Rather, it must use the same type of response that a web server would send "HTTP 401 Unauthorized".

In order to facilitate this, SWG redirects the traffic to a "virtual authentication hostname".

The virtual authentication hostname must resolve to an external IP so that SWG will have a chance to intercept the traffic and issue an authentication challenge.


When the end-user sends the request to the Scanning Server and the Scanning Server is configured to perform user authentication, the Scanning Server responds with an HTTP 302 Redirect, which redirects the user to a virtual host. The virtual host is pre-configured, and its default value is vhost.finjan.com. The virtual host does not have to be a real host; however, the host name of the virtual host must be resolvable by the enduser.






The end-user then closes the session and opens a new session for the virtual host (which does not actually exist). When Vital Security identifies a request for the virtual host, it knows that it must perform user authentication, and it responds to the end-user with HTTP 401 – Authentication Required. 
The end-user then sends the credentials, and the Scanning Server authenticates the end-user against the Active Directory.


It is recommended to change the virtual authentication hostname to vhost (without ".finjan.com") and hosting the DNS entry for vhost on local DNS servers.
For testing/evaluation purposes we have been using public DNS server addresses, i.g. 8.8.8.8 or 8.8.4.4. 


To contact Trustwave about this article or to request support:


Rate this Article:
     

Add Your Comments


Comment submission is disabled for anonymous users.
Please send feedback to Trustwave Technical Support or the Webmaster
.