Installation of SSO on SQL Cluster

In this post I will tell a story of my experience with installation of SSO on SQL Cluster. Each BizTalk Server has an Enterprise Single Sign-On service (EntSSO.exe). Enterprise Single Sign-On is also referred as SSO or EntSSO. SSO serves two purposes. One is for data encryption, that is, port URI data. And the other is, as what the name indicates, Single Sign-On. Single Sign-On is about credential mapping. BizTalk Server SSO currently supports only Windows-initiated Single Sign-On. That means you can only map Windows users accounts to external application (affiliate application) user accounts. On the inbound side the sender is authenticated with Windows; on the outbound side, BizTalk Server automatically authenticates with the affiliate applications using the preconfigured credential mapping. Single Sign-On is a useful feature in business-to-business (B2B) scenarios.

Note: However the encryption function is mandatory for a BizTalk system. Single Sign-On for credential mapping can be solved with other tools like Oracle Wallet.

In addition to the SSO services running on each of the BizTalk Servers, there is a master secret server. The master secret server is a server with the SSO service running on it. The master secret server can be one of the SSO services running on one of the BizTalk Servers, or a dedicated master secret server.

It is the same executable called EntSSO.exe, but with an additional sub component responsible for maintain and supply the master secret key to the SSO services on the other BizTalk Servers. The other SSO services running on the BizTalk Servers check every 30 seconds to see whether the master secret has changed. If it has changed, they read it securely; otherwise, they continue to use the master secret they already have cached in memory.

Considering there is only one master secret server in your entire environment and the dependency of BizTalk Server, it is recommended that you use an active-passive cluster configuration for the master secret server. Because the master secret server doesn’t consume a lot of resources, it is very common to use the SQL Server failover cluster for clustering the master secret server.

On the first server cluster node where you run BizTalk Server Configuration, you choose to create a new SSO system. That makes the cluster node as the master secret server. The host name of the master secret server is the host name of the physical cluster node. The master secret key is automatically generated on that node. On the other cluster node, you choose to join the existing SSO system. To cluster the master secret server, you need to change the master secret server from the first cluster node host name to the virtual SQL Server failover cluster network name (NameSQL1), and create a SSO generic service cluster resource. At the end, you restore the master secret key to the other cluster nodes. So, when the cluster fails over to another node, that node has the master secret. These steps can be done using the domain admin account (usually a network senior administrator will perform these steps with this account i.e. as example I will name the account InstallBizTalk).

Clustering the master secret server service is a complicated process. You might find it confusing when and where you need to perform a step, and the order of the steps. Here are some general rules:

· You must install and configure SSO on each of the cluster nodes. When you create the new SSO system on the first cluster node, this node can be either an active cluster node or a passive cluster node.

· After you successfully installed and configured SSO on all of the cluster nodes, you must update the master secret server host name from a physical cluster node host name to the virtual cluster network name, and you must change the rename from an active node.

· After the master secret server host name is changed, you must restart the SSO service on the active node to refresh the cache by taking the SSO cluster resource offline and then online.

· You must create an SSO cluster resource before restoring the master secret key on the other cluster nodes.

· Before you restore the master secret key on a cluster node, you must make it the active node first.

Steps involved to successfully install and configure SSO on cluster will be outlined here.

There are several SSO user groups. Two of them are required when configuring the master secret server. SSO Administrators have the highest level user rights in the SSO system; and SSO Affiliate Administrators defines the affiliate applications that the SSO system contains.

To create a domain group account for the SQL Server service groups

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A using domain admin account.

2. Click Start, and then click Run.

3. In the Run dialog box, enter dsa.msc, and then click OK.

4. From Active Directory Users and Computers, if the YourDomain domain is not already expanded, click the plus sign (+) to expand the YourDomain.com domain.

5. In the left pane, right-click Users, point to New, and then click Group.

6. From New Object – Group, enter the following values, and then click OK.

7. Repeat steps 5 to 6 to create one more group:

To create a domain user account for the SSO Service

1. (continue from the previous procedure)

2. In the left pane, right-click Users, point to New, and then click User.

3. From New Object – User, enter the following values, and then click Next.

4. Enter or select the following values, and then click Next.

5. Click Finish.

Both YourDomainSSOSerivce and domain admin account need to be members of the YourDomainSSO Administrators group. It is designated for installing and configuring the BizTalk Server system.

To make YourDomainSSOService and domain admin account members of SSO Administrators

1. (continue from the previous procedure)

2. In the left pane, highlight Users.

3. In the right pane, right-click SSO Service, point to All Tasks, and then click Add to a group.

4. From Select Group, enter or select the following values, and then click OK.

