Lesson 3:Other SSL Applications

---

The vast majority of SSL certificates are installed on Web servers. However, Windows networks can use SSL certificates to protect several other protocols: LDAP, SMTP, POP3, NNTP, and SQL. This section will describe how to use SSL certificates to encrypt these communications protocols.

After this lesson, you will be able to

• Use SSL certificates to encrypt LDAP and global catalog queries.

• Use SSL certificates to encrypt database queries.

• Use SSL certificates to protect messaging communications.

Estimated lesson time: 45 minutes

Enabling SSL on Active Directory Domain Controllers

Applications use LDAP to query Active Directory domain controllers for information contained in the directory, such as the IP addresses of registered services or the contact information for users. LDAP queries can reveal a tremendous amount of confidential information, including user names, personal details about users, and locations of services on the network. As shown in Figure 11.11, a protocol analyzer can be used to capture and read LDAP traffic when an SSL certificate is not used.

Figure 11.11: Network Monitor displaying the results of an unencrypted LDAP query

Fortunately, you can install a computer certificate on a domain controller to enable SSL/TLS communications to encrypt LDAP queries and responses, in addition to global catalog traffic, by using LDAP over SSL (LDAPS). If you configure a domain controller as an enterprise CA, this happens automatically. In fact, after configuring a single enterprise CA, all domain controllers in the forest will automatically enroll for and install the appropriate certificate.

You can also use a certificate from a non-Microsoft CA. As long as the Enhanced Key Usage extension includes the Server Authentication object identifier, Active Directory will accept LDAPS queries. As with other types of certificates-based encryption, the client and server must both trust the root CA that issued the certificate. Additionally, the common name of the domain controller must appear in either the Subject or Subject Alternative Name field of the certificate, as shown in Figure 11.12.

Figure 11.12: The subject field of a certificate containing the domain controller’s common name

Normal unencrypted LDAP traffic uses TCP port 389. When SSL is used to encrypt LDAP queries and responses, it uses TCP port 636. When SSL is used to encrypt global catalog queries, clients will connect to TCP port 3269 instead of the standard global catalog port of 3268.

Unlike IPSec, LDAPS is not transparent to the application. Additionally, LDAPS does not provide clients and servers the opportunity to negotiate a level of encryption. Even after SSL is enabled, clients can send queries to TCP port 389, and 3268 will be allowed to send and receive unencrypted communications. You might have to configure applications that query Active Directory specifically to use SSL. The exercise at the end of this lesson demonstrates this phenomenon.

Enabling SSL on Computers Running SQL Server

SQL Server queries and results often contain confidential data. For example, an accounting front-end application might send financial information to a computer running SQL Server. An e-commerce Web server will send private end-user account information to a computer running SQL Server. By default, these communications are not encrypted and are vulnerable to eavesdropping. However, they can be encrypted by using an SSL certificate.

SQL Server SSL encryption can be enabled on either the SQL Server–based computer itself or on individual SQL Server–based clients. If you want to encrypt all communications to a particular server running SQL Server, and that server will not have any clients that do not support SSL encryption, you should require encryption on the computer running SQL Server. If some clients can connect to a SQL Server–based computer by using SSL encryption, but other clients must use an unencrypted connection, enable encryption on a client-by-client basis.

To enable encryption on a server running SQL Server 2000 for all clients connecting to that server, first install a server authentication certificate and store it in the local machine authority on the server, and then configure all clients to trust that certificate’s root CA. The client computer does not require a computer certificate itself, but it must trust the CA that issued the server certificate. If the computer is a member of an Active Directory domain and the certificate was issued by the domain’s enterprise CA, this trust will be automatically configured.

Note 

The SetCert tool, included with the SQL Server Resource Kit, permits you to control the certificate used for SQL Server. The tool is only available by purchasing the SQL Server Resource Kit or with a TechNet subscription.

Configuring clients to trust the root CA

If the clients do not automatically trust the root CA, you should manually configure the trust on each of the clients that will use encryption by following these steps:

1. Log on as an administrator to the computer running SQL Server.

2. Open the Internet Properties dialog box on the client computer, either by clicking Internet Options in Control Panel or by starting Internet Explorer, clicking Tools, and then clicking Internet Options.

3. Click the Content tab.

4. Click the Certificates button.

5. Click the Trusted Root Certification Authorities tab.

6. Click the certification authority that issued the certificate of the computer running SQL Server, and then click Export.

   The Certificate Export Wizard appears.

7. Click Next.

8. On the Export File Format page, click Cryptographic Message Syntax Standard - PKCS #7 Certificates (.P7B).

