Microsoft® BizTalk® Server 2004 relies heavily on the security provided by certificates. By using certificates for encryption and digital signatures, BizTalk Server can send and receive data that can be trusted. The BizTalk Server 2004 Technical Guide for Certificate Management provides detailed information about how to configure your BizTalk Server environment to use certificates for encryption, signing, and party resolution. It also provides a sample application to help you automate the installation of certificates in the certificate stores that BizTalk Server uses when processing messages.

By using certificates, companies can conduct business electronically with authentic and private message exchanges. Authenticity involves validating the digital signatures or identities of those who send messages, while privacy involves encrypting confidential information to prevent tampering and unintended disclosure. Companies can use separate certificates for digital signatures and encryption.

This document assumes that you are familiar with public key infrastructure (PKI), certificates, and certification authorities. For information about cryptography and certificates on MSDN®, the Microsoft Developer Network, see Cryptography.

You can configure your Microsoft® BizTalk® Server 2004 environment to use certificates for sending and receiving signed and encrypted messages. By using certificates for encryption and digital signatures, BizTalk Server can:

• Send and receive data that can be trusted.
  
• Make sure that the data it processes is secure.
  
• Make sure that authorized parties receive its messages.
  
• Make sure that it receives messages from authorized parties.
  

This section provides information about how to configure BizTalk Server 2004 pipelines, receive locations, ports, and the BizTalk Server environment to receive and send encrypted and signed messages, and how to use the signing certificates for party resolution.

Storing Certificates for BizTalk Server 2004

Windows Certificate Stores That BizTalk Server Uses

Certificates That You Need in Each Store

The following table describes the certificates that you must install in each Windows certificate store.

Table 1 Certificates for each Windows certificate store

Certificate purpose	Certificate type	Certificate store
Signing	Own private key	Personal store for each service account of a host instance that has a send pipeline with a MIME/SMIME Encoder pipeline component configured to sign messages (Add Signing Cert To Message property set to True).
Verifying signature	Partner's public key	Other People store on each computer that has a host instance that has a receive pipeline with a MIME/SMIME Decoder pipeline component.
Decrypting	Own private key	Personal store for each service account of a host instance that has a receive pipeline with a MIME/SMIME Decoder pipeline component.
Encrypting	Partner's public key	Other People store on each computer that has a host instance that has a send pipeline with a MIME/SMIME Encoder pipeline component configured to encrypt messages (Enable encryption property set to True).
Party resolution	Partner's public key	Other People store on the administration computer from which you are configuring party resolution.

The following figure shows what certificates you will need in each certificate store on a BizTalk Server dedicated to receiving messages.

Figure 3 Certificates required in a BizTalk Server dedicated to receiving messages

The following figure shows what certificates you will need in each certificate store on a BizTalk Server dedicated to sending messages.

Figure 4 Certificates required in a BizTalk Server dedicated to sending messages

For more information about certificates and about managing certificates in the Certificate snap-in, search for "Certificates" in Windows XP, Windows Server 2003, or Windows 2000 Server Help.

BizTalk Server 2004 supports public key encryption of outbound messages and decryption of inbound messages based on S/MIME. BizTalk Server uses S/MIME version 3 for encryption of outbound messages, and S/MIME versions 2 and 3 for decryption of inbound messages.

Receiving Encrypted Messages

Sending Encrypted Messages

The following figure shows the message flow when BizTalk Server sends an encrypted message.

Figure 6 Message Flow when sending an encrypted message

The message flow when BizTalk Server sends an encrypted message to a partner is as follows:

1. The appropriate BizTalk Server send handler sends a message to the partner.
   
2. During the send pipeline execution, the MIME/SMIME Encoder pipeline component encrypts the message by using the partner's public key.
   
3. The partner receives the message from BizTalk Server. The partner uses its private key to decrypt the message.
   

This section describes the steps that you have to follow to configure a BizTalk Server environment to receive and send encrypted messages.

At a high level, the steps are:

• Install the certificate keys in the certificate stores.
  
• Configure the pipelines to receive and send encrypted messages.
  

Installing the Certificate Keys in the Certificate Stores

Configuring BizTalk Server to Receive Encrypted Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to receive encrypted messages.

