Active Directory Integration with Blue Coat

Transcription

1 The Web Security Authority. TM Active Directory Integration with Blue Coat NOTE: This techbrief is applicable when using NTLM under Windows 2000 Server. Introduction Windows 2000 server utilizes Active Directory, a directory service that enables organizations to efficiently manage system resources across their enterprise. Users and groups, for example, are stored and managed within Active Directory allowing controlled access to network and system services such as printers, applications and the Internet. Using Active Directory with Windows 2000 drives the need to provide comprehensive proxy authentication with a Blue Coat Security Gateway. Coupled with the Security Gateway an Active Directory environment can achieve the following benefits: Log Web browsing activity by user ID. Organizations can reduce liability by providing an audit trail for browsing activity. Since an IP address is not considered legally binding, an audit trail must be tracked to a specific user ID. Authentication through the Blue Coat Security Gateway can provide a detailed audit trail for Web access. Single Sign-On (SSO). Administrators prefer that network users should not be prompted more than once for their user ID and password. Blue Coat authentication enables Single Sign-On for users of Internet Explorer 4 or later (IE) in an Active Directory environment. User access Webbased resources through the Blue Coat Security Gateway which utilizes Active Directory authentication services. Per User and Per Group Authorization for Network Resources. Varying aspects of authorization to network resources can be provided by both the directory service and a Blue Coat Security Gateway. It is possible to authorize Active Directory groups to a list of URLs, Content Filtering categories, and so on when using the Blue Coat Security Gateway. Per User or Per Group URL Filtering. Using the Blue Coat Security Gateway in conjunction with Active Directory allows a company to authenticate users and allow or disallow access to any URL or URL category. This TechBrief describes how the Blue Coat Security Gateway integrates with Active Directory in native mode. Microsoft offers two domain modes of operation when deploying Active Directory: native mode and mixed mode. Mixed Mode: Mixed mode supports the Security Account Manager (SAM) replication of both Active Directory domain controllers (DCs) and a Windows NT 4.0 or 3.51 domain, allowing older Windows clients to authenticate to the domain. Native mode: Active Directory offers extended security functions in native mode through a user group type known as the Universal group. The Universal Group allows for group nesting such as Global groups within Global groups, and Domain Local groups within Domain Local groups. Windows 2000 servers in the native mode domain can use Domain Local groups from the domain on the local computer and Domain Local groups can be used to assign permissions and rights on the member server. Technical Brief

2 Active Directory Integration with Blue Coat By default, Active Directory installs in mixed mode. However, a domain can be updated from mixed to native mode but not vice versa. Once a domain is converted to native mode, the backup domain contollers (BDCs) will no longer replicate updates to the Active Directory database. So, make sure that all desktops and applications function properly before changing the mixed mode domain to native mode. Additionally, a network can run a pure Windows 2000 network in mixed mode without any problem, but it will not receive the added benefit of the Universal Group function. The Blue Coat Approach to Authentication Blue Coat Systems has implemented Microsoft authentication support via Microsoft s recommended method, the Security Support Provider Interface, or SSPI. Major technology vendors that support SSPI include SAP, Oracle, and IBM, to name a few. The SSPI is a well-defined common API for obtaining integrated security services for authentication, message integrity, message privacy, and security quality of service of any distributed application protocol. How it Works The Blue Coat Security Gateway integrates with Active Directory via the Credential Authentication Agent Service for NTLM (CAASNT) agent that can be installed on any member workstation/server of the domain. Additionally, if a trust relationship exists with other domains of the organization, the agent will authenticate users of other domains as well. Authorization rules for users to access Web resources are defined in the Blue Coat Visual Policy Manager (VPM). Users will authenticate through the Blue Coat Security Gateway utilizing Active Directory to check user credentials. Once the user is authenticated, Blue Coat Security policies can be applied. The following graphic shows the use of VPM to block URL categories for all users on the network. 2 Copyright 2003 Blue Coat Systems, Inc.

