Udostępnij za pośrednictwem

Plan for single sign-on

  • Artykuł

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

In this article:

  • About single sign-on

  • Common SSO scenarios

  • Office SharePoint Server SSO architecture

  • Plan farm-level SSO settings

  • Plan enterprise application definition settings

  • Plan for SSO operations

  • Worksheets

Use this article to plan for using single sign-on (SSO) in Microsoft Office SharePoint Server 2007. This article describes how SSO is configured in a secure environment, including how to use SSO to connect to back-end data systems.

About single sign-on

The SSO feature in Office SharePoint Server 2007 maps user credentials to back-end data systems. Using SSO, you can access data from server computers and services that are external to Office SharePoint Server 2007. From within Office SharePoint Server 2007 Web Parts, you can view, create, and change this data. The SSO feature ensures that:

  • User credentials are managed securely.

  • User permission levels that are configured on the external data source are enforced.

  • Users are not prompted to reenter their credentials when viewing data from external data sources within Office SharePoint Server 2007.

  • Office SharePoint Server 2007 can connect to multiple external data systems regardless of the platform and authentication requirements.

SSO requires the use of Windows credentials for user accounts. In environments where Web SSO is used to authenticate user accounts, SSO can be used only if the current thread that is invoking SSO application programming interfaces (APIs) has a Windows identity associated with it.

Common SSO scenarios

SSO is primarily used for business intelligence scenarios. In Office SharePoint Server 2007, many features depend on SSO, including the following:

  • Business Data Catalog

  • Excel Services

  • InfoPath Forms Services

  • Business Data Web Parts

  • KPI Web Part

  • Microsoft Office SharePoint Designer Data Form Web Part

  • Business data search

  • Business data in lists

Additionally, you can introduce custom Web Parts that connect to external data sources including those that are based on operating systems other than Windows. For example, you can connect to the following enterprise applications:

  • SAP Business Information Warehouse

  • Siebel eBusiness Applications

  • Microsoft BizTalk Server

For more information about business intelligence scenarios, see Plan for business intelligence.

Office SharePoint Server SSO architecture

This section describes how SSO is implemented in Office SharePoint Server 2007.

Microsoft Single Sign-On service

The SSO feature in Office SharePoint Server 2007 uses the Microsoft Single Sign-On service (SSOSrv). The following figure shows how the Single Sign-On service is implemented in an Office SharePoint Server 2007 server farm.

Single sign-on service in a server farm

  1. SSO encryption-key server   The first server computer on which the Single Sign-On service is enabled becomes the encryption-key server. The encryption-key server generates and stores the encryption key. The encryption key is used to encrypt and decrypt the credentials that are stored in the SSO database. The encryption-key server should be an application server computer, such as the index server.

  2. Single Sign-On service   This service must be installed on all Web server computers in the server farm. Additionally, the service must be installed on any computers that are hosting the Excel Services application server role. If a Business Data Catalog search is used, the service must be installed on the index server as well.

  3. SSO database   When you configure SSO server settings in the Central Administration site, Office SharePoint Server 2007 creates an SSO database on the database server computer that hosts the configuration database. If Microsoft SQL Server is installed, the SSO database is a SQL Server database. If SQL Server is not installed, the Single Sign-On service uses SQL Server 2005 Express Edition. The SSO database stores the encrypted credentials.

    Note

    If you are upgrading from a previous version of SharePoint Portal Server, you must re-create your SSO environment, including creating a new SSO database. SSO cannot be migrated or upgraded to Office SharePoint Server 2007.

Enterprise application definitions

In an SSO environment, the back-end external data sources and systems are referred to as enterprise applications. After the SSO environment is configured, you can create enterprise application definitions. For each enterprise application that Office SharePoint Server 2007 connects to, there is a corresponding enterprise application definition configured by an administrator. Or, several enterprise application definitions can be configured for the same physical enterprise application to secure different groups who have access.

An enterprise application definition defines:

  • The enterprise application identity (display name, programmatic name, and contact e-mail address).

  • The type of user accounts that are mapped to the enterprise applications. This depends on whether the enterprise application (or in some cases, the Web Part) enforces permissions based on individual accounts or group accounts.

  • The type of credentials that are collected from users (user name, password, or other credentials, such as a smart card).

  • The account used by Office SharePoint Server 2007 Web Parts to connect to the enterprise application.

The single sign-on functionality enables scenarios where multiple Web Parts access different enterprise applications. The different enterprise applications can each use a different type of authentication. The enterprise applications can also be based on operating systems other than Windows.