Note
The MIME/SMIME Decoder pipeline component performs both decryption and digital signature validation (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to receive encrypted and signed messages, you can use the same receive pipeline. In other words, you do not have to create separate pipelines for decryption and digital signature validation.

Note
You can use one certificate for both signing and decryption operations, or you can use one certificate for each function.

To configure BizTalk Server to receive encrypted messages

1. Create a new receive pipeline:

   1. In Solution Explorer, select the project in which you want to create the pipeline.
      
   2. On the File menu, click Add New Item.
      
   3. In the Add New Item dialog box, select the Receive Pipeline template by clicking it once.
      
   4. In the Name field, type a name for the pipeline.
      
   5. Click Open.
      The new pipeline appears in Solution Explorer.
      

2. Drag the MIME/SMIME Decoder pipeline component into the Decode stage of a receive pipeline.

   

3. Configure the MIME/SMIME Decoder pipeline component properties in the Properties window. For more information about the MIME/SMIME decoder, see "Configuring the MIME/SMIME Decoder Pipeline Component" in BizTalk Server 2004 Help.

4. Build and deploy the receive pipeline.

5. In BizTalk Explorer, create a new receive port.

6. Create a new receive location. In the Receive Pipeline drop-down list, select the pipeline you created in step 1. In the Receive Handler drop-down list, select the BizTalk Host where the receive location will run.

7. Configure the host running the receive pipeline with the decryption certificate:

   1. Open BizTalk Server Administration.
      
   2. Expand the Microsoft BizTalk Server 2004 (local) node, and then double-click Hosts.
      
   3. Right-click the host where the receive location you created in step 6 will run, and select Properties.
      
   4. In the <Host Name> Properties dialog box, on the Certificate tab, type the thumbprint value for the decryption certificate that BizTalk Server will use to decrypt messages it receives through the receive location.
      

Configuring BizTalk Server to Send Encrypted Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to send encrypted messages.

Note
The MIME/SMIME Encoder pipeline component performs both encryption and digital signing (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to send encrypted and signed messages, you can use the same send pipeline. In other words, you do not have to create separate pipelines for encryption and digital signing.

To configure BizTalk Server to send encrypted messages

1. Create a new send pipeline:

   1. In Solution Explorer, select the project in which you want to create the pipeline.
      
   2. On the File menu, click Add New Item.
      
   3. In the Add New Item dialog box, select the Send Pipeline template by clicking it once.
      
   4. In the Name field, type a name for the pipeline.
      
   5. Click Open.
      The new pipeline appears in Solution Explorer.
      

2. Drag the MIME/SMIME Encoder pipeline component into the Encode stage of a receive pipeline.

   

3. In the Properties window, configure the MIME/SMIME Encoder pipeline component Enable encryption property to True. For more information about the MIME/SMIME encoder, see "Configuring the MIME/SMIME Encoder Pipeline Component" in BizTalk Server 2004 Help.

4. Build and deploy the send pipeline.

5. In BizTalk Explorer, create a new send port.

6. In General Properties, in the Send Pipeline drop-down list, select the pipeline you created in step 1.

7. In the Certificate Name drop-down list, select the public key encryption certificate that BizTalk Server will use to encrypt messages sent to the partner.

BizTalk Server supports using digital signature certificates both to sign outbound messages and to verify the signature of inbound messages. BizTalk Server uses S/MIME versions 2 and 3 to sign outbound messages and to validate the signature of inbound messages. The signing certificate supported by BizTalk Server is x.509 version 3.

Using Digital Signature Certificates with Inbound Messages

Using Digital Signature Certificates with Outbound Messages

The following figure shows the message flow when BizTalk Server sends a digitally signed message.

Figure 8 Message Flow when sending a digitally signed message

The message flow when BizTalk Server sends a digitally signed message to a partner is as follows:

1. The appropriate BizTalk Server send handler sends a message to the partner.
   
2. During the execution of the send pipeline, the MIME/SMIME Encoder pipeline component signs the message by using the BizTalk Server private key.
   
3. The partner receives the message from BizTalk Server. The partner uses the BizTalk Server public key to verify the digital signature.
   

This section describes the steps that you have to follow to configure a BizTalk Server environment to receive and send signed messages.

At a high level, the steps are:

• Install the certificate keys in the certificate stores.
  
• Configure the pipelines to receive and send signed messages.
  
• Specify the signing certificate in the BizTalk Administration console.
  

Installing the Certificate Keys in the Certificate Stores

Configuring BizTalk Server to Receive Signed Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to receive signed messages.

Note
The MIME/SMIME Decoder pipeline component performs both decryption and digital signature validation (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to receive encrypted and signed messages, you can use the same receive pipeline. In other words, you do not have to create separate pipelines for decryption and digital signature validation.

To configure BizTalk Server to receive signed messages

1. Create a new receive pipeline:

   1. In Solution Explorer, select the project in which you want to create the pipeline.
      
   2. On the File menu, click Add New Item.
      
   3. In the Add New Item dialog box, select the Receive Pipeline template by clicking it once.
      
   4. In the Name field, type a name for the pipeline.
      
   5. Click Open.
      The new pipeline appears in Solution Explorer.
      

2. Drag the MIME/SMIME Decoder pipeline component into the Decode stage of a receive pipeline.

   

3. Configure the MIME/SMIME Decoder pipeline decoder properties in the Properties window. For more information about the MIME/SMIME decoder, see "Configuring the MIME/SMIME Decoder Pipeline Component" in BizTalk Server 2004 Help.

4. Build and deploy the receive pipeline.

5. In BizTalk Explorer, create a new receive port.

6. Create a new receive location. In the Receive Pipeline drop-down list, select the pipeline you created in step 1.

Configuring BizTalk Server to Send Signed Messages

The following procedure lists the steps that you have to follow to configure BizTalk Server to send signed messages.

Note
The MIME/SMIME Encoder pipeline component performs both encryption and digital signing (when configured to perform both functions). Therefore, if you are configuring BizTalk Server to send encrypted and signed messages, you can use the same send pipeline. In other words, you do not have to create separate pipelines for encryption and digital signing.

Note
You can use one certificate for both signing and decryption operations, or you can use one certificate for each function.

To configure BizTalk Server to send signed messages

1. Create a new send pipeline:

   1. In Solution Explorer, select the project in which you want to create the pipeline.
      
   2. On the File menu, click Add New Item.
      
   3. In the Add New Item dialog box, select the Send Pipeline template by clicking it once.
      
   4. In the Name field, type a name for the pipeline.
      
   5. Click Open.
      The new pipeline appears in Solution Explorer.
      

2. Drag the MIME/SMIME Encoder pipeline component into the Encode stage of a receive pipeline. For more information about the MIME/SMIME encoder, see "Configuring the MIME/SMIME Encoder Pipeline Component" in BizTalk Server 2004 Help.

   

3. In the Properties window, configure the MIME/SMIME Encoder pipeline component Signature type property to ClearSign or BlobSign properties.

   Important
   If you are also using encryption, you can only select BlobSign.

4. Build and deploy the send pipeline.

5. In BizTalk Explorer, create a new send port.

6. Expand the Send node, and then the General node. In the Send Pipeline drop-down list, select the pipeline you created in step 1.

Specifying the Signing Certificate in the BizTalk Administration Console

A party is an entity outside BizTalk Server that interacts with an orchestration. When you use BizTalk Explorer (either the user interface or the object model) to configure a party, you can choose to resolve the party by using its digital signature. In other words, when BizTalk Server receives a message, it uses the public key certificate to determine who sent the message, and to resolve the sender to a known party in the BizTalk Server environment.

Using Digital Signatures for Party Resolution

The following figure shows the message flow when BizTalk Server receives a digitally signed message and uses the digital signature to resolve the partner identity to a party in the BizTalk Server environment. In this scenario, the partner who sends the message is resolved to Party A.

Figure 9 BizTalk Server message flow

The message flow when BizTalk Server uses the signing certificate to resolve the party is as follows:

1. A partner sends a message to BizTalk Server. The partner signs the message with its private key.
   
2. The appropriate BizTalk Server receive handler receives the message.
   
3. During the execution of the receive pipeline, the MIME/SMIME Decoder pipeline component verifies the digital signature by using the partner's public key.
   
4. During the execution of the receive pipeline party resolution component, the Partner's public key certificate is used to identify the party in the BizTalk Server system.
   
5. Additional processing occurs.
   

This section describes the steps that you have to follow to configure a BizTalk Server environment to use certificates for party resolution.

At a high level, the steps are:

• Install the certificate keys in the certificate stores. Because you are using the same certificate that you use for verifying the partner's signature, follow the steps in the topic Configuring BizTalk Server 2004 to Use Signing Certificates.
  
• Configure the Party Resolution component in the receive pipeline.
  

Using Certificates for Party Resolution

The following procedure lists the steps that you have to follow to configure the Party Resolution component in a BizTalk Server receive pipeline.

Note
You can also use the default XMLReceive pipeline instead of creating a new receive pipeline. The XMLReceive pipeline runs the Party Resolution component, which resolves the certificate subject to the party ID. Note that the XMLReceive pipeline has an empty Decode stage, and therefore you cannot use it for receiving encrypted messages or verifying digital signatures.

To configure BizTalk Server to use certificates for party resolution

1. Create a new receive pipeline:

   1. In Solution Explorer, select the project in which you want to create the pipeline.
      
   2. On the File menu, click Add New Item.
      
   3. In the Add New Item dialog box, select the Receive Pipeline template by clicking it once.
      
   4. In the Name field, type a name for the pipeline.
      
   5. Click Open.
      The new pipeline appears in Solution Explorer.
      

2. Configure the Decode stage as indicated in the procedure "To configure BizTalk Server to receive signed messages" in the topic Configuring BizTalk Server 2004 to Use Signing Certificates.

3. Drag the Party Resolution pipeline component into the ResolveParty stage of a receive pipeline. For more information about the Party Resolution pipeline component, see "Configuring the Party Resolution Pipeline Component" in BizTalk Server 2004 Help.

4. In the Properties window, configure the Party Resolution pipeline property Resolve party by certificate to True.

5. Build and deploy the receive pipeline.

6. In BizTalk Explorer, create a new party.

7. In the Certificates properties, from the Certificate Name drop-down list, select the public key signing certificate to use to identify this party.

This section provides some recommendations and best practices for managing certificates in your Microsoft® BizTalk® Server 2004 environment.

Some best practices to consider are:

• Do a threat model analysis of your environment to determine whether using signing or encryption certificates can help you mitigate some security threats.
  
• Create a plan for receiving and sending public key certificates to and from partners. If you are not using signing certificates for party resolution, the public certificate can be attached to the message, in which case you do not have to have a copy of the certificate in your system beforehand.
  
• Download the certificate revocation list (CRL) from your certification authority (CA) at set intervals. We recommend once a week.
  
• As part of your service level agreement with your partner, establish guidelines for submitting public keys, notifying you when their certificates are about to expire, and notifying you when they revoke a certificate.
  
• Make sure you verify the signing certificates against the certificate revocation list by configuring the Check Revocation List option in the Decode MIME/SMIME pipeline component to Yes.
  
• Determine what you want to do with messages that you receive when BizTalk Server 2004 cannot validate the digital signature. Setting the Requires MSMQ authentication flag on the receive location and AuthenticationRequired (Drop messages) on the receive port to True will help prevent denial of service attacks. Remember that the AuthenticationRequired flag on the receive port requires the Party Resolution pipeline component to be configured correctly, and that the parties are defined in BizTalk Explorer. For more information about configuring the Party Resolution pipeline component, see BizTalk Message Queuing Party Resolution in BizTalk Server 2004 Help.
  
• If you plan to receive MIME-encrypted messages from some partners and unencrypted messages from other partners, create separate receive locations in different hosts for encrypted and unencrypted messages. When you expect only MIME-encrypted messages, configure the Allow Non MIME Message option in the Decode MIME/SMIME pipeline component to No.
  
• Make certificate management part of your partner management practices. In other words, when you add or remove a party from the BizTalk Server environment, we recommend that you also add or remove the certificates associated with that partner.
  
• When you use the sample utility provided with this guide to automate the installation of certificates, configure your BizTalk Server environment, including host and host instances, before installing the certificates. This way you only have to run the sample application once. If you add new host instances, even for existing hosts, you have to rerun the sample application.
  
• Before removing a host instance from a BizTalk Server, remove the certificates in the personal store of the account under which the host instance is running.
  

Certificate management is an important process for companies that have many partners. Depending on their particular environments and business needs, companies approach and implement certificate management in a variety of ways. This section provides examples of how a company manages their certificates to meet their needs.

Company A is a hardware manufacturer. They use BizTalk Server 2004 primarily as a middleware process automation tool to control all document flow through a variety of custom components. They run over 100,000 transactions from more than 100 trading partners and over 250,000 transactions from their back end daily. Their trading partners include companies from whom they buy materials (suppliers), companies to whom they sell products (customers), companies with whom they contract, shipping companies, and internal groups such as human resources.

Certificates

This section provides a sample Microsoft® BizTalk® Server 2004 deployment that uses certificates to send and receive encrypted messages from a partner.

The sample BizTalk Server deployment described in this section is not a secure BizTalk Server deployment. For more information about how to secure your BizTalk Server deployment, see Planning a Secure Deployment in BizTalk Server 2004 Help.

The following sections provide detailed information about the sample architecture and how to configure it. One section documents a threat model analysis performed on the sample and how you can mitigate the identified threats.

This section describes the sample architecture on which we will configure BizTalk Server 2004 to send and receive encrypted messages. It shows the network architecture diagram and describes each server in the deployment.

The deployment for the sample application includes five computers. Four of these computers would typically be server-class computers in a production environment. The last computer would typically be a workstation-class computer in a production environment. The following figure shows the network diagram for the sample deployment.

Figure 10 Network diagram for the sample deployment

The sample depicts a Point of Sale (PoS) application in which a salesperson from Contoso requests inventory items for the store. The salesperson uses a custom application to submit the request for items. The application submits the request to BizTalk Server 2004, where the appropriate orchestration processes the order. To illustrate the use of certificates in this architecture, the orchestration sends the order to a pipeline where it is encrypted in one BizTalk Server, and then the second BizTalk Server decrypts the order before additional processing takes place. BizTalk Server uses the order information to update the SQL Server database that contains business data. BizTalk Server does a warehouse inventory check, and then submits an encrypted acknowledgment and inventory status back to the salesperson. The salesperson decrypts the message and verifies the signature.

For more information about the data flow in this sample deployment architecture, see "Data Flow Diagram" in Collect Background Information for the Sample Deployment.

Domain Controller

This computer runs Active Directory® to control the authorization of user, group, computer, and service accounts that access information across the network in the sample deployment. This computer also runs as a certification authority using Certificate Services. Computers in the sample deployment request certificates from the certification authority.

Note
For this sample deployment, the domain controller acts as the certification authority for the computers in the E-Business domain and for the client computer. Typically, a third party would act as the certification authority for your company and your partner.

SQL Server

BizTalk Server

Application Computer

This sample is made up of five computers - a primary domain controller and certification authority, a computer that is running Microsoft SQL Server 2000, two computers that are running Microsoft BizTalk Server 2004, and an application computer. Each computer plays a role in the sample, and you must configure each of them correctly.

This section contains procedures for configuring the five computers that are used in the sample certificate management deployment. To configure this sample deployment, you must have sufficient knowledge in the following areas:

• Microsoft Windows Server™ 2003
  
• Active Directory
  
• SQL Server
  
• BizTalk Server 2004
  

This section describes the hardware and software prerequisites for each of the five computers in the sample deployment for certificate management in BizTalk Server 2004. The sample was created and tested using Microsoft Windows Server 2003 Standard Edition as the operating system for each computer.

Domain Controller

SQL Server

BizTalk Server 2004

Application Client

This section provides guidelines for configuring the domain controller in the sample BizTalk Server 2004 deployment for certificate management. It includes guidelines for configuring Active Directory, creating domain accounts, and installing Certificate Services.

Follow these steps to configure Active Directory.

1. Click Start, point to All Programs, point to Administrative Tools, and then click Configure Your Server Wizard.

2. Install Domain Controller (Active Directory).

3. Create a domain in a new forest.

4. Select the option to install and configure Domain Name System (DNS) on the computer.

5. The full DNS name for the new domain is contoso.com.

6. The domain NetBIOS name is CONTOSO.

7. Accept the defaults for the Active Directory database.

8. Accept the default for the sysvol folder.

9. Choose a password for the restore mode.

10. Complete the domain controller installation and restart the computer.

After the computer restarts and Active Directory is running, create the global domain security groups that BizTalk Server 2004 will use for the sample application. Create the following new domain groups:

• SSO Administrators
  
• SSO Affiliate Administrators
  
• BizTalk Server Administrators
  
• BizTalk Decrypter Host Users
  
• BizTalk Server Application Host Users
  
• BizTalk SQL Adapter Host Users
  

Follow these steps to create these groups.

1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

2. In the Active Directory Users and Computers window, right-click <domainname>.com, point to New, and then click Group.

3. In the New Object - Group dialog box, type a name for the new group (for example, SSO Administrators), accept the default name for Pre-Windows 2000 groups, select Global for the Group Scope, select Security for the Group Type, and then click OK.

4. Repeat this procedure for each remaining domain group.

After you create the BizTalk domain groups, you must create users who are part of these groups. The following table shows the domain user names and the groups to which you add them.

Table 2 Domain user names and associated groups

Follow these steps to create these user accounts.

1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

2. In the Active Directory Users and Computers window, expand <domainname>.com, right-click Users, point to New, and then click User.

3. In the New Object - User dialog box, type a first name for the account, type the account name (for example, ssoadmin) for the User logon name, and then click Next.

4. In the Password box, type a password for the account, and then in the Confirm password box, type the password again.

5. Select User cannot change password, and then click Next.

6. Click Finish.

7. Repeat this procedure for each remaining user account.

After you create the appropriate domain user and group accounts in Active Directory, install Certificate Services so that the domain controller can issue certificates.

Follow these steps to install certificate services on the domain controller and configure it as a certification authority.

1. Log on to the computer as a domain administrator.

2. Click Start, point to Settings, and then click Control Panel.

3. Double-click Add or Remove Programs and then click Add/Remove Windows Components.

4. In the Windows Components Wizard, select the Certificate Services check box. A dialog box appears to inform you that the computer cannot be renamed and that the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Next.

5. On the Windows Components Wizard, CA Types page, select Stand-alone root CA, select the Use custom settings to generate the key pair and CA certificate check box, and then click Next.

6. On the Public and Private Key Pair page, leave the default settings, and then click Next.

7. On the CA Identifying Information page, in the Common name for this CA box, type CertMgmtCA, and then click Next.

8. On the Certificate Database Settings page, leave the default settings, and then click Next.

9. If Internet Information Services (IIS) is running, you will receive a request to stop the service before proceeding with the installation. Click OK.

10. If prompted, type the path of the Certificate Services installation files.

This section provides guidelines for installing BizTalk Server 2004 in the sample certificate management deployment. It includes guidelines for preparing for installation and for the installation process itself.

Configuring the two BizTalk Server computers requires several steps. This section describes the following steps:

• Preparing the computers for BizTalk Server 2004 installation
  
• Installing BizTalk Server 2004 on the computers
  
• Creating BizTalk Hosts
  
• Deleting unnecessary adapters
  
• Adding the BizTalk Message Queuing adapter
  

Before you install BizTalk Server 2004, you must configure the two computers to join the domain, and also configure Microsoft Distributed Transaction Coordinator (MS DTC). After you complete these preliminary steps, you are ready to configure the BizTalk Server 2004 computers.

Follow these steps to configure the BizTalk Server 2004 computers.

1. Name the first BizTalk Server 2004 computer BTS-SRV. The sample certificate management deployment program assumes that this receiving computer is named BTS-SRV. If it is not, you can change the default BizTalk Server in the sample certificate management deployment program described later in this document.

2. Add the computer to the CONTOSO domain.

3. Add the btsinstall domain user to the local administrators group.

4. Log off and then log on using the btsinstall domain user.

5. Modify MS DTC on the computer:

   1. Open Administrative Tools.
      
   2. Open Component Services.
      
   3. Right-click My Computer.
      
   4. Click Properties.
      
   5. Click the MSDTC tab.
      
   6. Click Security Configuration.
      
   7. Click Security Settings.
      
   8. Make sure that the Network Clients check box is selected.
      

6. Close the dialog box and restart the computer.

7. Repeat steps 1 through 6 for the second BizTalk Server 2004 computer. Name this sending computer BTS2-SRV.

Follow these steps to install and configure BizTalk Server 2004.

1. Log on as the BizTalk Server installation account (btsinstall).

2. Perform a custom installation of BizTalk Server 2004. On the Custom Installation page, remove the following from the standard installation:

   • Development
     
   • Human Workflow Services Runtime Component
     
   • Base EDI Adapter
     
   • Rules Engine
     
   • Human Workflow Service Administration Tools
     
   • Information Worker Applications/Portal
     

   On the second BizTalk Server computer, remove this additional item:

   • Administration and Monitoring
     

3. After you finish the BizTalk Server 2004 installation wizard, run the BizTalk Server Configuration Wizard to configure the BizTalk Server databases in SQL Server 2000.

4. On the Configuration options page, for the first BizTalk Server installation (BTS-SRV), create a BizTalk Server group, and then click Yes to have the Single Sign-On server hold the master secret key. Click No to creating a BizTalk Host or Isolated Host Application. Click Next.

   For the second BizTalk Server 2004 installation (BTS2-SRV), join the existing group from the first BizTalk Server installation and then click No for Single Sign-On so that the master secret key only exists on the first BizTalk Server installation.

5. On the second Configuration options page, click No to creating an Analysis database for tracking aggregation. Click No to using the Analysis Server for BAM. Click Next.

6. On the Windows accounts page, configure the following Windows accounts for the following BizTalk Server accounts, and then click Next:

   Windows account name	BizTalk Server account
   BizTalk Administrators Group	Contoso\BizTalk Server Administrators
   SSO Administrator(s)	Contoso\SSO Administrators
   SSO Affiliate Administrator(s)	Contoso\SSO Affiliate Administrators

7. On the Database configurations page, change the settings for each database so that they are created on the SQL Server that you set up earlier (SQL-Server). Click Next.

8. On the Windows Service Configurations page, assign the Enterprise Single Sign-On Service to the Contoso\ssoservice domain user. Click Next.

9. On the BizTalk Messaging page, click Next.

10. On the Summary page, review the configuration options, and then click Next.

11. Click Finish.

12. Repeat steps 1 through 11for the second BizTalk Server computer.

After configuring the BizTalk Server 2004 computers, create BizTalk Hosts for the sample application. Follow these steps to create the following hosts:

• BizTalkServerApplication (on BTS-SRV)
  
• BizTalkEncrypter (on BTS2-SRV)
  
• SQLAdapter (on BTS-SRV)
  

1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

2. Click Start, click All Programs, click Microsoft BizTalk Server 2004, and then click BizTalk Server Administration.

3. Expand Microsoft BizTalk Server 2004 (local), right-click Hosts, click New, and then click Host.

4. Create the BizTalkServerApplication host:

   1. Name: BizTalkServerApplication
      
   2. Windows Group: Contoso\BizTalk Server Application Host Users
      
   3. Host Type: In-Process
      
   4. Make sure that the Default Host in Group check box is selected.
      
   5. Make sure the Host tracking check box is selected.
      
   6. Click OK.
      
   7. Right-click the BizTalkServerApplication host and create a new instance of the host.
      
   8. Click BTS-SRV.
      
   9. Set the Contoso\btsproc1 account as the logon account for the host instance with the corresponding password.
      
   10. Click OK.
       
   11. If the host instance is not automatically started, in the Results pane, right-click the host instance, and then click Start.
       

5. Create the BizTalkDecrypter host by using the procedure in step 4 with the following information:

   1. Name: BizTalkDecrypter
      
   2. Windows Group: Contoso\BizTalk Decrypter Host Users
      
   3. Host Type: In-Process
      
   4. Click OK.
      
   5. Right-click the BizTalkDecrypter host and create a new instance of the host.
      
   6. Click BTS2-SRV.
      
   7. Set the Contoso\btsrcv1 account as the logon account for the host instance with the corresponding password.
      

6. Create the SQLAdapter host by using the procedure in step 4 with the following information:

   1. Name: SQLAdapter
      
   2. Windows Group: Contoso\BizTalk SQL Adapter Host Users
      
   3. Host Type: In-Process
      
   4. Click OK.
      
   5. Right-click the SQLAdapter host and create a new instance of the host.
      
   6. Click BTS-SRV.
      
   7. Set the Contoso\sqladapter account as the logon account for the host instance with the corresponding password.
      

While in the BizTalk Administration console, delete the adapters that the sample does not use. Follow these steps to delete the following adapters:

• EDI adapter (will appear if you did not remove Base EDI Adapter from the custom installation list)
  
• FTP adapter
  
• HTTP adapter
  
• SMTP adapter
  
• SOAP adapter
  

1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

2. Open the BizTalk Administration console.

3. Expand Adapters.

4. Right-click the specific adapter that you want to delete, and then click Delete.

5. In the confirmation dialog box, click Yes.

Follow these steps to add the BizTalk Message Queuing Adapter (also known as MSMQT).

1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

2. Open the BizTalk Administration console.

3. Right-click Adapters, click New, and then click Adapter.

4. Create a new adapter with the following information:

   • Name: MSMQT
     
   • Adapter: MSMQT
     
   • Comment: BizTalk Message Queuing Adapter
     

5. In the configuration dialog box, click OK.

6. Expand Hosts, and then click BizTalkServerApplication,

7. In the results pane, right-click BTS-SRV, and then click Stop.

8. In the results pane, right-click BTS-SRV, and then click Start.

Follow these steps to associate the File receive and send handlers and the SQL receive and send handlers with the correct hosts.

1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

2. Open the BizTalk Administration console.

3. Expand Microsoft BizTalk Server 2004 (local), expand Adapters, expand FILE, and then click Receive Handlers.

4. In the results pane, right-click the host, and then click Properties.

5. On the <Host name> Properties page, select BizTalkDecrypter from the Host name drop-down list, and then click OK.

6. Click Send Handlers.

7. In the results pane, right-click the host, and then click Properties.

8. On the <Host name> Properties page, select BizTalkDecrypter from the Host name drop-down list, and then click OK.

9. Expand SQL, and then click Receive Handlers.

10. In the results pane, right-click the host, and then click Properties.

11. On the <Host name> Properties page, select SQLAdapter from the Host name drop-down list, and then click OK.

12. Click Send Handlers.

13. In the results pane, right-click the host, and then click Properties.

14. On the <Host name> Properties page, select SQLAdapter from the Host name drop-down list, and then click OK.

Follow these steps on one of the BizTalk Server computers to install the files you need to configure the sample deployment.

1. Log on to the first BizTalk Server computer (BTS-SRV) as the BizTalk Server installation account (btsinstall).

2. Run the Certificate_Management.msi installation program on one of the BizTalk Server computers.

3. On the Welcome to the Certificate Management Technical Guide Setup Wizard page, click Next.

4. On the License Agreement page, read the agreement. If you agree to abide by the license agreement click the I Agree option, and then click Next.

5. Select the location where you want the sample files to be copied, and then click Next.

6. On the Confirm Installation page, click Next.

7. On the Installation Complete page, click Close to exit the installation program.

8. If you took the default settings for the location of the installation files, the files and directories for the sample deployment are in the C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide folder.

This section describes how to configure encryption certificates for the sample certificate management deployment. Before configuring the certificates for BizTalk Server 2004, make sure you configure the sample deployment as described in the Configuring the Sample Certificate Management Deployment topic.

This section includes the following steps:

1. Requesting a certificate. Request an encryption certificate for the client computer from Certificate Services running on the domain controller.
   
2. Exporting the private key. Export the private key from the Personal certificate store to a folder. You will need this private key later on if you use the certificate deployment utility. For more information about the certificate deployment utility, see Sample Certificate Deployment Utility.
   
3. Exporting the public key. Export the public key for the encryption certificate from the Personal certificate store to a folder where the partner can access it. When you request a certificate, it contains both the public and private keys. You have to open the Personal store to export the public key to a share where you can access it. You then have to import the public key to the Local Computer\Other People store of the other computer.
   
4. Importing the public key. Import the public key for encryption from the partner to the Other People certificate store.
   
5. Viewing the thumbprint. When you configure the sample deployment application, you have to enter the thumbprint for the client computer certificate and for the BizTalk Server computer.
   

On the client application computer (APP-SRV), you must do the following:

1. Request a certificate.
   
2. Export the public key to a location accessible by the BizTalk Server computers.
   

On the BizTalk Server computer BTS2-SRV, you must do the following:

1. Request a certificate.
   
2. Export the public key to a location where the client computer and the other BizTalk Server computer (BTS-SRV) can access it.
   
3. Import the public key for BizTalk Server to the Local Computer\Other People certificate store.
   

On the BizTalk Server computer BTS-SRV you must do the following:

1. Import the public key from the client computer to this BizTalk Server computer.
   
2. Import the public key from BTS2-SRV to this BizTalk Server computer.
   

Follow these steps on the client computer and on the second BizTalk Server computer (BTS2-SRV) to request an encryption certificate from the domain controller. The certification authority running on the domain controller issues the encryption certificate to the application client computer and to the BizTalk Server computer.

Note
Make sure that Certificate Services is configured to automatically issue certificates after the request (instead of pending certificate requests). Otherwise, an administrator must manually issue the certificate. You can modify this property through the Certification Authority administrative tool.

Note
This procedure assumes that you are running Windows Server 2003. If you are using a different version of Windows, the options may vary.

1. On the client computer, log on as the user who will run the application (you can use administrator or btsinstall). For BizTalk Server, log on as the user account for the BizTalkDecrypter host instance (btsrcv1).

2. Start Internet Explorer and connect to http://<servername>/certsrv, where <servername> is the computer name where the certification authority is running. (For this sample deployment, use the computer name of the domain controller.)

3. On the Welcome page, click Request a certificate.

4. On the Choose Request Type page, click advanced certificate request.

5. On the Advanced Certificate Request page, click Create and submit a request to this CA.

6. On the Advanced Certificate Request page, enter a friendly name for this certificate, make sure Exchange is selected for Key Usage, select Mark keys as exportable, accept the remaining default values, and then click Submit.

7. In the Potential Scripting Violation dialog box that prompts you to confirm your certificate request, click Yes.

8. On the Certificate Issued page, click Install this certificate.

9. In the Potential Scripting Violation dialog box that prompts you to confirm your certificate request, click Yes.

10. After you see the Certificate Installed page, you can close Internet Explorer.

The certificate is installed in the Personal certificate store for the account that requested the certificate.

On the client computer, you must now export the public key.

On the BizTalk Server computer, you must now export the private key.

Follow these steps on the second BizTalk Server computer (BTS2-SRV) to export the private key from the Personal certificate store to a location that is accessible to the other BizTalk Servers that need this key.

Note
You do not have to do this procedure for the client computer.

1. Log on as the user account for the BizTalkDecrypter host instance (btsrcv1).

2. Click Start, click Run, type mmc, and then click OK.

3. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

4. In the Add/Remove Snap-in dialog box, click Add.

5. In the Add Standalone Snap-in dialog box, select Certificates, click Add, and then click Close.

6. In the Add/Remove Snap-in dialog box, click OK.

7. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates - Current User, expand Personal, and then click Certificates.

8. In the Results pane, right-click the certificate you want to export, point to All Tasks, and then click Export to start the Certificate Export Wizard.

9. On the Welcome to the Certificate Export Wizard page, click Next.

10. On the Export Private Key page, click Yes, export the private key, and then click Next.

11. On the Export File Format page, leave the defaults, and then click Next.

12. On the Password page, type and confirm the password you want to use to help protect the private key file, and then click Next.

    Important
    If you use the certificate deployment utility to deploy private key certificates to BizTalk Server computers, you can only use numeric and alphabetical characters and the special characters ~ ! @ # $ % ^ *( ) - _ = + [ { ] } ; : , . / \ ? " ; for this password.

13. On the File to Export page, in the File name box, enter the location and name for the certificate. The location should be a share that other BizTalk Server computers can access. Use the .pfx extension for the certificate file. Then click Next.

14. On the Completing the Certificate Export Wizard page, click Finish.

15. In the Certificate Export Wizard dialog box, click OK.

After you export the encryption certificate on the BizTalk Server computer, export the public key.

Follow these steps on the client computer to export the public key from the client computer to the BizTalk Server computer receiving messages from the client computer (BTS-SRV).

Follow these steps on the second BizTalk Server computer (BTS2-SRV) to export the public key to the first BizTalk Server computer (BTS-SRV)

1. On the client computer, log on as the user who will run the application (you can use administrator or btsinstall). For BizTalk Server, log on as the user account for the BizTalkDecrypter host instance (btsrcv1).

2. In the Run dialog box, in the Open box, type mmc, and then click OK.

3. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

4. In the Add/Remove Snap-in dialog box, click Add.

5. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

6. On the Certificates snap-in page, select My user account, and then click Finish.

7. In the Add Standalone Snap-in dialog box, click Close.

8. In the Add/Remove Snap-in dialog box, click OK.

9. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates - Current User, expand Personal, and then click Certificates.

10. In the Results pane, right-click the certificate you want to export, point to All Tasks, and then click Export to start the Certificate Export Wizard.

11. On the Welcome to the Certificate Export Wizard page, click Next.

12. On the Export Private Key page, click No, do not export the private key, and then click Next.

13. On the Export File Format page, leave the defaults, and then click Next.

14. On the File to Export page, in the File name box, enter the location and name for the certificate, and then click Next.

15. On the Completing the Certificate Export Wizard page, click Finish.

16. In the Certificate Export Wizard dialog box, click OK.

Follow these steps on the BizTalk Server computer that receives messages from the client computer (BTS-SRV) to import the public key from the client computer.

Follow these steps on the second BizTalk Server computer (BTS2-SRV) to import the public key to the appropriate certificate store.

1. Log on to the BizTalk Server computer as a local administrator or as the btsinstall account.

2. Click Start, click Run, type mmc, and then click OK.

3. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

4. In the Add/Remove Snap-in dialog box, click Add.

5. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

6. On the Certificates snap-in page, select Computer account, and then click Next.

7. On the Select Computer page, make sure Local computer is selected, and then click Finish.

8. In the Add Standalone Snap-in dialog box, click Close.

9. In the Add/Remove Snap-in dialog box, click OK.

10. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates (Local Computer), right-click Other People, point to All Tasks, and then click Import.

11. On the Welcome to the Certificate Import Wizard page, click Next.

12. On the File to Import page, click Browse.

13. In the Open dialog box, open the location where you exported the public key in step 10 of the previous procedure, select the public key, and then click Open. This key should have a .cer file name extension.

14. On the File to Import page, click Next.

15. On the Certificate Store page, select Place all certificates in the following store, make sure that the certificate store is Other People, and then click Next.

16. On the Completing the Certificate Import Wizard page, click Finish.

17. In the Certificate Import Wizard dialog box informing you that the import was successful, click OK.

After you install the certificates on the BizTalk Server computers, you have to copy the thumbprint values for the certificates for use in following procedures.

You can also use the certificate deployment utility to retrieve the thumbprint values. For more information about using the certificate deployment utility to retrieve the thumbprint values, see Retrieving the Thumbprint Values.

1. Click Start, click Run, type mmc, and then click OK.

2. In the Microsoft Management Console window, click File, and then click Add/Remove Snap-in.

3. In the Add/Remove Snap-in dialog box, click Add.

4. In the Add Standalone Snap-in dialog box, select Certificates, and then click Add.

5. On the Certificates snap-in page, select Computer account, and then click Next.

6. On the Select Computer page, make sure Local computer is selected, and then click Finish.

7. In the Add Standalone Snap-in dialog box, click Close.

8. In the Add/Remove Snap-in dialog box, click OK.

9. In the Microsoft Management Console window, from the tree view in the left frame, expand Certificates (Local Computer), expand Other People, and then click Certificates.

10. Right-click the certificate you want to view the thumbprint for, and then click Open.

11. On the Details tab, scroll down until you see Thumbprint. Select the thumbprint value, and then press CTRL+C.

12. Paste the thumbprint to a location where you can access it later on.

This section provides guidelines for configuring the database computer in the sample certificate management deployment. It includes guidelines for configuring SQL Server 2000, modifying the properties for Microsoft Distributed Transaction Coordinator (MS DTC), and copying data to the database for the sample application.

Follow these steps when installing and configuring the computer that is running SQL Server.

1. The sample application assumes that this server is named SQL-SERVER. If you name this computer something different, you must modify the settings on the BizTalk Server.

2. Add the computer that is running SQL Server to the CONTOSO domain.

3. Install SQL Server 2000 on the computer. For more information about installing SQL Server 2000, see "Installing SQL Server" in SQL Server Books Online.

Follow these steps when modifying the properties for MS DTC.

1. Open Administrative Tools.

2. Open Component Services.

3. Right-click My Computer, and then click Properties.

4. Click the MSDTC tab.

5. Click Security Configuration.

6. Click Security Settings, and make sure that the Network Client check box is selected.

7. Close the dialog box and restart the computer.

Follow these steps to set up the sample database on the computer that is running SQL Server. This sample database contains business data about the purchase orders, and is independent from the BizTalk Server databases.

1. On the computer that is running SQL Server, log on as a SQL Server administrator.

2. If you used the default settings for the location of the installation files, open Windows Explorer and open the \\<BizTalk Server Computer>\Program Files\WSS Technical Guides\Certificate Management Technical Guide folder. Otherwise open the location you specified.

3. Copy the Database folder to the computer that is running SQL Server.

4. Locate the Database folder that you just copied from the BizTalk Server computer.

5. Double-click mount_db.vbs. This file will mount the sample database that the sample application uses.

6. Open SQL Server Enterprise Manager and verify that the ContosoOrder database has been successfully mounted.

Follow these steps to make sure the user account that will access the SQL Server database with the business data (sqladapter) has sufficient permissions to access the database.

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

2. Expand Microsoft SQL Servers, expand SQL Server Group, expand (LOCAL) (Windows NT), expand Security, right-click Logins, and then click New Login.

3. In the SQL Server Login Properties -New Login dialog box, on the Name box, type contoso\sqladapter.

4. On the Database Access tab, select the Permit check box for the ContosoOrders database, and then click OK.

5. Expand Databases, expand ContosoOrders, and then click Users.

6. In the Results pane, right-click Contoso\sqladapter, and then click Properties.

7. On the Database User Properties - contoso\sqladapter page, click Permissions.

8. Make sure that EXEC is selected for the SaveOrder row, and that SELECT, UPDATE, and INSERT are selected for the IncomingOrders row.

9. Click OK to exit the Database User Properties - ContosoOrders page.

10. Click OK to exit the Database User Properties - BizTalk SQL Adapter Host Users page.

11. Exit Enterprise Manager.

This section describes how to update the binding file with the new certificate keys. The binding file released with the sample was configured for a specific test environment. This step updates the binding file to match your particular environment.

Follow these steps to update the binding file.

1. Log on to the BizTalk Server computer where you installed the directory and files for the sample deployment (BTS-SRV). If you took the default settings for the location of the installation files, the files and directories for the sample deployment are in the C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide folder.

2. Open C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders, and double-click the adjust_setup.bat file. This file helps update the binding file for your particular environment.

3. If you did not use the recommended names for the computer that is running SQL Server and the client computer, enter the names of your SQL Server and application client computers.

4. Retrieve the thumbprint values as described in Retrieving the Thumbprint Values or in Configuring Certificates for the Sample Deployment.

5. In the Partner Thumbprint box, enter (or paste) the thumbprint for the client computer's encryption certificate (public key).

6. In the BizTalk Thumbprint box, enter (or paste) the thumbprint for the BizTalk Server encryption certificate (public key).

This section describes how to run the batch file that runs the modified binding file to configure your BizTalk Server environment and to complete the configuration of the BizTalk Server objects.

Follow these steps to run the deployment file on the BizTalk Server computer.

1. Log on to the BizTalk Server computer where you installed the directory and files for the sample deployment. If you took the default settings for the location of the installation files, the files and directories for the sample deployment are in the C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders folder.

2. Run the deploy.bat file. This file deploys the BizTalk Server orchestration and starts the sample orchestration. The batch file will finish with success messages.

Follow these steps to make sure the second BizTalk Server computer has the BizTalk assemblies in the global assembly cache.

1. Log on to the second BizTalk Server computer (BTS2-SRV) using the btsinstall account.

2. Open Windows Explorer and locate \\BTS-SRV\c$\windows\assembly.

3. Open a second instance of Windows Explorer and locate c:\windows\assembly.

4. On \\BTS-SRV\c$\windows\assembly, click ContosoOrders, and drag the file to c:\windows\assembly.

Follow these steps to add the certificate information to the BizTalkDecrypter host.

1. Retrieve the thumbprint value for the BizTalk Server encryption certificate as described in Retrieving the Thumbprint Values or in Configuring Certificates for the Sample Deployment.

   Note
   The public and private keys for a specific certificate (in this case the BizTalk Server encryption certificate) have the same thumbprint.

2. Open BizTalk Server Administration.

3. Expand Microsoft BizTalk Server 2004 (local), expand Hosts, right-click BizTalkDecrypter, and then click Properties.

4. In the BizTalkDecrypter Properties dialog box, click the Certificate tab.

5. In the Thumbprint box, type (or paste) the thumbprint for the BizTalk Server encryption certificate, and then click OK

To illustrate how BizTalk Server encrypts and decrypts messages in this sample deployment, the BizTalk orchestration drops a copy of the message it receives from the client computer into a folder. This message is encrypted. You can then move the message to another folder for the File receive adapter to pick it up, decrypt it, and put it in another folder. Follow these steps to create the folders where the messages will be dropped.

1. Log on to the second BizTalk Server computer (BTS2-SRV).

2. Create the following folders:

   C:\temp

   C:\temp\receive

   C:\temp\result

3. Make sure the account running the instance of the BizTalkDecrypter host (btsrcv1) has read and write permissions to these folders.

This section describes how to run the application that starts the sample certificate management deployment. The sample application was written using Microsoft® Visual Studio® .NET 2003.

Follow these steps to run the certificate management installation program on the client computer.

1. Log on to the client computer.

2. If you used the default settings for the location of the installation files, open Windows Explorer and open the \\<BizTalk Server Computer>\Program Files\WSS Technical Guides\Certificate Management Technical Guide\App Installer\Debug folder. Otherwise open the location you specified. Select the location where you want to copy the sample files. Click Next.

3. Copy App_Installer.msi to the client computer.

4. Double-click App_Installer.msi.

5. On the Welcome to the Certificate Management Sample App Setup Wizard page, click Next.

6. On the License Agreement page, read the agreement. If you agree to abide by the license agreement, click the I Agree option, and then click Next.

7. Select the location where you want the sample files to be copied. Click Next.

8. On the Confirm Installation page, click Next.

9. On the Installation Complete page, click Close to exit the installation program.

You are now ready to send a test message from the client computer to the BizTalk Server computers. Follow these steps to run the sample application.

1. Click Start, click All Programs, click WSS Technical Guides, click Certificate Management, and then click ContosoOrderProcessor.

2. If your BizTalk Server computer is named BTS-SRV, go to step 5.

3. If your BizTalk Server computer is not named BTS-SRV, click Setup.

4. Change the entry for the BizTalk Host field to the correct name of your BizTalk Server computer. The Local Queue should be ContosoOrderOutput and the BizTalk Queue should be ContosoInputQueue.

5. Change the values for Shirts, Pants, Socks, and Shoes. Click Order to send the order to the BizTalk Server. A confirmation XML message will be sent from the BizTalk Server and displayed in the Processed Orders text box.

   An order with the quantities that you specified is sent to the BizTalk Server for processing.

   An XML document confirming the order is returned to the sample application and displayed in the text box.

6. Click the order, and then click Order Details. The Order Details window shows the encrypted message.

7. Click Decrypt to see the decrypted message.

8. Click Close to close the Order Details window.

To illustrate how BizTalk Server encrypts and decrypts messages in this sample deployment, the BizTalk orchestration drops a copy of the message it receives from the client computer into a folder. This message is encrypted. You can then move the message to another folder for the File receive adapter to pick it up, decrypt it, and put it in another folder. Follow these steps to see how BizTalk Server encrypts and decrypts a message.

1. Log on to the second BizTalk Server computer (BTS2-SRV).

2. Open c:\temp\.

3. Double-click one of the *.txt files, and verify that the file is MIME encrypted.

4. Copy one of the encrypted files and drop it to c:\temp\receive for the File receive adapter to process it.

5. The file will now appear on c:\temp\result. Open the file (*.xml) to verify that the file is now in clear text.

The following steps offer some possible ways to fix your deployment if you cannot run the sample application successfully,

1. If you do not receive an XML document confirming the order, do the following:

   1. Make sure you restart the BizTalkServerApplication host instance in BTS-SRV after you add the BizTalk Message Queuing Adapter. For more information, see "Adding the BizTalk Message Queuing Adapter" in Configuring the BizTalk Server Computers.
      
   2. Make sure the sqladapter account has permissions to access the ContosoOrders database. For more information, see "Making Sure the User Account Has Correct Rights" in Configuring the SQL Server Computer.
      

2. If you cannot decrypt the order, do the following:

   1. Make sure you are running the ContosoOrderProcessor application with the same user account that you used to request the certificate for the partner.
      
   2. On BTS-SRV, open c:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders and open contoso-bind.xml. Make sure the thumbprints for BizTalk Server and the partner are correct.
      

3. If the thumbprints are incorrect, do the following:

   1. Open Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders
      
   2. Run cleanup.bat to undeploy the BizTalk ports, pipelines, and the orchestration.
      
   3. Run adjust-bind.bat. Make sure you type or paste the thumbprints in the correct boxes.
      
   4. Run deploy.bat to deploy the BizTalk ports, pipelines, and the orchestration.
      

4. If you are still having problems with the sample deployment, use Health and Activity Tracking (HAT) and the Event Viewer to identify the issue. For more information about HAT, see Health and Activity Tracking in BizTalk Server 2004 Help.

This section describes how to remove the sample deployment components from your computers. To remove the sample deployment components, you must do the following:

1. Remove the sample deployment application from APP-SRV.
   
2. Run the cleanup application to remove the BizTalk Server objects.
   
3. Remove the log files.
   
4. Delete the ContosoOrders database.
   
5. Remove the sample deployment application from BTS-SRV.
   

Follow these steps to remove the sample application from the client computer.

1. Log on to the client computer and open the location where you copied App_Installer.msi.

2. Double-click App_Installer.msi.

3. On the Welcome to the Certificate Management Sample App Setup Wizard page, click Remove Certificate Management Sample App, and then click Finish.

4. On the Installation Complete page, click Close to exit the installation program.

Follow these steps to run the cleanup application to undeploy the BizTalk ports, pipelines, and the orchestration.

1. Log on to the first BizTalk Server computer (BTS-SRV) using the btsinstall account.

2. Open C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders.

3. Run cleanup.bat to undeploy the BizTalk ports, pipelines, and the orchestration.

Follow these steps to remove the log files the sample application creates. By deleting these log files, you can remove all the directories associated with the sample deployment.

1. Log on to the first BizTalk Server computer (BTS-SRV) using the btsinstall account.

2. Open C:\Program Files\WSS Technical Guides\Certificate Management Technical Guide\ContosoOrders.

3. Delete the following files:

   Binding1.log.htm

   Binding1.log.xml

   Binding2.log.htm

   Binding2.log.xml

   Binding3.log.htm

   Binding3.log.xml

   Undeploy.htm

   Undeploy.xml

   Undeploy2.htm

   Undeploy2.xml

Follow these steps to remove the ContosoOrders database from the computer that is running SQL Server.

1. On the computer that is running SQL Server, log on as a SQL Server administrator.

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

3. Expand Microsoft SQL Servers, expand SQL Server Group, expand (LOCAL) (Windows NT), expand Databases, right-click ContosoOrders, and then click Delete.

4. On the confirmation message, click Yes.

5. Exit Enterprise Manager.

Follow these steps to remove the sample application from your computers.

Note
This also removes the certificate deployment utility. For more information about the certificate deployment utility, see Sample Certificate Deployment Utility.

1. Click Start, click Control Panel, and then click Add or Remove Programs.

2. In the Add or Remove Programs list, select Certificate Management Technical Guide, and then click Remove.

3. On the confirmation message, click Yes.

This section provides the steps and results of a threat model analysis (TMA) that we did for the sample deployment. By walking you through the steps, this section gives you a better understanding of how a TMA works, and also describes the potential threats we identified for the sample deployment and how we mitigated them.

For additional information about threat modeling, see the Threat Model Analysis topic in BizTalk Server 2004 Technical Guide for Security and chapter 4 of Writing Secure Code, Second edition, by Michael Howard and David LeBlanc.

Before the main threat analysis meeting, we collected the following background information about our sample deployment:

• Usage scenarios
  
• Data flow diagrams (DFDs)
  
• Boundaries and scope of the system
  
• Boundaries between trusted and untrusted components
  
• Configuration and administration model for the components
  
• Assumptions about other components and systems
  

The sample depicts a Point of Sale (PoS) application in which a salesperson from Contoso requests inventory items for the store. The salesperson uses a custom application to submit the request for items. The application submits the request to BizTalk Server, where the appropriate orchestration processes the order. To illustrate how to use certificates in this architecture, the orchestration sends the order to a pipeline where it is encrypted in one BizTalk Server, and then the second BizTalk Server decrypts the order before additional processing occurs. BizTalk Server uses the order information to update the SQL Server database that contains business data. BizTalk Server does a warehouse inventory check, and then submits an encrypted acknowledgment and inventory status back to the salesperson. The salesperson then decrypts the message.

This PoS application is used in an intranet environment, and salespeople and managers have access to it. For our sample, the PoS application only has users; we have not defined administrators. Therefore, no user group needs special permissions for BizTalk Server. The users of the PoS application need permissions to put messages in Message Queuing (also known as MSMQ).

The user group accounts and individual group accounts are created in Active Directory on the domain controller.

The following figure shows the Level 0 data flow diagram (DFD) for the sample deployment.

Figure 11 Level 0 data flow diagram

The data flow is as follows:

1. The salesperson logs on to the client computer (APP-SRV) and uses a fixed form within the PoS application to choose the number of items to order (inventory request).
   
2. When the form is submitted, the PoS application transforms the fixed form into an XML document, and sends it to BizTalk Server by using Windows Message Queuing (also known as MSMQ).
   
3. The BizTalk Message Queuing receive adapter (running in the BizTalkServerApplication host in BTS-SRV) picks up the message. After the receive adapter does the initial processing of the message, it puts the message in the MessageBox database (SQL-SERVER). A BizTalk orchestration that has the right subscription picks up the message and processes it.
   
4. To illustrate the encryption step, the orchestration sends the order document to a File send port (SaveEncryptedContosoOrder). The File send adapter picks up the message, encrypts it, and puts it in a file location.
   
5. To illustrate the decryption step, the File receive adapter (running in the BizTalkEncrypter host in BTS2-SRV) picks up the message, decrypts it, and puts it in a file location in clear text.
   
6. The orchestration passes the message to the SQL adapter (running in the BizTalkServerApplication host in BTS-SRV). The SQL adapter picks up the message and sends it to a stored procedure in the SQL Server database with the business data. The stored procedure enters the data into a database table and sends the message back to the SQL adapter. The SQL adapter puts the document back in the MessageBox database.
   
7. The orchestration then passes the response message back to the PoS application by using the BizTalk Message Queuing send adapter (running in the BizTalkServerApplication host in BTS-SRV). The BizTalk Message Queuing adapter picks up the message from the MessageBox database, encrypts it, and puts it in the Message Queuing queue that the PoS application uses.
   
8. The PoS application picks up the message. It appears as an encrypted message.
   
9. The salesperson decrypts the message to view the details of the acknowledgment.
   

• This sample PoS application is used in an intranet environment, and salespeople and managers have access to it.
  
• At this point, only one user at a time can use the application.
  
• The sample application retrieves business data from the business data database.
  
• The sample application is not connected to the Internet.
  
• Only users who have a valid account in the domain can use the sample application.
  

To create boundaries, we used different hosts as a security boundary between applications within BizTalk Server.

If you are using this sample to guide you in developing your own environment, we recommend that you use Internet Protocol security (IPSec) to restrict communication between servers and use a firewall to restrict access from the application server to the BizTalk Server computer and the databases.

Additionally, we recommend that you use different BizTalk Hosts to separate the processing functions from the receiving and sending functions, and that you create different hosts for each adapter.

Configuration

Administration

This issue is not applicable; this is a stand-alone application.

This section describes the key steps and findings during the threat analysis meeting for the certificate management sample deployment.

At the beginning of the meeting, we reviewed the background information we collected before the meeting, and identified the entry points, trust boundaries, and flow of data.

Entry points

• PoS application
  
• Message Queuing
  

Trust boundaries

• See "Boundaries and Scope of the System" in the previous topic.
  
• See "Boundaries Between Trusted and Untrusted Components" in the previous topic.
  

Flow of data

• See "Data Flow Diagrams" in the previous topic.
  

Using the STRIDE (Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges) method, we identified the following threats to the PoS application. Note that we listed all the threats we identified, even if we were already mitigating them.

Table 3 Threats to the PoS application

Threat	Description	Threat target	Threat type
An unauthorized user can put messages in the queue.	If a user has write permissions to the queue from which BizTalk Server picks up messages, then that user can submit messages to BizTalk Server.	BizTalk Server environment	Spoofing identity Tampering with data Elevation of privileges
An unauthorized user can view the received message in the PoS application.	Any user who has access to the PoS application can view the acknowledgments that BizTalk Server sends to the application.	Message	Information disclosure
Access to private keys	If a user has access to the private keys, either when you receive them from the certification authority or when they are stored in the Personal certificate store, that user can use the private key to decrypt messages and/or sign messages.	Certificate keys	Spoofing identity Tampering with data Information disclosure
Access to public keys	Any users of the computer where you store the public keys has access to the public keys, because they are stored in the computer's Local Computer store. Users of this computer can use the public key to encrypt and/or verify signatures.	Certificate keys	Information disclosure
A malicious user can sniff data in the wire between BizTalk Server and the client computer.	By default, the communication between BizTalk Server and the client application is in the client computer that is running the PoS application text. A malicious user can sniff the data as it travels from one server to another.	Message	Information disclosure
Access to private keys after computer is reused	If you install private keys in a user's personal store, and then reuse the server for other purposes, the private keys may remain in the server, where a malicious user may obtain access to them.	Certificate keys	Spoofing identity Tampering with data Information disclosure
A malicious user can replace the receive location with a rogue receive location or server.	If a malicious user replaces the BizTalk receiving server with a rogue BizTalk Server, that server can intercept the messages.	Message	Spoofing identity Tampering with data Information disclosure
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.	By default, the communication between BizTalk Server and the SQL Server databases is in clear text. A malicious user can sniff the data as it travels from one server to another.	Message	Spoofing identity Tampering with data
A malicious user can tamper with the application binaries.	If a malicious user has access to the network resources, that user may be able to locate the binaries for the PoS application, tamper with them, and cause unwanted behavior.	Test application	Tampering with data Information disclosure Denial of service Elevation of privileges
We cannot prove that we received a message, or that we sent a reply.	If there are no good auditing mechanisms in place, then we may not be able to prove that a specific employee submitted an order, or that BizTalk sent an acknowledgment.	Message	Repudiation
Employees can order as may items as they want.	There should be a limit on how many items employees can order, requiring management approval to exceed that limit.	Inventory	Tampering with data Elevation of privileges Note While this is not a standard elevation of privileges threat (they cannot gain control of the system through this threat), employees currently can order more items than they should, which is a different form of elevation of privileges.
A malicious user can see and retrieve data in the Message Queuing queue.	If users can access the queue to which BizTalk drops messages, then they can read and modify the messages.	Message	Spoofing identity Tampering with data Information disclosure
A malicious user can insert a bad message into BizTalk Server.	A malicious user can identify the communication channel between the PoS application and BizTalk Server, and send unauthorized messages to BizTalk Server.	Message	Tampering with data Spoofing identity
A malicious user can insert a bad message into the test application.	A malicious user can provide invalid data to the PoS application, which can help the user break into the stored procedure that BizTalk Server uses to retrieve business data.	Data in the business database	Tampering with data Information disclosure Elevation of privileges
A malicious user can use the stored procedure as an access point to the business database.	If a malicious user gains access to the stored procedure that BizTalk Server uses to retrieve business data, then the user can take advantage of the stored procedure to access and modify the data in the business database.	Data in the business database	Tampering with data Information disclosure
A malicious user can see data in the stored procedure.	If a malicious user gains access to the stored procedure that BizTalk Server uses to retrieve business data, then the user can see and modify the data within the stored procedure.	Data in the business database	Tampering with data Information disclosure
An unauthorized user can obtain data in the business database.	Only the people and processes that have to access the data in the business database should have access to the database.	Data in the business database	Tampering with data Information disclosure

After the main threat modeling meeting, we reviewed the threats and used the DREAD rating (Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability) to identify the risk for each threat.

The following table lists the threats and their DREAD ratings.

Table 4 Threats and their DREAD ratings

After identifying the threats and their risks, we proceeded to identify the mitigation techniques for each threat.

The following table lists the threats, the mitigation techniques, and whether we implemented the mitigation for the PoS application. The threats are ordered from greater risk to lower risk.

Table 5 Threats in order of risk level

Threat	Threat type	Overall risk	Mitigation techniques and technologies	Implemented?
Employees can order as may items as they want.	Tampering with data Elevation of privileges	9	Modify the application so that there is a limit to the number of items that a person can order. An additional modification is to enable a manager to order more items, or to require manager approval for an employee to order more than the maximum allowed.	Yes. We implemented an upper limit of 100 items, and a lower limit of 0 items.
An unauthorized user can obtain data in the business database.	Tampering with data Information disclosure	8.2	Create a separate host for the SQL adapter. Create a user group and account dedicated to this new host. Lock down access to the business database by granting permissions in SQL Server only to the members of the SQL User group. Give the SQL User group access to the business database as users only, and only give them permissions to the specific stored procedures they need access to.	Yes
A malicious user can tamper with messages as they go from BizTalk Server to SQL Server and vice versa.	Spoofing identity Tampering with data	6.8	Use Internet Protocol security (IPSec) to encrypt communication between BizTalk Server and SQL Server.	Yes
An unauthorized user can view the received message in the PoS application.	Information disclosure	6.8	Only people that have the private encryption certificate in the personal certificate store can view the message. Only authorized users can access the PoS application.	Yes. Sample application first shows the message in encrypted form. Users must have a copy of the private certificate in their personal store to decrypt the message
A malicious user can see and retrieve data in the Message Queuing queue.	Spoofing identity Tampering with data Information disclosure	6.6	Use encryption to make sure that only authorized users and processes can read the message. Use Message Queuing client authentication to restrict access to the queue. Important Message Queuing client authentication only works when the client and the server are on the same domain controller.	No
Access to public keys	Information disclosure	6.6	By default, public keys are designed to be shared with multiple parties. A person with the public key can only encrypt messages and verify digital signatures. The disclosure of public keys does not pose a significant risk to your company. However, a malicious user can use the public key to encrypt messages it sends to you. If you do not have a mechanism in place for authenticating the sender, such as digital signatures, a malicious user can create a denial of service attack by sending invalid encrypted messages.	No.
A malicious user can replace the receive location with a rogue receive location or server.	Spoofing identity Tampering with data Information disclosure	6.4	Follow the recommendations in Assembly Deployment Security Recommendations in BizTalk Server 2004 Help to protect the assembly that contains the receive location and to restrict access to the assembly files. You must place your computers in a safe environment, and limit access to the computers that contain business-critical information, such as the databases.	Yes.
A malicious user can tamper with the application binaries.	Tampering with data Information disclosure Denial of service Elevation of privileges	6.4	While not part of the sample solution, the data center administrators have to limit access to the application binaries. Administrators must remove the binary file after deploying the BizTalk assemblies. You can also use signed assemblies to secure assemblies from end to end.	No
An unauthorized user can put messages in the queue.	Spoofing identity Tampering with data Elevation of privileges	6.4	Access to the Message Queuing queue should be restricted to only the accounts that have to drop (write) and pick up (read and delete) messages from the queue. Only the service account for the BizTalk Message Queuing host should be able to write to the Message Queuing queue.	No
A malicious user can see data in the stored procedure.	Tampering with data Information disclosure	6.4	Use different user groups for each BizTalk Host. Have a host dedicated to the SQL adapter. In SQL Server grant permissions only to the members of the SQL User group, and give this group user access to the business database, and permissions to the specific stored procedures they have to run.	Yes
A malicious user can use the stored procedure as an access point to the business database.	Tampering with data Information disclosure	6.2	As with the previous threat, the SQL User group should only have permissions to the specific stored procedures they have to run.	Yes
We cannot prove that we received a message, or that we sent a reply.	Repudiation	6	Use the BizTalk tracking features, and the standard log files. Important While this mitigation can help you prove that you sent or received a message, it may not meet the requirements for legal auditing.	Yes
A malicious user can insert a bad message into the test application.	Tampering with data Information disclosure Elevation of privileges	6	Only authorized users can access the PoS application. Processes downstream should verify that the message came from an authorized user.	No
A malicious user can insert a bad message into BizTalk Server.	Tampering with data Spoofing identity	5.6	Do not use default host and group names. Use different user groups for each BizTalk Host. Have a different host for send and receive for each adapter, processing, and tracking. Use the BizTalk S/MIME security features to prove the identity of the sender (from either direction) and to validate that the incoming request is valid. Drop the message if the incoming request is not valid.	Somewhat. We have separate hosts and groups, but do not use S/MIME.
A malicious user can sniff data in the wire between BizTalk Server and the client computer.	Information disclosure	5.6	Use encryption certificates to make sure that only authorized users can access the message.	Yes
Access to private keys	Spoofing identity Tampering with data Information disclosure	4.8	Modify PoS application so that it runs under a service account. This way you have to store the private key in one location. Restrict access to the PoS application by using DACLs	No
Access to private keys after computer is reused	Spoofing identity Tampering with data Information disclosure	4.6	Use strong passwords for all accounts, including those that have certificates in the personal certificate store. Revoke certificates that you are no longer using. Remove the certificates from the personal certificate stores before reusing the computer.	No

The sample certificate deployment utility helps you automate the installation of certificates in the appropriate certificate stores of selected computers that are running Microsoft® BizTalk® Server 2004.

The utility installs public certificates in the Other People certificate store of the selected BizTalk Servers. For private certificates, it does the following:

• Prompts you for the password for the user account under which each host instance on the selected BizTalk Server computers is running.
  
• Logs on to each BizTalk Server as each account.
  
• Installs the private key certificate in the Personal certificate store for each account.
  

As described in previous sections, to send and receive encrypted or signed messages, you must install the certificates in the appropriate certificate store on each BizTalk Server runtime computer. If you have a small number of partners, or a small BizTalk Server deployment, an administrator can easily take on the task. If you have many partners, logging on to each BizTalk Server computer and manually installing their certificates can become a complex task.

This section provides information about how to use the sample certificate deployment utility.

This section describes the steps that you must follow to configure the BizTalk Server environment to use the certificate deployment utility. These steps are:

1. Run the private certificate handler installation program.
   
2. Create an account for creating and accessing the log files.
   
3. If you have not done so already, mount the Certificate_logging database on the computer that is running SQL Server, and make sure the logging account has sufficient permissions to access the database.
   
4. Configure the certificate logging Web service to use the logging account.
   
5. Update the certificate logging Web service configuration file with the correct name for the computer hosting the Web service.
   

Important

You must have already run the certificate deployment utility installation program. The certificate deployment utility is installed as part of the sample certificate management deployment. If you have not done so, follow the instructions for "Running the Installation Program for the Sample Deployment" in Configuring the BizTalk Server Computers to install the certificate deployment utility on a BizTalk Server computer.

Running the Private Certificate Handler Installation Program

Creating an Account for Certificate Logging

Mounting the Certificate_logging Database

Configuring the Certificate Logging Web Service

Updating the Certificate Logging Web Service Configuration File

The first step for using the certificate deployment utility is to generate a list of the BizTalk Server computers that are running host instances. After you generate this list, you can edit it, save it for future use, and retrieve it later. After you have the list, you can install or remove certificates. This section describes how to list the BizTalk Host instances available in your deployment. This section includes guidelines for:

• Generating a list of host instances
  
• Editing a list of host instances
  
• Saving a list of host instances
  
• Loading a list of host instances
  

Generating a List of Host Instances

Editing a List of Host Instances

Saving a List of Host Instances

Loading a List of Host Instances

This section provides instructions on how to use the certificate management utility to install public key certificates to the Other People certificate store of the BizTalk Server computers.

Deploying Public Certificates on the BizTalk Server Computers

This section provides instructions on how to use the certificate management utility to install a private certificate in the Personal certificate store for the user accounts of a selected list of host instances.

Note
The private key certificate must be in shared directory that all BizTalk Server computers have access to. Only a Windows® administrator account that you use for installing the certificates remotely needs access to this share.

Deploying Private Certificates on the BizTalk Server Computers

This section describes how to retrieve the thumbprints for the public and private keys for each company (in this example, the application client computer and the BizTalk Server deployment).

Using the Certificate Deployment Utility to Retrieve Thumbprints

This section provides information about how to use the certificate management utility to delete public and private certificate keys from the certificate stores on the BizTalk Server computers.

Deleting Public Certificates

Deleting Private Certificates

Applying the Microsoft Operations Framework (MOF) process model to the management of Microsoft® BizTalk® Server 2004 certificates can help you make sure that you have appropriate processes in place at the different stages of the release life cycle. By looking ahead at all the life cycle stages where certificate management appears, you can make the installation, maintenance, and troubleshooting of certificates in your environment easier.

This section contains information about the MOF processes where you may want to consider certificate management tasks.

The Microsoft Operations Framework (MOF) provides guidance that enables organizations to achieve mission-critical system reliability, availability, supportability, and manageability of Microsoft products and technologies. MOF provides operational guidance in the form of white papers, operations guides, assessment tools, best practices, case studies, templates, support tools, and services. This guidance addresses the people, process, technology, and management issues pertaining to complex, distributed, and heterogeneous IT environments.

The MOF process model enables companies to:

• Facilitate consistent IT service management across service solutions
  
• Establish a structure for IT functions, processes, and procedures
  
• Represent a life cycle approach
  

Central to the MOF process model is its division into four quadrants of operational processes and procedures, named service management functions (SMFs). The SMFs are the foundation-level best practices and prescriptive guidance for operating and maintaining an IT environment.

The following figure shows the MOF processes where you may want to consider certificate management.

Figure 12 MOF processes where you may want to consider certificate management

The changing quadrant includes the service management functions (SMFs) required to identify, review, approve, and incorporate change into a managed IT environment. This includes changes in software, hardware, documentation, roles and responsibilities, and so on, as well as specific process and procedural changes.

Change Management

Configuration Management

Release Management

The operating quadrant includes the SMFs required to monitor, control, manage, and administer service solutions daily to achieve and maintain service levels within predetermined parameters.

Security Administration

The supporting quadrant includes the SMFs required to identify, assign, diagnose, track, and resolve incidents, problems, and requests within the approved requirements that are contained in the service level agreements.

The optimizing quadrant includes the SMFs that contribute to maintaining business and IT alignment by focusing on decreasing IT costs while maintaining or improving service levels. This includes review of outages and incidents, examination of cost structures, staff assessments, availability and performance analysis, and capacity forecasting.

Service Level Management

Availability Management

Security Management