BizTalk has a key dependency on Enterprise Single Sign-On (ESSO), because there are two uses of ESSO. First, ESSO is used to securely store send port and receive location configuration information for BizTalk. Because the information contained in the configuration of these items (URLs, file drop locations, etc.) is often confidential, it needs to be stored safely and securely. This means that the BizTalk service requires access to the ESSO service in order to be able to access this configuration information and, hence, send and receive messages. Therefore, it is essential to ensure ESSO is always available. The other use is to store encrypted user credentials, which can then be transmitted to various systems. A key problem within many enterprise organizations is cross-platform security, system integration, and management. For example, when Line-of-Business (LOB) applications and other systems require separate logons users must keep track of, and use, multiple credentials. For many IT support teams the most common support incidents are password resets. This situation reduces end-user productivity while significantly increasing help desk expenses. If a user community mishandles IBM mainframe or AS/400 midrange logon credentials this can represent an increased security risk and compromise access to vital enterprise computing resources. Enterprise SSO is provided by a set of processes that run on network servers to provide the following services for heterogeneous systems:

• User account and password mapping and caching
• Single Sign-on to multiple Windows domains and Host security systems
• Password Synchronization to simplify administration

Enterprise SSO offers administrators a means to efficiently map accounts across Windows Active Directory and Host systems or LOB applications. This includes supporting 1:1 and group:1 associations. These mappings are stored securely in a centralized Credential Database (SSODB) using SQL Server. Based on a secure end-to-end architecture, BizTalk Server can call into SSO to obtain foreign credentials and access resources on these Host systems or LOB applications with the appropriate credentials. The Master Secret Server ESSO uses the SSODB database to store all encrypted credentials. Information is encrypted and decrypted from this database using a key called the master secret key. The first BizTalk Server that is installed in your group will have an ESSO service installed, referred to as the master secret server because the master secret key is stored in the registry on this box. On each additional BizTalk Server that is installed in the group, an ESSO service will be present, which has to start up successfully and without errors for BizTalk to start. For each of these instances of ESSO to start, they require access to the master secret server ESSO instance so that the key can be cached by the service. Access to the master secret server is now not required until the service is restarted. If the master secret server fails, when the other ESSO services restarted, they would no longer be able to access the master secret server and cache a copy of the key. Therefore, they would not be able to access information in the SSODB database and the service would not start correctly. This, in turn, would prevent BizTalk from starting correctly. To resolve this, you would need to recreate the SSODB database, which would require you to reconfigure the full BizTalk group — typically, a lengthy process and one that you want to avoid! Therefore, it is critical that you back up your master secret key and know how to restore it. Clustering Options for the Master Secret Server Because the master secret server is a single point of failure in your BizTalk group, it should be made highly available. This can be done using Windows clustering. The master secret server must be part of an active-passive cluster configuration. It can either be installed on its own server cluster or as part of one of your existing clusters. Given that the master secret server does not consume many resources, most customers opt to install it on the database cluster that the BizTalk databases use. This avoids the somewhat prohibitive costs of purchasing the additional resources required for an additional cluster but provides a highly available solution. Please note that if you do cluster the master secret server using the BizTalk database cluster, it is recommended that it is contained in its own cluster group so that if it fails over it does not affect other clustered services such as SQL Server. Related Links: http://social.technet.microsoft.com/wiki/contents/articles/12888.biztalk-server-enterprise-single-sign-on-service.aspx http://social.technet.microsoft.com/wiki/contents/articles/6904.biztalk-server-2010-enterprise-sso-survival-guide.aspx http://blogs.msdn.com/b/biztalknotes/archive/2013/07/30/moving-the-entsso-service-to-a-new-cluster-in-an-existing-biztalk-server-environment.aspx http://blogs.msdn.com/b/richardbpi/archive/2005/07/19/440645.aspx