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.

Name

Value

Group name

SSO Administrators

Group scope

Global

Group type

Security

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

Name

Value

Group name

SSO Affiliate Administrators

Group scope

Global

Group type

Security

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.

Name

Value

First name

SSO

Last name

Service

User logon name

SSOService

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

Name

Value

Password

TBD

Confirm password

TBD

User must change password at next logon

(clear)

User cannot change password

(select)

Password never expires

(select)

Account is disabled

(clear)

5. Click Finish.

Both YourDomain\SSOSerivce and domain admin account need to be members of the YourDomain\SSO Administrators group. It is designated for installing and configuring the BizTalk Server system.

To make YourDomain\SSOService 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.

Name

Value

Select this object type

Group or Built-in security principal

From this location

YourDomain

Enter the object name to select

SSO administrators

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 YourDomain\SSO Administrators Full Control on Cluster Node A

You need to grant YourDomain\SSOService or YourDomain\SSO Administrators with the full control privilege on the cluster administrator.

To grant YourDomain\SSO 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 YourDomain\IInstallBizTalk.

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.

Name

Value

Select this object type

Group or Built-in security principal

From this location

YourDomain.com

Enter the object name to select

SSO administrators

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 YourDomain\InstallBizTalk.

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.

clip_image002

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 YourDomain\InstallBizTalk.

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.

Name

Value

Database server name

Database Name Cluster

User name

YourDomain\SSOService

Password

TBD

4. in the left pane, click Enterprise SSO.

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

Name

Value

Enable Enterprise Single Sign-On on this computer

(checked)

Create a new SSO system

(selected)

SSO Database: Server Name

Database Name Cluster

SSO Database: Database Name

SSODB

Enterprise Single Sign-On Service: Account

YourDomain\SSOService

SSO Administrator(s): Windows Group

YourDomain\SSO Administrators

SSO Affiliate Administrators(s): Windows Group

YourDomain\SSO Affiliate Administrators

 

image

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:

Name

Value

Secret back password

TBD

Confirm password

TBD

Password reminder

TBD

Backup file location

C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSecret.bak)

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 YourDomain\InstallBizTalk.

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.

Name

Value

Database server name

ServerName Database Cluster

User name

YourDomainSSOService

Password

TBD

4. In the left pane, click Enterprise SSO.

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

Name

Value

Enable Enterprise Single Sign-On on this computer

(checked)

Join an existing SSO system

(selected)

Server Name

ServerName Database Cluster

Database Name

SSODB

Account

YourDomain\SSOService

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 YourDomain\InstallBizTalk.



<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 Files\Common Files\Enterprise Single Sign-On\SSOCluster.xml" (with the double quotes). The content is case sensitive.



 



clip_image002[5]



3. Open a command prompt, and then change directory to the C:\Program Files\ Common Files\Enterprise 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 Files\Common Files\Enterprise 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




 



image



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 YourDomain\InstBizTalk.



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.

clip_image002[9]



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:

clip_image002[11]



9. From Registry Replication, click Finish.










clip_image001Note



Do not configure any registry keys for replication in the Registry Replication dialog box. Replication of registry keys is not a requirement when creating a SSO cluster resource and, in fact, may cause problems when failover of this cluster resource is attempted.





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-NL\InstBizTalk.



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 Files\Common Files\Enterprise Single Sign-On\SSOSecret.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 Files\Common Files\Enterprise Single Sign-On.



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



ssoconfig -restoresecret SSOSecret.bak



image

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:

Comments

Hari said…
I have a Biztalk server 2006 R2 environment running without SSO clustering.One of the biztalk servers acts as the SSO Master.
My SQL is clustered.
Can I move my SSO service to SQL cluster?

Thanks
Hi Hari,