9. Select the Include All The Certificates In The Certification Path If Possible check box. Click Next.

10. On the File To Export page, type the name of a file in which to store the exported certificate, and then click Next.

11. On the final page, click Finish, and then click Close.

At this point, you have exported the SQL Server certificate. Now you need to transfer the exported certificates to each of the clients and then import the certificate into each client’s trusted root CAs by following this procedure:

1. Log on as an administrator on the client computer running SQL Server.

2. Open the Internet Properties dialog box on the client computer, either by clicking Internet Options in Control Panel or by launching Internet Explorer, clicking Tools, and then clicking Internet Options.

3. Click the Content tab.

4. Click the Certificates button.

5. Click the Trusted Root Certification Authorities tab.

6. Click the Import button.

   The Certificate Import Wizard appears.

7. Click Next.

8. On the File To Import page, select the certificate that you exported from the computer running SQL Server. Click Next.

9. Click Automatically Select The Certificate Store Based On The Type Of Certificate.

10. Click Next, and then click Finish.

11. When prompted to verify the addition to the root store, click Yes, and then click OK. Finally, click Close.

Requiring encryption at the SQL Server computer

Although encryption is enabled when SQL Server initializes and an appropriate SSL certificate is found, you can choose to require encryption to eliminate the possibility of clients connecting to the computer running SQL Server by using an unencrypted session. To require encryption on the computer running SQL Server, follow these steps:

1. Click Start, click All Programs, click Microsoft SQL Server, and then click Enterprise Manager.

2. Expand Microsoft SQL Servers and locate the computer running SQL Server for which you want to enable SSL.

3. Right-click the server’s node, and then click Properties.

4. Click the General tab, and then click Network Configuration.

5. Select the Force Protocol Encryption check box.

6. Click OK. When notified that the SQL Server service must be restarted, click OK. Click OK again to return to the SQL Server Enterprise Manager.

7. Right-click the server’s node, and then click Stop. When prompted, click Yes.

8. Right-click the server’s node, and then click Start.

Enabling encryption for individual clients

To enable encryption on a computer running SQL Server 2000 for only specific clients, first verify that the client has Microsoft Data Access Components (MDAC) version 2.6 or later installed. You can download the latest version of MDAC from http://www.microsoft.com/. After the computer running SQL Server has a certificate that is trusted by the client, you must configure encryption for either individual database applications or for all database connections initiated by the client.

If you choose to enable encryption individually for each application, the specific steps you follow will vary depending on the client application that accesses the computer running SQL Server. If the application uses an Open Database Connectivity (ODBC) connection string, add a semicolon and the phrase Encrypt=Yes to the end of the string. For example, the following is an ODBC connection string that will attempt to use SSL encryption when connecting to a computer running SQL Server:

Driver=SQLServer;Server=ServerName;UID=UserId; PWD=Password;Network=DBNETLIB.DLL;Encrypt=YES

If the application uses an OLE DB connection string, add a semicolon and the phrase Use Encryption for Data=True to the end of the string. For example, the following is an OLE DB connection string that will attempt to use SSL encryption when connecting to a computer running SQL Server:

Provider=SQLOLEDB.1;Integrated Security=SSPI ;Persist Security Info=False;Initial Catalog=dbName;Data  Source=ServerName;Use Encryption for Data=True 

You can configure encryption for all database connections initiated from the client by using the SQL Server Client Network utility if the SQL Server Client Tools are installed. However, this requires encryption for all SQL connections initiated by the client, and it does not allow the client to connect to SQL Server 7.0 or earlier databases. Therefore, you should enable encryption on a per-application basis by editing the connection string whenever possible.

Note 

To install the SQL Server Client tools, launch setup.bat from the root of the SQL Server 2000 CD-ROM, and follow the prompts.

To enable encryption by using the SQL Server Client Network utility, perform these steps:

1. Click Start, click All Programs, click Microsoft SQL Server, and then click Client Network Utility.

2. Click the General tab, and then select the Force Protocol Encryption check box.

3. Click OK.

Unfortunately, there is no easy way to verify that a particular database connection is encrypted. The best way to verify encryption is to use Network Monitor to capture and analyze the network traffic.

Enabling SSL on Mail Servers

Although there is currently no widely supported standard for encrypting communications between mail servers on the Internet, it is possible to encrypt messages transmitted from a client to a server, or between mail servers within an organization, by using SSL and TLS.

See Also 

Microsoft Exchange uses both SSL and TLS, for different purposes. For instructions on requiring TLS encryption for a virtual server in Exchange, refer to Chapter 4.

Differences Between SSL and TLS

