ProxySG TechBrief Enabling Transparent Authentication What is Transparent Authentication? Authentication is a key factor when defining a web access policy. When the Blue Coat ProxyxSG is configured for transparent mode, a client s web traffic is redirected first to the ProxySG before sending it on to an origin server. In order to authenticate users, the Blue Coat appliance must act as the origin server to the client. Therefore, authentication request will be sent to the client as if they came from the origin server. Transparent authentication can be deployed using authentication mechanisms such as NTLM, LDAP, RADIUS or a local password file. Why Enable Transparent Authentication with the ProxySG? Authentication through the ProxySG enables an administrator to define powerful user/group-based policies to manage and monitor access to your network resources. Transparent authentication requires special mechanisms to authenticate users as they are not directly connected to the Blue Coat appliance, but the requests are transparently redirected. The Blue Coat ProxySG implements two different transparent authentication mechanisms: IP address-based transparent proxy authentication Cookie-based transparent proxy authentication With IP address transparent proxy authentication, a user s client IP address is used as the temporary authentication and/or authorization state. With cookie-based transparent authentication, a client cookie (issued by the Blue Coat ProxySG ) is used as the temporary authentication and/or authorization state. This approach is similar to having a virtual Blue Coat network of origin servers and implementing a single sign-on scheme for multiple domains. Another benefit to using transparent cookie-based authentication is that logging and tracking of individual users is much easier. If a desktop is being tracked through an IP address and the user resets their IP address, it makes it much more difficult to identify where a user if going on the Internet. Through transparent cookie-based authentication, the ProxySG can track a user s movements based on the temporary cookie in use for that session. The user s URL attempts can be logged and denied depending on corporate policy. To alleviate security concerns, the temporary state is only valid until a configurable time to live (TTL) has been reached. After the expiration of the TTL, the user is again challenged for their authentication credentials. Therefore, it is important to configure a TTL value that meets your corporation s enterprise security needs. Use the following table to determine which type of transparent authentication is best for your environment. 1 Technical Brief
IF Use Rationale The network uses DHCP The topography includes a NAT firewall The network uses proxy chaining There is a router or Layer-4 switch between clients and the Security Appliance Client machine security is an issue Client machine security is an issue Cookie-based authentication Cookie-based authentication Cookie-based authentication Cookie-based authentication IP address-based or cookie-based authentication with caveats In IP address-based transparent proxy authentication, an IP address must map to a unique user. Using DHCP, however, IP addresses can be recycled. If the last user with a certain IP address was authenticated, a new user with the same IP address will be granted access until the TTL expires. All users behind the firewall appear to use the same IP address. As a result, only the first user will be authenticated. A downstream proxy can rewrite a client IP address with its own; multiple users could, potentially, be assigned the same client IP address. With a router or L4 switch users could, potentially, come to the Security Appliance with the same IP address. The result is that only the first user is authenticated. Client-side cookies can be forged or stolen, however, Blue Coat uses unique secure cookie mechanisms that make it difficult to copy or forge cookies. Configurable TTL on the cookie also guards against such threats. stems, How to implement Transparent Authentication There are four steps to implement transparent authentication services 1. Create an authentication realm on the ProxySG 2. Select IP or cookie-based authentication 3. Enable authentication through the Blue Coat Visual Policy Manager and create a policy based on user and group identification 4. Test the transparent authentication policy The assumption is made that all web traffic will be redirected to the ProxySG via a Layer4 switch or a router using WCCP. 2 Technical Brief
Step 1 Create a REALM Create an NTLM realm using the Blue Coat GUI management console by selecting the Authentication option and the NTLM button. Note: NTLM will be used as an example only. Your environment may require a different realm type. 1. Click the New button. The Add Realm dialog box is displayed. Type in NTLM as the Realm name 2. Specify the IP address and port for the primary NTLM server where the CAASNT Agent Service is running. The default port is 16101. Click on OK. 3. Click Apply to save your changes. Repeat the above steps for additional NTLM servers, up to a total of 40 when needed. 3 Technical Brief
t Step 2 Select Transparent Authentication scheme 1. Select Management from the Blue Coat GUI Management home page. 2. From the Authentication Option, select the Transparent Proxy button. 3. Select a transparent proxy method Cookie or IP address-based. The default is Cookie. If you select Cookie, the Cookie Type radio buttons are made available. Click either Session, for cookies that will be deleted at the end of a session or Persistent for cookies that will remain on a client machine until the TTL (Time To Live) is reached or the credentials cache is flushed. The default is Session. 4 Technical Brief
4. Enter the TTL amount of time (in minutes) for user credentials to remain in the cache before being purged. The default is 15 minutes. Your corporate security policy will dictate this timeframe. Note: A value of 0 (zero) for the IP address TTL means: ignore this TTL and only re-prompt the user for credentials once the specified cache duration for the particular realm has expired. 5. The Global Virtual URL is set to www.cfauth.com/. You can leave this at the default or change it to preferably the IP address of the ProxySG, unless you are doing secure credentials over SSL. Using the IP address of the ProxySG enables you to be sure that the correct ProxySG is addressed in a cluster configuration. Transparent authentication requires a virtual URL to be set to allow clients to transparently authenticate to the ProxySG. 6. Add the virtual host domain to the DNS service for your organization so that browsers, when redirected to the virtual URL, can resolve the hostname in the URL. (If you use the virtual hostname provided by Blue Coat www.cfauth.com you do not need to add the hostname to the DNS service.) 7. For Windows Internet Explorer NTLM users who want true single-sign-on (allowing Internet Explorer to provide your credentials automatically when challenged), set the virtual URL to a hostname that is resolvable to the IP address of the ProxySG by the client machines. Dots (for example, 10.1.1.1) are not allowed. The ProxySG requires a name. To define the information in Internet Explorer, go to Internet Options>Security>Local intranet>sites>advanced...>web sites. (If you are an XP user, go to Internet Options>Security>Internet>Custom Level, then check Automatic logon with current username and password). For Windows Internet Explorer 6.x users, add the virtual host address to Internet Options>Privacy>Web Sites>Managed Web Sites>Always Allow. 8. Click Apply on the ProxySG management console to save your changes. 5 Technical Brief
Step 3 Enable Authentication using the Visual Policy Manager 1. From the Visual Policy Manager create a new web authentication policy by selecting edit from the VPM tool bar, and choosing Add Web Authentication Layer. 2. Name the new authentication layer NTLM_Authentication or some unique name. Click OK. 3. On the Action field of the policy layer, right click and click on set. The following screen will be displayed. Click on New and Authenticate. 6 Technical Brief
7 Technical Brief
4. A pop-up window will display a list of current realms. Select the realm called NTLM_Authentication (or the name you gave it) and Click on OK. 5. Click on Install Policies to load Policy. 8 Technical Brief
Step 4 - Test Transparent Authentication Policy Test Authentication by opening up an Internet Explorer browser. You will be prompted to enter your NTLM credentials. Successful authentication will display the user (YOGIPC2) in the log tail for a request. This example shows a transparent request for YOGIPC2 via the ProxySG. 1018355897.971 0 10.254.0.210 TCP_HIT/200 4455 GET http://images.mp3.com/mp3s/images/banner_ad/copy.gif YOGIPC2\Administrator DIRECT/- image/gif Conclusion The Blue Coat ProxySG can be configured to meet the security needs of any organization through transparent authentication. Transparent authentication can be configured using IP addressing or a cookie stored on the client desktop to maintain the session. Cookie-based authentication requires a time-to-live (TTL) setting to be enabled. The default is 15 minutes and can be changed to adhere to corporate security requirements. With the Blue Coat ProxySG you can securely and transparently authentication users. Copyright 2004 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by any means nor translated to any electronic medium without the written consent of Blue Coat Systems, Inc. Specifications are subject to change without notice. Information contained in this document is believed to be accurate and reliable, however, Blue Coat Systems, Inc. assumes no responsibility for its use. Blue Coat is a registered trademark of Blue Coat Systems, Inc. in the U.S. and worldwide. All other trademarks mentioned in this document are the property of their respective owners. Contact Blue Coat Systems 1.866.30BCOAT 408.220.2200 Direct 408.220.2250 Fax www.bluecoat.com 9 Technical Brief