Enterprise Single Sign-On Security Recommendations

With the Enterprise Single Sign-On (SSO) system, users can connect to different systems by using only one set of credentials. BizTalk Server leverages the SSO system as a store for sensitive information. Although BizTalk automatically installs whenever you install the BizTalk Server runtime, you can also install Enterprise Single Sign-On as a stand-alone component, independent of your BizTalk Server environment. For more information about Enterprise Single Sign-On, see Using Enterprise Single Sign-On. It is recommended you follow these guidelines for securing and deploying the Enterprise Single Sign-On (SSO) services and resources in your environment.

General deployment recommendations for SSO

• There must be only one master secret server and only one Credential database in the entire environment, even if you have multiple BizTalk groups in your environment. You must configure these two servers before you configure any other BizTalk and SSO servers.
• You must have a time server in your environment to ensure all SSO servers are synchronized. If the clocks on the SSO servers are not synchronized, this could compromise the security of your environment.
• Considering there is only one master secret server in your entire environment, it is recommended to use an active-passive cluster configuration for the master secret server. For more information about clustering the master secret server, see Clustering the Master Secret Server.
• The master secret server holds the encryption key the SSO systems uses to encrypt the information in the Credential database. It is recommended that you do not install or configure any other products or services on this computer.

  Note  The computer where you install and configure the master secret server does not have to be a server.

• The master secret server should have access to a removable media or NTFS file system folder in order to back up and restore the master secret. If you use removable media, ensure you take appropriate measures to protect the removable media. If you back up the master secret to an NTFS file system, ensure you protect the file and the folder. Only the SSO Administrator should have access to this file.
• You should back up the master secret as soon as the master secret server generates it. This is so that you may recover the data in the Credential database in the event the master secret server fails. For more information about backing up the master secret, see Managing the Master Secret.
• Back up your current secret, or generate a new secret on a regular basis, for example, once a month. Without the secret, you cannot retrieve information from the Credential database. For more information about backing up and restoring the master secret, see Managing the Master Secret.

Security Recommendations for SSO Groups and Accounts

• It is recommended to use Windows groups, and not single user accounts, especially for the SSO Administrator and SSO Affiliate administrator groups. These groups must have at least two user accounts as members of the group at all times.
• The SSO runtime service accounts and the SSO administrator user accounts should be different accounts, even when they are members of the same SSO Administrators group. The SSO administrator users performing administrative tasks such as generating and backing up the secret need to be Windows administrators, while the SSO runtime service accounts do not need to be Windows administrators.

   Security  Windows administrator user rights do not supersede the user rights of the SSO administrator. To perform any SSO administration-level task you must be a member of SSO administrators group even if you already are a Windows administrator.

• If you use the SSO ticketing feature, you must use domain accounts that the computers in the processing domain (domain where the SSO servers are) recognize.
• It is recommended to use a unique service account for the SSO service corresponding to the master secret server.
• The SSO administrator account is a highly privileged account in the SSO system, which also is SQL Server administrator for SQL Server that has the Credential database. You should have dedicated accounts for SSO administrators, and should not use these accounts for any other purposes. You should limit the membership to the SSO administrators group only to those accounts responsible for running and maintaining the SSO system.
• You must manually add the BizTalk administrators group to the SSO Affiliate Administrators group so that the BizTalk administrators can leverage the SSO system to save the configuration information for the adapters in the Credential database. Only the BizTalk administrators managing adapters need to be members of the SSO Affiliate Administrators group. BizTalk administrators do not need to be SSO administrators.

Security Recommendations for an SSO Deployment

• If your network supports Kerberos authentication, you should register all SSO servers. When you use Kerberos authentication between the master secret server and the Credential database, you must configure Service Principal Names (SPN) on the SQL Server where the Credential database is located. For more information about configuring Service Principal Names, see Microsoft Download Web site at http://go.microsoft.com/fwlink/?LinkId=20797.
• When running Microsoft Windows Server™ 2003, if the master secret server is on a different domain from the other SSO servers and from the Credential database, you must disable RPC security (as used for Data Transaction Coordinator (DTC) authentication between computers) on the master secret server, on the SSO servers (processing computers in the processing domain), and on the Credential database. RPC security is a new DTC feature in Windows Server 2003. When you disable RPC security, the DTC authentication security level for RPC calls goes back to one available in Microsoft Windows® 2000 Server. For more information about disabling RPC security, see the Microsoft Help and Support Web site at http://go.microsoft.com/fwlink/?LinkId=24774.
• SSO administrators should regularly monitor the event log in the master secret server and the SSO server for SSO auditing events.
• In addition to firewalls, it is recommended to use Internet Protocol security (IPSec) or Secure Sockets Layer (SSL) between all the SSO servers and the Credential database. For more information about SSL, see Microsoft Help and Support Web site at http://go.microsoft.com/fwlink/?LinkId=16731. For more information about using SSL between all the SSO servers and the Credential database, see Enabling SSL for Enterprise Single Sign-On.

See Also

Enterprise Single Sign-On Security

Ports for the Enterprise Single Sign-On Servers

Minimum Security User Rights

Security Recommendations for BizTalk Server Components