Active Directory Integration with Blue Coat
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:
• LLoogg WWeebb bbrroowwssiinngg aaccttiivviittyy bbyy uusseerr IIDD.. 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.
• SSiinnggllee SSiiggnn--OOnn ((SSSSOO)).. 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 Web-based resources through the Blue Coat Security Gateway which utilizes Active Directory authentication services.
• PPeerr UUsseerr aanndd PPeerr GGrroouupp AAuutthhoorriizzaattiioonn ffoorr NNeettwwoorrkk RReessoouurrcceess.. 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.
• PPeerr UUsseerr oorr PPeerr GGrroouupp UURRLL FFiilltteerriinngg.. 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.
M
Miixxeedd MMooddee:: 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.
N
Naattiivvee mmooddee:: 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
The Web Security Authority.TM
N
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.
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
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 16101 should be used
• Click on Ok within the Add Realm pop-up window
• Click Apply on the Realms GUI screen to save your changes
N
NOOTTEE:: The previous steps may be repeated multiple times to add additional NTLM servers, for up to a maximum of 25.
1. 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
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
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
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.
N
Noottee:: TThhee ppaasssswwoorrdd iiss nneevveerr sseenntt bbyy tthhee uusseerr ttoo tthhee SSeeccuurriittyy GGaatteewwaayy 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.
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 byte zero[2];
short dom_len; // domain string length
short dom_len; // domain string length
short dom_off; // domain string offset
byte zero[2];
short host_len; // host string length
short host_len; // host string length
short host_off; // host string offset (always 0x20)
byte zero[2];
byte host[*]; // host string (ASCII)
byte dom[*]; // domain string (ASCII)
} type-1-message 0 1 2 3 +---+---+---+---+ 0: | 'N' | 'T' | 'L' | 'M' | +---+---+---+---+ 4: | 'S' | 'S' | 'P' | 0 | +---+---+---+---+ 8: | 1 | 0 | 0 | 0 | +---+---+---+---+ 12: | 0x03 | 0xb2 | 0 | 0 | +---+---+---+---+ 16: | domain length | domain length | +---+---+---+---+ 20: | domain offset | 0 | 0 |
+---+---+---+---+ 24: | host length | host length | +---+---+---+---+ 28: | host offset | 0 | 0 | +---+---+---+---+ 32: | host string | + + . . . . + +---+ | | domain string | +---+ + . . . . +---+---+---+---+
The host and domain strings are ASCII (or possibly ISO-8859-1), are uppercased, and are not nul-terminated. 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).
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 byte zero[2]; short flags; // 0x8201 byte zero[2];
byte nonce[8]; // nonce
byte zero[8]; } type-2-message 0 1 2 3 +---+---+---+---+ 0: | 'N' | 'T' | 'L' | 'M' | +---+---+---+---+ 4: | 'S' | 'S' | 'P' | 0 | +---+---+---+---+ 8: | 2 | 0 | 0 | 0 | +---+---+---+---+ 12: | 0 | 0 | 0 | 0 | +---+---+---+---+ 16: | message len | 0 | 0 | +---+---+---+---+ 20: | 0x01 | 0x82 | 0 | 0 | +---+---+---+---+ 24: | | + server nonce | 28: | | +---+---+---+---+ 32: | 0 | 0 | 0 | 0 | +---+---+---+---+ 36: | 0 | 0 | 0 | 0 | +---+---+---+---+
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
byte zero[2];
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
byte zero[2];
short dom_len; // domain string length
short dom_len; // domain string length
short dom_off; // domain string offset (always 0x40)
byte zero[2];
short user_len; // username string length
short user_len; // username string length
short user_off; // username string offset
byte zero[2];
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
byte zero[2];
short flags; // 0x8201
byte zero[2];
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 0 1 2 3 +---+---+---+---+ 0: | 'N' | 'T' | 'L' | 'M' | +---+---+---+---+ 4: | 'S' | 'S' | 'P' | 0 | +---+---+---+---+ 8: | 3 | 0 | 0 | 0 | +---+---+---+---+ 12: | LM-resp len | LM-Resp len | +---+---+---+---+ 16: | LM-resp off | 0 | 0 |
+---+---+---+---+ 20: | NT-resp len | NT-Resp len | +---+---+---+---+ 24: | NT-resp off | 0 | 0 |
+---+---+---+---+ 28: | domain length | domain length | +---+---+---+---+ 32: | domain offset | 0 | 0 |
+---+---+---+---+ 36: | user length | user length | +---+---+---+---+ 40: | user offset | 0 | 0 |
+---+---+---+---+ 44: | host length | host length | +---+---+---+---+ 48: | host offset | 0 | 0 |
+---+---+---+---+
52: | 0 | 0 | 0 | 0 | +---+---+---+---+ 56: | message len | 0 | 0 | +---+---+---+---+ 60: | 0x01 | 0x82 | 0 | 0 | +---+---+---+---+ 64: | 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.
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.
The Web Security Authority.TM
Contact Blue Coat Systems 1.866.30.BCOAT
408.220.2200 Direct 408.220.2250 Fax www.bluecoat.com
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 Web-based threats by policing Port 80 – the primary hole in the enterprise security infrastructure. Headquartered in Sunnyvale, California, Blue Coat Systems can be reached at 408.220.2200 or at http://www.bluecoat.com.
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 respec-tive owners. Version 1.0