5. To acknowledge that the account was created, click OK.

6. Repeat steps 3 to 5 to add domain admin account into the same group.

Granting YourDomainSSO Administrators Full Control on Cluster Node A

You need to grant YourDomainSSOService or YourDomainSSO Administrators with the full control privilege on the cluster administrator.

To grant YourDomainSSO Administrators full control on the cluster

1. If you haven’t already logged on or if you are logged on with a different credential, log on to Cluster Node A as YourDomainIInstallBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, in the left pane, right-click CLUSTER NODE A, and then click Properties.

4. From CLUSTER NODE A Properties, click the Security tab, and then click Add.

5. From Select Users, Computers, or Groups, enter the following values, and then click OK.

6. Verify the Allow box is selected, and then click OK.

Installing the SSO Components on Cluster Node A

With the accounts and permissions configured in the last step, you can now install the master secret server. BizTalk Server is not cluster aware as SQL Server is. You will need to install SSO on each of the cluster nodes. You will also need to create the SSO cluster resource manually.

BizTalk Server installation process has two parts. In this step, you will install the components. And the next step is configuring the master secret server.

To install the SSO components on Cluster Node A and Cluster Node B

1. If you haven’t logged on, log on to Cluster Node A as YourDomainInstallBizTalk.

2. Run setup.exe to install BizTalk Server 2006 R2.

3. On the Start page, click Install Microsoft BizTalk Server 2006 R2 on this computer.

4. On the Customer Information page, enter information in the User name box, the Organization box, and the Product key box, and then click Next.

5. On the License Agreement page, read the license agreement, select yes, I accept the terms of the license agreement, and then click Next.

6. On the Component Installation page, clear all the check boxes, select Enterprise Single Sign-On Administration Module and Enterprise Single Sing-On Master Secret Server from the Additional Software group, and then click Next.

7. On the Summary page, click Install.

8. On the Installation Completed page, clear Launch BizTalk Server Configuration check box, and then click Finish.

Installing the SSO Components on Cluster Node B

Repeat the same steps to install the SSO components on Cluster Node B.

Configuring the Master Secret Server on Cluster Node A

Configuring the master secret server has three parts, creating SSO database, assigning SSO service account, and backing-up the master secret. Notice there are two options, create a new SSO system, and join an existing SSO system. On the first cluster nodes, you must choose to create a new SSO system. When you create a new SSO system, you must specify the database server name, and the database name. But you don’t need to specify the master secret server host name. The current host name, becomes the default master secret server. Later, you must change the master secret server from the physical cluster node host name to the virtual cluster host name, YourVirtualServerName.

It doesn’t matter whether Cluster Node A is the active node or a passive node when you go through this procedure.

To configure the master secret server on Cluster Node A

1. If you haven’t logged on, log on to Cluster Node A as YourDomainInstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

4. in the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

6. In the left pane, click Enterprise SSO Secret Backup. The Enterprise SSO secret is very critical. You must back it up to a file. It is a good practice to burn the key into a CD and store the CD in a safe place.

7. In the right pane, enter the following values:

8. Click Apply Configuration.

9. On the Summary page, to apply the configuration, click Next.

10. Verify that the Configuration Result is Success, and then click Finish.

11. Close Microsoft BizTalk Server 2006 Configuration.

1.1.4 Configuring SSO on Cluster Node B

On the second node, you choose to join the existing SSO system. When joining the existing SSO system, it shares the SSO database of the existing SSO system.

To configure the master secret server on Cluster Node B

1. If you haven’t logged on, log on to Cluster Node B as YourDomainInstallBizTalk.

2. Click Start, point to All Programs, point to Microsoft BizTalk Server 2006, and then click BizTalk Server Configuration.

3. On the Microsoft BizTalk Server 2006 Configuration page, choose Custom Configuration, enter the following values, and then click Configure.

4. In the left pane, click Enterprise SSO.

5. In the right pane, enter or select the following values:

6. Click Apply Configuration.

7. On the Summary page, to apply the configuration, click Next.

8. Verify that the Configuration Result is Success, and then click Finish.

9. Close Microsoft BizTalk Server 2006 Configuration.

1.1.5 Updating the Master Secret Server Host Name

When SSO was configured on the first cluster node, it created a new SSO system. It used the host name of the physical cluster node as the master secret server host name that is Cluster Node A. You must change it to the server cluster virtual name, which is YourVirtualClusterName. This procedure must be carried out from the active cluster node. All it does is to update the master secret server field in the SSO database.

To configure the master secret server on Cluster Node B

1. If you haven’t already logged on, log on to Cluster Node A as YourDomainInstallBizTalk.