Having your SSO Master on BizTalk instance will cause problems if you want to scale out to more BizTalk instances. It is a best practice to have your SSO on a SQL cluster. In your case you will need to unconfigure SSO in your current BizTalk instance. Hence there is a dependency with your host instance, you will to stop them too. If your environment is a production one, you will need some time to be offline so you can setup SSO on your SQL Cluser. It will only take about half hour to setup your SSO on SQL Cluster; at least that is my experience. Having someone around with cluster knowlegde/system administrator would be advisable.
Unknown said…
As a follow-up to the question of if the SSO master secret can be moved from the BizTalk servers to a SQL Server Cluster, is it possible to maintain the same master secret key or do you have to generate a new key? If you have to generate a new key, would we lose the ability to decrypt data currently in SSO?
You do not need to generate a new SSO Key. You do need to move backup file to cluster and might do a ssoconfig -restoresecret BackupFile.
Anonymous said…
Hi -

Is this SSO clusetring on SQL the instructions for BizTalk 2006R2 or BizTalk 2009? I read in the BizTalk 2009 docs from MSDN that of you are clustering BizTalk 2009 SSO on a Windows 2003 Cluster - you use the BT2006R2 Install & Config for SSO, and if on a Win2008Cluster, use BT2009 install & config. I saw these both in MSDN and TechNet. Is this correct or a misprint?

Thanks -
Anonymous said…
Hi Steef-Jan Wiggers,

Is this SSO clusetring on SQL the instructions for BizTalk 2006R2 or BizTalk 2009? I read in the BizTalk 2009 docs from MSDN that of you are clustering BizTalk 2009 SSO on a Windows 2003 Cluster - you use the BT2006R2 Install & Config for SSO, and if on a Win2008Cluster, use BT2009 install & config. I saw these both in MSDN and TechNet. Is this correct or a misprint?

Thanks -
Anonymous said…
Hi -

Is this SSO clusetring on SQL the instructions for BizTalk 2006R2 or BizTalk 2009? I read in the BizTalk 2009 docs from MSDN that of you are clustering BizTalk 2009 SSO on a Windows 2003 Cluster - you use the BT2006R2 Install & Config for SSO, and if on a Win2008Cluster, use BT2009 install & config. I saw these both in MSDN and TechNet. Is this correct or a misprint?

Thanks -
These are instructions on SSO Clustering on 2003 Windows Environment with BizTalk Server 2006 R2.
Anonymous said…
Steef,

I have 2 machine envt. Machine A has Biztalk and Machine B has SQL server. What steps should I take on each machine to configure SSO?

Thanks for your help
Anonymous said…
First of all, let me apologize if this has been answered already, and if I could be pointed to the appropriate link I would greatly appreciate it. My searches have yet to find the answer to my question.

We currently have one BizTalk 2009 host and one SQL Server (Master Secret server) in a small domain with two domain controllers. All of these are virtual machines (running on a Hyper-V Failover Cluster) because they are part of a pilot project.

Now we want to expand that project to a larger scale, and the intention is to stand up two new physical blades for SQL servers in an Active/Passive Failover Cluster and stand up two new virtual BizTalk hosts in an NLB cluster (all in the same small domain as the pilot). The new SQL cluster would hold the Master Secret for the production portion of this project and the new VMs would host the production BizTalk for the project. After these production systems have been verified and the BizTalk applications migrated, the single virtual BizTalk host and single virtual SQL server that made up the pilot BizTalk environment would be retired. This would mean that we would have one Master Secret Server for the pilot while having a new, different, Master Secret Server for the production installation, running at the same time.

My question is this: Can I install a second Master Secret Server in this same domain (to be used for the production installation) without interrupting service to the pilot environment?
Anonymous said…
Hi, Is it possible to have two clustered entsso instances running in same sql server cluster? I need to have two SQL virtual instances in active/active config, each hosting biztalk databases. One instance is for Biztalk test environment and the other for uat. How will I setup entsso as both Biztalk env require entsso? Can I add entsso resource to both of my sql server cluster groups? Thanks
I think the best option is to have the cluster resource for SSO on SQL Cluster.
Anonymous said…
Took me time to read all the comments, but I really enjoyed the article. It proved to be Very helpful to me and I am sure to all the commenters here! Its always nice when you can not only be informed, but also entertained! Im sure you had fun writing this article.
Valuable information and excellent design you got here! I would like to thank you for sharing your thoughts and time into the stuff you post!!

http://www.sqlservermasters.com/

Popular posts from this blog

DTAP Strategy: Pricing and Licensing

Table Operation on Oracle 11g XE with OracleDbBinding

Integration, the community blasting into 2017!