SSO tickets

In an enterprise environment where a user interacts with various systems and applications, it is very likely that the environment does not maintain the user context through multiple processes, products, and computers. This user context is crucial to provide single sign-on capabilities, because it is necessary to verify who initiated the original request. In scenarios where multiple servers participate in passing credentials from the encryption-key server to the enterprise application, the Single Sign-On service provides an SSO ticket (not a Kerberos ticket). These servers use this ticket to get the credentials that correspond to the user who made the original request.

For example, a payroll environment might be configured to access data in a SAP system through BizTalk Server. If a Web Part is connecting to the SAP system, credentials are routed through the BizTalk Server computer. In an SSO environment, a Web Part sends an SSO ticket to the service on the BizTalk Server computer that connects to the SAP system. If the user belongs to an account or group account that is specified in the enterprise application definition, the service redeems the SSO ticket for credentials to the SAP system. In order for the service on the BizTalk Server computer to redeem SSO tickets, the account that is used by the service must be added to the SSO Administrators group.

The Single Sign-On service issues a ticket when a Windows user requests a ticket or when an application requests a ticket on behalf of a user. The Single Sign-On service can only issue a ticket for the user who makes the request (you cannot request a ticket for other users). A ticket contains the encrypted domain and user name of the current user, and the ticket expiration time.

After an enterprise application verifies the identity of the original requestor, the application redeems the ticket to obtain the credentials of the user who initiated the request. Tickets expire in two minutes by default. SSO administrators can modify the expiration time for tickets. The ticket time-out value must be long enough to last between the time the ticket is issued and the time that it is redeemed.

SSO administration

Administering SSO involves two types of administrators:

  • SSO administrators   These administrators set up and configure SSO, manage SSO accounts, back up the encryption key, and create and change the encryption key. For security reasons, SSO administrators are required to log on to the encryption-key server locally to set up, configure, and manage SSO. SSO administrators are prevented from managing SSO server settings from a remote server computer.

  • Enterprise application definition administrators   These administrators create and manage enterprise application definitions, and update accounts and credentials used to access enterprise applications. These administrators can manage enterprise application definitions remotely.

Specific accounts and permissions for SSO administrators are detailed later in this article.

Networking dependencies

Within an Office SharePoint Server 2007 server farm, the Single Sign-On service relies on NetBIOS names to communicate between the encryption-key server and the database server computer. If NetBIOS name resolution is not available for the database server computer, SSO configuration will fail.

Plan farm-level SSO settings

This section describes planning choices for farm-level settings. These planning choices include:

  • Deciding which server computer will host the SSO encryption-key server role.

  • Setting up SSO accounts and ensuring that these accounts are created with the appropriate permissions.

  • Recording decisions for farm-level settings that are configured on the Manage Server Settings for Single Sign-On page in Central Administration.

  • Worksheet action

SSO encryption-key server

Determine which computer in your farm will host the SSO encryption-key server role. The recommended configuration is to select an application server computer, such as the index server, for the following reasons:

  • All server computers that run the Single Sign-On service must be able to communicate over the network with the encryption-key server. When using a farm with multiple Web server computers, some load-balancing technologies do not allow the Web servers to communicate with each other.

  • Application server computers are not directly accessed by end-users and are typically protected by additional layers of security. For example, security protocols such as IPsec or SSL are often implemented to secure server-to-server communication within a server farm. Additionally, some farm topologies implement an additional router or firewall between Web server computers and application server computers.

The Single Sign-On service must be installed on any application server computers that host the Excel Services role. If a Business Data Catalog search is used, the Single Sign-On service must be installed on the index server as well. These requirements make each of these server computers a good choice for the encryption-key server role.

Ensure that SSO administrators can log on locally to the encryption-key server. Additionally, be sure that security settings in Internet Explorer do not prevent administration of SSO by ensuring the following:

  • The default option, Automatic logon only in Intranet zone, is selected. (To do this, on the Tools menu, click Internet Options, click the Security tab, click the Custom Level button, and then in the Security Settings dialog box, go to the User Authentication section.)

  • Prompt for user name and password is not selected.

SSO accounts

There are four different accounts that are required to set up, run, and administer the SSO system:

  • SSO configuration account

  • SSO administrator account

  • SSO service account

  • Enterprise application administrator account

In an evaluation environment, you can use the server farm account for each of these accounts. However, in a secure environment, you should put some thought into which accounts you use and how you configure these accounts. This section details the account requirements and provides recommendations for configuring these accounts in a secure environment.