SSL and TLS are often referred to as SSL/TLS. Though the two protocols are similar, they are indeed different and cannot interoperate. One important difference is that TLS 1.0 applies a Keyed-Hashing for Message Authentication Code (HMAC) algorithm, whereas SSL 3.0 applies the Message Authentication Code (MAC) algorithm. HMAC produces an integrity check value as MAC does, but it uses a hash function construction that makes the hash much harder to break.

SMTP and POP3 services are built into Windows Server 2003 and can be installed by adding the Mail Server (POP3, SMTP) server role. However, only the SMTP service can be configured with an SSL certificate. To configure an SSL certificate to allow SMTP encryption, follow these steps:

1. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

2. In the left pane, expand the computer node. Right-click Default SMTP Virtual Server, and then click Properties.

3. Click the Access tab, and then click the Certificate button.

   The Web Server Certificate Wizard appears. This enables you to configure an SSL certificate exactly as you would for a Web site, as described in Lesson 2.

Clients downloading messages by using POP3, IMAP4, or NNTP from a server running Exchange can use SSL to encrypt the communications if the server running Exchange is configured with a certificate. To configure a certificate for a server running Exchange Server 2003, begin by opening the Web Server Certificate Wizard by following these steps (the sequence of steps will be slightly different for Exchange Server 2000):

1. Click Start, click All Programs, click Microsoft Exchange, and then click System Manager.

2. In the left pane, locate the Servers node. Then expand Servers, expand the computer node you are configuring, expand Protocols, and expand SMTP.

3. Right-click the SMTP, POP3, IMAP4, or NNTP virtual server, and then click Properties.

4. Click the Access tab, and then click the Certificate button.

   The Web Server Certificate Wizard appears. Notice that it is called the Web Server Certificate Wizard because SMTP, POP3, IMAP4, and NNTP are components of IIS, not Exchange. However, the certificate you assign or create will be used for messaging.

After a certificate has been installed on the virtual server, encryption is automatically enabled for clients that request it. However, by default, the server running Exchange will still accept unencrypted communications. You can require that all clients use encryption by performing the following steps:

1. Click Start, click All Programs, click Microsoft Exchange, and then click System Manager.

2. In the left pane, locate the Servers node. Expand Servers, expand the computer node you are configuring, expand Protocols, and then expand SMTP.

3. Right-click the SMTP, POP3, or IMAP4 virtual server, and then click Properties.

4. Click the Access tab, and then click the Communication button.

5. Select the Require Secure Channel check box, as shown in Figure 11.13. Optionally, select the Require 128-Bit Encryption check box.

   
   Figure 11.13: Requiring messaging encryption

6. Click OK twice.

   Security Alert 

   If your organization allows users to retrieve e-mail by using a Web server interface, such as with Outlook Web Access (OWA), configure the Web server with an SSL certificate to encrypt the communications and authenticate the server.

Enabling SSL on Microsoft Outlook

After a server running Exchange, or another messaging server, has had a certificate installed and has been configured to enable encrypted communications, the messaging client must be configured to use encryption. Unlike IPSec, messaging encryption will not automatically negotiate authentication and encryption protocols.

Although every messaging client is different, the following procedure enables SSL encryption for the otherwise unsecured POP3, IMAP4, or SMTP protocols for an existing e-mail account on an Outlook 2003 client:

1. Open Control Panel, and then double-click Mail.

2. Click the E-Mail Accounts button.

3. The E-Mail Accounts Wizard appears.

4. Click View Or Change Existing E-Mail Accounts, and then click Next.

5. Click the account for which you want to enable encryption, and then click Change.

6. On the Internet E-Mail Settings page, click the More Settings button.

7. Click the Advanced tab.

8. Select the This Server Requires An Encrypted Connection (SSL) check box for the protocols you want to enable encryption for. Click OK.

9. Click Next, and then click Finish.

Practice: Protecting Active Directory Communications

In this practice, you will use SSL certificates to encrypt LDAP queries.

Exercise 1: Analyze unencrypted LDAP queries

In this exercise, you will generate and analyze unencrypted LDAP queries by using the Address Book accessory.

1. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

2. Click Start, click Control Panel, and then click Add Or Remove Programs.

3. Click Add/Remove Windows Components.

4. Click Management And Monitoring Tools, and then click Details. Select the Network Monitor Tools check box, and then click OK.

5. Click Next, and then respond to the prompts provided by the wizard. When installation has completed, click Finish.

   Network Monitor has now been installed and can be used to monitor traffic on Computer1.

6. Click Start, click Administrative Tools, and then click Network Monitor.