3 Installing the CAASNT Agent To provide the Security Gateway the ability to correctly communicate with the domain controller of an NT server, an agent called the Blue Coat NTLM Authentication Agent (CAASNT) must be installed on a Windows NT system somewhere on your network to pass the user requests back and forth. To implement NTLM Authentication, follow these steps: 1. Install the Blue Coat NTLM Authentication Agent Service just as any other service is installed on an NT or Windows 2000 server 2. Create an NTLM Realm 3. Enable NTLM authentication through the Blue Coat Policy Language 4. Create a policy based on user and group identification through the Blue Coat Policy Language Create an NTLM Realm Go to the Security Gateway GUI and add a new realm Management GUI Security Realms press the New button an Add Realm pop-up screen will appear Technical Brief 3

4 Active Directory Integration with Blue Coat Name the realm NTLM and select NTLM as the protocol Specify NTLM as the name for the realm in the Realm name: field. This is just a name to make the realm distinguishable (particularly useful if you have three or more NTLM realms), but since we are only going to have one NTLM realm we will keep it simple. Set the protocol to NTLM Indicate where CAASNT is running The Primary server IP: will NOT be the IP of the directory server instead it will be the IP of the Windows NT/2000 system which has CAASNT running The default of should be used Click on Ok within the Add Realm pop-up window Click Apply on the Realms GUI screen to save your changes 4 Copyright 2003 Blue Coat Systems, Inc.

5 NOTE: The previous steps may be repeated multiple times to add additional NTLM servers, for up to a maximum of Select the Policy category 2. Start the Visual Policy Manager again 3. Create the Authentication Policy VPM Edit Add Web Authentication Policy 4. Name the policy Web Authentication Adjust the name and then click OK Technical Brief 35

6 Active Directory Integration with Blue Coat 5. Set the Action to Authenticate Select the Action field of rule 1 Right click on the field Select Authenticate 6. Select NTLM as the realm to use An Authenticate pop-up window will appear Select the NTLM we just created from the pull-down menu Select OK 6 Copyright 2003 Blue Coat Systems, Inc.

7 7. Move the authentication policy before the access policy Edit Policy Ordering Highlight Web Authentication press Move Up 8. Install the new policy with changes Click Install Policies 9. Test that users are being prompted for authentication now Using Netscape attempt to reach a website, you should receive a credential pop-up window Technical Brief 7

8 Active Directory Integration with Blue Coat Authentication details The Internet Explorer will seamlessly authenticate only if the NTLM authentication method is requested by the proxy or Web server. If another authentication method is requested, the Internet Explorer will prompt the user for the pair login/password. Therefore, to provide the single sign on feature, the Blue Coat Security Gateway implements the NTLM authentication method. When a client needs to authenticate itself to the Blue Coat Security Gateway the following four-way handshake takes place. Note that only parts of the request and status line and the relevant headers are shown here. The security Gateway simply passes on all the messages to the CAASNT agent it receives them. Note: The password is never sent by the user to the Security Gateway 1: Client --> Security Gateway GET... 2: Client <-- Security Gateway 407 Unauthorized Proxy-Authenticate: NTLM 3: Client --> Security Gateway GET... Proxy-Authorization: NTLM <base64 encoded type-1-message> 4: Client <-- Security Gateway 407 Unauthorized Proxy-Authenticate: NTLM <base64 encoded type-2-message> 5: Client --> Security Gateway GET... Proxy-Authorization: NTLM <base64 encoded type-3-message> 6: Client <-- Security Gateway 200 Ok Messages The three messages sent in the handshake are binary structures. Each one is described below as a pseudo-c struct and in a memory layout diagram: byte is an 8-bit field; short is a 16-bit field All fields are unsigned. Numbers are stored in little-endian order Struct fields named zero contain all zeroes. An array length of "*" indicates a variable length field Hexadecimal numbers and quoted characters in the comments of the struct indicate fixed values for the given field. The field flags is presumed to contain flags, but their significance is unknown; the values given are just those found in the packet traces. 8 Copyright 2003 Blue Coat Systems, Inc.