The four accounts that are required to set up, run, and administer the SSO system provide separation of roles and isolation of permissions. The following tables list the accounts and describe the actions that are performed using these accounts.

Account Description

SSO configuration account

  • Set up the Single Sign-On service in Office SharePoint Server 2007.

  • Configure and manage the Single Sign-On service in Office SharePoint Server 2007, including managing the encryption key.

  • Create, modify, or delete enterprise application definitions within Office SharePoint Server 2007.

SSO administrator account

  • Configure and manage the Single Sign-On service in Office SharePoint Server 2007, including managing the encryption key.

  • Create, modify, or delete enterprise application definitions within Office SharePoint Server 2007.

    Redeem SSO tickets. In scenarios where credentials pass through an intermediary service (such as BizTalk Server) before reaching the enterprise application definition, this account is used to give intermediary services permissions to redeem SSO tickets.

SSO service account

Run the Single Sign-On service in Windows.

Enterprise application administrator account

Create, modify, or delete enterprise application definitions within Office SharePoint Server 2007.
Account Requirements

SSO configuration account

  • Must be a user domain account. Cannot be a group account.

  • The user account must be a server farm administrator.

  • Must be a member of the Administrators group on the encryption-key server computer.

  • Must be a member of the following SQL Server security roles on the computer running SQL Server:

    • Dbcreator

    • Securityadmin

  • Must be either the same as the SSO administrator account, or be a member of the group account that is the SSO administrator account.

SSO administrator account

  • Must be either a Windows global group or an individual user account. Cannot be a domain local group account or a distribution list.

  • The SSO service account must be this user or a member of this group.

  • The SSO configuration account must be this user or a member of this group.

  • Must be added to the SharePoint Central Administration site with the Read permission level.

  • All users that are added to this group for the purpose of administering SSO must be members of the Administrators group on the encryption-key server. Do not make this account itself a member of the Administrators group on the encryption-key server.

SSO service account

  • Must be a domain user account. Cannot be a group account.

  • Must be the SSO administrator account or a member of the group account that is the SSO administrator account.

  • Must be member of the local group WSS_Admin_WPG on all server computers running Office SharePoint Server 2007 in the server farm.

  • Must be member of the public database role on the Office SharePoint Server 2007 configuration database.

  • Must be member of the Sysadmin server role on the SQL Server instance where the SSO database is located.

  • In a secure environment, do not run the service under an account that is a member of the Administrators group on the local computer.

    Note

    To change the service account, you must first back up the master key, and then restore the master key after the service account is changed.

Enterprise application administrator account

  • Must be global group account or individual user account. This account cannot be a domain local group or a distribution list.

  • Must have the Read permission level on the SharePoint Central Administration site.

In a secure environment, the recommendation is to configure four distinct accounts and to use a group account, where possible. If you are using a user account for the SSO configuration account, SSO administrator account, and the SSO service account, you must use the same user account. The following table provides recommendations for configuring these accounts.

Account Evaluation environment Secure environment

SSO configuration account

Server farm account

Use the individual user account of an administrator who is a member of the Farm Administrators group.

SSO administrator account

Server farm account

Create a dedicated domain group account. Add the following to this group:

  • User account that will be used as the SSO configuration account.

  • Account used to run the Single Sign-On service

  • Users that are allowed to administer the Single Sign-On service in Office SharePoint Server 2007. Also add these users to the Administrators group on the encryption-key server.

    Service accounts of services that redeem SSO tickets. These are intermediary services that pass credentials between the encryption-key server and the enterprise application.

SSO service account

Server farm account

  • Use an individual user account. Use a different account than the SSO configuration account.

  • Do not add this account to the Farm Administrators group or to the Administrators group on the local computer.

    Do not use the same service account that is used to run Internet Information Services (IIS) application pools.

Enterprise application administrator account

Server farm account

Create a dedicated domain group account. Add to this group users that are allowed to create and manage enterprise application definitions.

The following figure shows the recommended secure configuration for these accounts.

Recommendations for configuring SSO accounts

Database settings

Database settings are used to create the SSO database and include:

  • Server name   This is the NetBIOS name of the database server computer. Do not enter the fully qualified domain name (FQDN).

  • Database name   This is the name of the SSO database.

Unless you are creating databases beforehand, the recommendation is to keep the default settings.

Time-out settings