<sso>

  <globalInfo>

    <secretServer> ServerName Database Cluster</secretServer>

  </globalInfo>

</sso>

2. Open a notepad.exe, create a file with the following content, and then save it as “C:Program FilesCommon FilesEnterprise Single Sign-OnSSOCluster.xml” (with the double quotes). The content is case sensitive.

3. Open a command prompt, and then change directory to the C:Program Files Common FilesEnterprise Single Sign-On folder.

4. From the command prompt, execute the following command:

ssomanage -updatedb SSOCluster.xml

5. Verify the master secrete server name has been changed to  as shown below:

C:Program FilesCommon FilesEnterprise Single Sign-On>ssomanage -updatedb ssocluster.xml

Using SSO server on this computer

Updated SSO global information with the following values -

SSO secret server name                  : ServerName Database Cluster

SSO Admin account name                  : NOT CHANGED

SSO Affiliate Admin account name        : NOT CHANGED

Creating SSO Cluster Resource

BizTalk Server is not cluster aware. So you must manually create the master secret server cluster resource. You can either create a dedicated virtual server (cluster group) for the SSO cluster resource, or use an existing cluster group. The instructions provided use the SQL Server Cluster Group. If you create a dedicated cluster group, you also need to create a network name cluster resource depended by the SSO cluster resource.

To Create SSO cluster resource

1. If you haven’t already logged on, log on to Cluster Node A as YourDomainInstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. In the left pane, expand CLUSTER NODE A, expand Groups, and then expand SQL Server Cluster Group. If you get a prompt before it opens Cluster Administrator, choose Open Existing Cluster, and point it to CLUSTER NODE A.

4. Right-click SQL Server Cluster Group, click New, and then click Resource.

5. From New Resource, enter or select the following values, and then click Next.

6. From Possible Owners, verify that CLUSTER NODE A and CLUSTER NODE B are in the Possible owners list, and then click Next.

7. From Dependencies, select SQL Network Name (Cluster Node A) and click Add. And then click Next.

8. From Generic Service Parameters, type or select the following values, and then click Next:

9. From Registry Replication, click Finish.

10. In the details pane, right-click ENTSSO, and click Bring Online. Verify that the state is changed to Online.

Restoring the Master Secret on Cluster Node B

Before restoring the master secret on Cluster Node B, you must make Cluster Node B as the active cluster node, and restart the cluster resource by taking the cluster resource offline and then online.

To make Cluster Node B the active cluster node

1. Log on to Cluster Node B as RBW-NLInstBizTalk.

2. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.

3. From Cluster Administrator, expand CLUSTER NODE A in the left pane, expand Groups, and then expand SQL Server Cluster Group. In the details pane, the Owner column of the cluster resources shows the active cluster node.

4. If Cluster Node B is not the active cluster node, in the left pane right-click SQL Server Cluster Group, and then click Move Group. Wait until all the cluster resources are online.

5. In the details pane, right-click ENTSSO, and then click Take Offline. Wait until all the cluster resources are offline.

6. In the details pane, right-click ENTSSO, and then click Bring Online. Wait until all the cluster resources are online.

To restore the master secret on the second cluster node

1. Copy the master secret backup file, C:Program FilesCommon FilesEnterprise Single Sign-OnSSOSecret.bak, on Cluster Node A to the same folder on Cluster Node B. SSOSecret.bak is how you named the file when you configured the master secret server on Cluster Node A.

2. Open a command prompt, and then change the directory to C:Program FilesCommon FilesEnterprise Single Sign-On.

3. Type and execute the following command in the command prompt:

ssoconfig -restoresecret SSOSecret.bak

Through following this procedure you will be successful in deploying SSO on SQLCluster and configure SSO. My experience is that in following this procedure with an senior administrator inside an organization works the best. This procedure us done with BizTalk Server 2006 R2, but is also suitable for BizTalk Server 2009.

Technorati:BizTalk 2006 R2BizTalk Server 2006 R2BizTalk

Author: Steef-Jan Wiggers

Steef-Jan Wiggers is all in on Microsoft Azure, Integration, and Data Science. He has over 15 years’ experience in a wide variety of scenarios such as custom .NET solution development, overseeing large enterprise integrations, building web services, managing projects, designing web services, experimenting with data, SQL Server database administration, and consulting. Steef-Jan loves challenges in the Microsoft playing field combining it with his domain knowledge in energy, utility, banking, insurance, healthcare, agriculture, (local) government, bio-sciences, retail, travel, and logistics. He is very active in the community as a blogger, TechNet Wiki author, book author, and global public speaker. For these efforts, Microsoft has recognized him a Microsoft MVP for the past 8 years. View all posts by Steef-Jan Wiggers