9 Type-1 Message This message contains the host name and the Active Directory domain name of the client. struct { byte protocol[8]; // 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0' byte type; // 0x01 byte zero[3]; short flags; // 0xb203 short dom_len; // domain string length short dom_len; // domain string length short dom_off; // domain string offset short host_len; // host string length short host_len; // host string length short host_off; // host string offset (always 0x20) byte host[*]; // host string (ASCII) byte dom[*]; // domain string (ASCII) } type-1-message : 'N' 'T' 'L' 'M' 4: 'S' 'S' 'P' 0 8: : 0x03 0xb : domain length domain length 20: domain offset : host length host length 28: host offset : host string domain string The host and domain strings are ASCII (or possibly ISO ), are uppercased, and are not nulterminated. The host name is only the host name, not the FQDN (e.g. just "GOOFY", not "GOOFY.DISNEY.COM"). The offsets refer to the offset of the specific field within the message, and the lengths are the length of specified field. For example, in the above message host_off = 32 and dom_off = host_off + host_len. Note that the lengths are included twice (for some unfathomable reason). Technical Brief 9

10 Active Directory Integration with Blue Coat Type-2 Message This message contains the server's NTLM challenge. struct { byte protocol[8]; // 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0' byte type; // 0x02 byte zero[7]; short msg_len; // 0x28 short flags; // 0x8201 byte nonce[8]; // nonce byte zero[8]; } type-2-message : 'N' 'T' 'L' 'M' 4: 'S' 'S' 'P' 0 8: : : message len : 0x01 0x : + server nonce 28: 32: : The nonce is used by the client to create the LanManager and NT responses (see Password Hashes). It is an array of 8 arbitrary bytes. The message length field contains the length of the complete message, which in this case is always 40. Type-3 Message This message contains the username, host name, NT domain name, and the two responses. struct { byte protocol[8]; // 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0' byte type; // 0x03 byte zero[3]; short lm_resp_len; // LanManager response length (always 0x18) short lm_resp_len; // LanManager response length (always 0x18) short lm_resp_off; // LanManager response offset 10 Copyright 2003 Blue Coat Systems, Inc.

11 short nt_resp_len; // NT response length (always 0x18) short nt_resp_len; // NT response length (always 0x18) short nt_resp_off; // NT response offset short dom_len; // domain string length short dom_len; // domain string length short dom_off; // domain string offset (always 0x40) short user_len; // username string length short user_len; // username string length short user_off; // username string offset short host_len; // host string length short host_len; // host string length short host_off; // host string offset byte zero[6]; short msg_len; // message length short flags; // 0x8201 byte dom[*]; // domain string (unicode) byte user[*]; // username string (unicode) byte host[*]; // host string (unicode) byte lm_resp[*]; // LanManager response byte nt_resp[*]; // NT response } type-3-message : 'N' 'T' 'L' 'M' 4: 'S' 'S' 'P' 0 8: : LM-resp len LM-Resp len 16: LM-resp off : NT-resp len NT-Resp len 24: NT-resp off : domain length domain length 32: domain offset : user length user length 40: user offset : host length host length 48: host offset 0 0 Technical Brief 11

12 Active Directory Integration with Blue Coat 52: : message len : 0x01 0x : domain string user string host string LanManager-response NT-response The host, domain, and username strings are in Unicode (little-endian) and are not nul-terminated; the host and domain names are in upper case. The lengths of the response strings are 24. Password Hashes To calculate the two response strings two password hashes are used: the LanManager password hash and the NT password hash. As NTLM uses a challenge/response mechanism, the password is never sent to the Security Gateway and moreover it is unlikely the session could be used by another user. 12 Copyright 2003 Blue Coat Systems, Inc.

13 Conclusion In this TechBrief we have discussed how to utilize the NTLM Authentication services provided by the Blue Coat Security Gateway. These services, in conjunction with the CAASNT agent running on a Windows NT/2000 Server, allows a Blue Coat Security Gateway to provide authentication services for all users on a network utilizing Active Directory in native mode. Technical Brief 13

14 Contact Blue Coat Systems BCOAT Direct Fax The Web Security Authority. TM Blue Coat Systems, a Web security company, has developed the industry s first port 80 security appliance. Safeguarding many of the world's largest corporate networks, this high-performance security appliance intelligently protects against Webbased threats by policing Port 80 the primary hole in the enterprise security infrastructure. Headquartered in Sunnyvale, California, Blue Coat Systems can be reached at or at Copyright 2003 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. Version 1.0