7. If prompted to select a network connection, expand Local Computer, click Local Area Connection, and then click OK.

   If you have other computers on your subnet, or if other computers are communicating with Computer1, you might want to create a capture filter to restrict captured traffic to the packets exchanged with Computer2.

8. Click the Capture menu, and then click Start.

At this point in the exercise, Network Monitor is running on Computer1. In the next process, you will use the Address Book accessory to generate unencrypted LDAP queries. You will then examine them in Network Monitor.

1. Log on to the cohowinery.com domain on Computer2 using the Administrator account.

2. Click Start, click All Programs, click Accessories, and then click Address Book.

3. Click the Find People button.

4. Click the Look In list, and then click Active Directory.

5. In the Name box, type the letter a, as shown in Figure 11.14. Click Find Now.

   
   Figure 11.14: Creating an Address Book query

6. Address Book will return three results: Account Operators, Administrator, and Administrators.

7. Return to Computer1. On the Capture menu, click Stop And View.

8. Click the first frame with a Src MAC Addr of LOCAL and a Description of ProtocolOp: SearchResponse (4). In the middle pane, expand LDAP, and then expand each LDAP: ProtocolOp = SearchResponse node.

   Notice that Network Monitor’s analysis of the frame shows three results with the following object names:

   • CN=Administrators,CN=Builtin,DC=cohowinery,DC=com

   • CN=Account Operators,CN=Builtin,DC=cohowinery,DC=com

   • CN=Administrator,CN=Users,DC=cohowinery,DC=com

Network Monitor would only be able to analyze the frame and determine the results of the query if the LDAP queries were transmitted without encryption. As you can see, configuring the Active Directory domain controller with a certificate is not sufficient to force encrypted communications; the client application must also be configured. Leave Network Monitor open, because you will use it in the next exercise.

Exercise 2: Encrypt LDAP queries

In this exercise, you will configure an LDAP client—the Address Book accessory—to submit encrypted LDAP queries. You will then use Network Monitor to examine the encrypted traffic.

1. On Computer1, in Network Monitor, click the File menu, and then click Close.

2. On the Capture menu, click Start. When prompted, click No.

3. On Computer2, in the Find People dialog box, click Close.

4. On the Tools menu, click Accounts.

5. Click Active Directory, and then click Properties.

6. In the Active Directory Properties dialog box, click the Advanced tab.

7. Select the This Server Requires A Secure Connection (SSL) check box.

8. In the Search Base box, type DC=cohowinery,DC=com, as shown in Figure 11.15.

   
   Figure 11.15: Configuring Address Book for encryption

9. Click OK, and then click Close.

10. Click the Find People button.

11. In the Look In list, click Active Directory.

12. In the Name box, type the letter a. Click Find Now.

    Address Book will return three results: Account Operators, Administrator, and Administrators.

13. Return to Computer1. On the Capture menu, click Stop And View.

14. Examine the captured frames.

    The majority of the frames will have the protocol listed as TCP. This indicates that Network Monitor was not able to perform an Application layer analysis on the frame. These frames have a TCP port of 636, which Network Monitor describes as LDAP Protocol Over TLS/SSL. However, as shown in Figure 11.16, the contents of the packets do not reveal the LDAP query or the response.

    
    Figure 11.16: Network Monitor attempting to analyze SSL-encrypted LDAP queries

    You will also notice LDAP queries that were transmitted unencrypted. These queries were used by Computer2 to locate a domain controller. They do not contain the LDAP query created by Address Book to find user names that start with the letter A.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

1. When a certificate is installed on a domain controller, which of the following types of communications can be protected with SSL? (Choose all that apply.)

   1. Kerberos authentication

   2. Global catalog traffic

   3. DNS queries

   4. LDAP queries

   5. File replication

2. After installing an SSL certificate on a computer running SQL Server, how can you protect database communications by using SSL? (Choose all that apply.)

   1. Select the Force Protocol Encryption check box on the computer running SQL Server.

   2. Add Encrypt=YES to the ODBC connection string.

   3. Add Use Encryption for Data=True to the ODBC connection string.

   4. Add Encrypt=YES to the OLE DB connection string.

   5. Add Use Encryption for Data=True to the OLE DB connection string.

Lesson Summary

• Allowing LDAP queries to be encrypted requires only enrolling the domain controllers with a computer certificate. No manual configuration is required.

• SSL certificates can be used to encrypt SQL queries. However, encryption must be either required on the computer running SQL Server or enabled in the SQL client application configuration.

• The best way to encrypt messaging communications is to install a computer certificate on the mail server and then configure the mail clients to use SSL encryption.

---