Time-out settings include the following:

  • Ticket time out (in minutes)   Use to set the number of minutes that can elapse before an SSO ticket expires. Ensure that the ticket time-out value is long enough to last between the time when the ticket is issued and the time that it is redeemed by the enterprise application. Two minutes is the recommended setting that allows ample time for tickets to be redeemed. If tickets are not redeemed within two minutes, networking or other issues might be preventing a connection between computers.

  • Delete audit log records older than   Use to set the number of days to hold records in the audit log before deleting.

The default time-out settings are the recommended starting points.

Plan enterprise application definition settings

This section describes planning choices for enterprise application definitions.

Worksheet action

Use the Single sign-on enterprise application definition worksheet (https://go.microsoft.com/fwlink/?LinkId=798133&clcid=0x409) to record your planning choices. Complete this worksheet for each enterprise application definition that you plan to add.

After you create an enterprise application definition, you cannot modify the following properties:

  • Name of the enterprise application definition

  • Account type (group or individual, Windows authenticated group or individual, or group that uses restricted account)

  • Logon account information fields

Application and contact information

Application and contact information includes the following settings:

  • Display name   The friendly name for the enterprise application.

  • Application name   The programmatic name for the enterprise application. This is the name that Web Parts will use to call the enterprise application definition.

  • Contact e-mail address   The e-mail address that users can contact for the enterprise application.

Account type

Account type refers to the type of account that is used to map user credentials to the enterprise application: either an individual account or a group account. If each user has an account in the enterprise application, choose Individual. If the enterprise application uses one account for all users, choose Group.

Be aware that security authorization can be performed by either the enterprise application or by the Web Part that is connecting to the enterprise application. How security authorization is set up affects which type of account is used by the enterprise application. For example, authorization to access personal data in a pay stub application can be set up by using one of two methods:

  • Users have their own accounts in the pay stub system to access their pay stub. In this case, individual accounts are used by the enterprise application.

  • The Web Part that is used to access pay stub data enforces security authorization. In this case, the Web Part performs user authorization based on user credentials and the pay stub system uses a group account for all users. Consequently, the enterprise application definition for this scenario uses a group account.

Additionally, if a group account is used, the enterprise application definition can be configured to use a privileged account. If you choose a privileged account, credentials are stored separately from regular credentials and a different API is used to access privileged credentials. Privileged accounts are used in scenarios where an intermediary application, such as Business Data Catalog, imposes further security trimming on the data that is retrieved based on the credentials.

Applications that use restricted credentials must perform further authorization and data trimming based on the data that is returned by using the privileged credentials. Farm administrators must ensure that all applications that use privileged accounts perform this authorization and data trimming uniformly. Otherwise, if an application that does not perform this additional authorization and trimming has access to privileged accounts, the application can compromise security by using privileged credentials to access data that would otherwise be trimmed.

Choose Group using privileged account only under the following circumstances:

  • The account is a group account.

  • Business Data Catalog is used to connect to the enterprise application.

  • The intermediary application that connects to the enterprise application complies with the terms of using a privileged account.

  • Data is highly sensitive.

Authentication type

Authentication type refers to the method in which the Office SharePoint Server 2007 server connects to the enterprise application: Windows authentication or no authentication. This authentication applies only to the credentials that the server running Office SharePoint Server 2007 uses to log on to the enterprise application. Authentication of user credentials is not affected.

If the enterprise application is hosted on a computer running Windows, select Windows authentication. If the enterprise application is hosted on a computer that is not running Windows, leave this setting blank. If Windows authentication is not used, logon credentials are not encrypted. If you select Windows authentication and the enterprise application system does not support Windows authentication, the SSO connection will fail.

Logon account information for users

The fields provided for logon account information determine which pieces of information are required to log on. By default, only the user name and password are specified. You can specify up to five different pieces of information that must be included. For example, you can require an SAP server name or an SAP client number. Users are prompted to enter credentials under the following circumstances:

  • Authentication fails or credentials are not found.

  • The Web Part is programmed to prompt users for credentials.

Logon account information is used for enterprise application definitions that use individual accounts. Prompting for logon account information is not recommended for enterprise application definitions that use group accounts.

The logon account information that you configure here must match the logon requirements for the enterprise application. Additionally, you must also determine whether the system needs to mask these credentials as the user provides them.

Typically, only a user name and password are required. Some highly secure environments might require additional pieces of user identification. Additionally, some systems might require additional information from users to identify the application. For example, for access to Oracle, users might enter the information shown in the following table.

In this field Enter this information

Field 1

Oracle user name

Field 2

Oracle user password (select Yes for the Mask option)

Field 3

Oracle database name

To access the SAP application, users might enter the information shown in the following table.

In this field Enter this information

Field 1

SAP user name

Field 2

SAP password (select Yes for the Mask option)

Field 3

SAP system number

Field 4

SAP client number

Field 5

language

Account information for enterprise application

If you are using a group account to connect to the enterprise application, you need to provide the account credentials. After adding an enterprise application definition, an SSO administrator or a member of the enterprise application administrator account specifies the account name and password used to connect to the external server computer by clicking Manage Account Information for an Enterprise Application Definition in the Central Administration site.

Worksheet action

Use the Single sign-on enterprise application definition worksheet (https://go.microsoft.com/fwlink/?LinkId=798133&clcid=0x409) to record the name of the group account.

The administrator who enters the account information in the Central Administration site must also know the password for the group account.

If you are using individual accounts to connect to the enterprise application, you do not need to enter account information into the Central Administration site.

Plan for SSO operations

Managing the encryption key

The encryption key is used as part of the encryption process for credentials used with SSO. The key helps to decrypt encrypted credentials stored in the SSO database. The first time you configure SSO and enterprise application definitions on the Manage Server Settings for Single Sign-On page in Central Administration, the encryption key is created automatically. Managing the encryption key includes auditing the encryption key and regenerating the encryption key.

Auditing the encryption key

You can enable auditing of changes that are made to the encryption key. If the key is read or written to, a security event is logged in the security log. You can view the security log by using Event Viewer. Enabling logging involves:

  • Modifying an SSO registry key.

  • Creating a local computer policy in Group Policy Object Editor.

Regenerating the encryption key

Because the encryption key protects security credentials, you should regenerate the key on a regular schedule, such as every 90 days. You should also regenerate the encryption key if account credentials are compromised.

The reencryption process is a long-running operation. It is recommended that you change the encryption key during non-peak periods. Reencrypting the encryption key has the following impact on the SSO environment:

  • During the reencryption process, write operations such as updating credentials and changing enterprise application definitions are not allowed.

  • Read operations such as retrieving credentials continue to work as normal.

You must be logged on to the encryption-key server locally to reencrypt the encrypting key. You must also be a member of the SSO administrator account.

If the encryption-key server is restarted or the Single Sign-On service is stopped on the encryption-key server during the reencryption process, you should look in the event log for errors. If the event log reports an error, you must restart the reencryption process. If the reencryption process is preempted in any way, it will have to be rerun. If the reencryption process is preempted, it reverts back to its original state.

When you create an encryption key, you can choose to reencrypt the existing credentials with the new key. If you do not reencrypt the existing credentials with the new encryption key, users must retype their credentials for individual enterprise application definitions, and administrators for group enterprise application definitions must retype group credentials.

When you reencrypt the Single Sign-On service credential store, events are logged in the Microsoft Windows Server 2003 application event log. After reencryption is initiated, you can monitor the application event log to verify that the credential store has been reencrypted. Event ID 1032 is recorded in the application event log when reencryption is started. Event ID 1033 is recorded in the application event log when reencryption has ended. If there are any failures during reencryption, an event is recorded in the log.

When you are deciding your planning choices for managing the encryption key, consider the following:

  • At what interval do you plan to reencrypt the encryption key?

  • Should the existing credentials be reencrypted with the new encryption key at the same time?

  • Under what additional circumstances will the encryption key be reencrypted?

Worksheet action

Use the Single sign-on server farm settings worksheet (https://go.microsoft.com/fwlink/?LinkId=798133&clcid=0x409) to record your planning choices.

Backing up the SSO environment

Backing up the SSO environment involves backing up the following two separate entities:

  • Encryption key

  • SSO database

You should back up the encryption key after initially setting up SSO and then back up the key again each time it is regenerated. There is no need to back up the encryption key at a regular interval unless the interval is tied to regenerating the encryption key. The encryption key cannot be backed up remotely. You must be a member of the SSO administrator account and logged onto the encryption-key server locally to back up the encryption key. The encryption key can only be backed up to a removable storage media. It cannot be backed up to a local hard disk. The encryption key can be backed up from the Manage Encryption Key page in Central Administration.

You should back up the SSO database after it is initially created and then again each time credentials are reencrypted. Additionally, you can include SSO database backups with the regularly scheduled database backups for your server farm. Regularly scheduled backups will include other changes to the SSO database, such as new enterprise application definitions and updated credentials.

Do not store the backup media for the encryption key in the same location as the backup media for the SSO database. If a user obtains a copy of both the database and the key, the credentials stored in the database could be compromised. Ideally, the backup of the encryption key is locked up in a safe place.

When you are deciding your planning choices for backing up the SSO environment, consider the following:

  • Interval to back up the encryption key.

  • Plan for backing up the SSO database. The most efficient plan is to include the SSO database along with your regular farm backups.

Worksheet action

Use the Single sign-on server farm settings worksheet (https://go.microsoft.com/fwlink/?LinkId=798133&clcid=0x409) to record your planning choices.

Restoring the SSO environment

There are several scenarios that require restoring the SSO environment. In some cases, you need to restore only the encryption key or only the SSO database. The following table describes several restore scenarios and indicates what needs to be restored.

Scenario What to restore

Move the encryption-key server role to a different server computer.

Encryption key

Change the SSO service account.

Encryption key

Restore the failed database server computer.

SSO database

Migrate the Office SharePoint Server 2007 farm to a different set of server computers.

Encryption key and SSO database

Recover from a farm-wide disaster.

Encryption key and SSO database

The rest of this section details the specific tasks involved in restoring the SSO environment, depending on the scenario.

To move the encryption-key server role to a different server computer, use the following steps:

Move the encryption-key server role to a different server computer

  1. Back up the encryption key.

  2. Disable the Single Sign-On service on all computers in the farm.

  3. Log on to the new encryption-key server, which is the index server in this example.

  4. Run Psconfig, the command-line equivalent of the Office SharePoint Server 2007 configuration wizard, and configure the index server to host the SharePoint Central Administration Web site.

  5. Start the Single Sign-On service.

  6. To access Central Administration on this server, browse to the index server.

  7. Configure SSO farm-level settings in the Central Administration site. Specify the existing SSO database.

  8. Restore the encryption key.

  9. Start the Single Sign-On service on all Web server computers in the server farm.

Change the SSO service account

The security identifier (SID) of the SSO service account is used as part of the formula for encrypting SSO credentials. Consequently, to change the SSO service account, you must reconfigure the SSO environment. Use the following steps to change the SSO service account:

Change the SSO service account

  1. Back up the encryption key.

  2. On all server computers in the farm that are running the Single Sign-On service, reconfigure the service with the new service account.

  3. Reconfigure SSO farm-level settings in the Central Administration site with the new SSO service account. Specify the existing SSO database.

  4. Restore the encryption key.

  5. Reencrypt the credentials in the SSO database. The restored encryption key is used to reencrypt the credentials.

Restore only the SSO database server

If the server computer that hosts the SSO database fails, you need to restore only the SSO database. Restore the database by using the same method you would use to restore any other databases in the Office SharePoint Server 2007 environment. If you restore the SSO database to a different server computer, reconfigure the SSO farm-level settings with the name of the new database server computer.

Restore the entire SSO environment

There are several scenarios which require restoring both the encryption key and the SSO database. Use the following steps to restore the entire SSO environment:

Restore the entire SSO environment

  1. Restore the SSO database to the intended database server computer.

  2. Set up and configure SSO as if you were configuring a new SSO environment, except enter the server name and database name of the existing SSO database.

  3. Restore the encryption key to the new SSO environment.

Responding to an SSO security compromise

A security compromise can include lost backup media, a password leak, or another event that can potentially compromise either the credentials stored in the SSO database or the data stored in the enterprise applications. If you experience a security compromise that can potentially affect your SSO environment, do the following to respond to the compromise:

Respond to a security compromise

  1. Regenerate the encryption key.

  2. Reencrypt the credentials in the SSO database (the new encryption key is used).

  3. Change passwords for enterprise applications if the passwords might be compromised.

  4. Encourage users to change their passwords if their passwords might be compromised.

If the security compromise is potentially severe, you can stop the Single Sign-On service to immediately halt access to credentials stored in the SSO database. If you need to stop the Single Sign-On service, you can securely restore the service to the existing Office SharePoint Server 2007 server farm by using the following steps:

Restore the Single Sign-On service to the existing server farm

  1. Restore the SSO environment to an isolated server computer.

  2. Regenerate the encryption key.

  3. Reencrypt the credentials in the SSO database.

  4. Back up the SSO environment.

  5. Restore the SSO environment to the existing Office SharePoint Server 2007 server farm.

Worksheets

Use the following worksheets to plan for single sign-on:

Download this book

This topic is included in the following downloadable book for easier reading and printing:

See the full list of available books at Downloadable content for Office SharePoint Server 2007.