Plan for single sign-on
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.
.gif "Single sign-on service in a server farm")
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.
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.
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.
|
|---|
|
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 |
|
SSO administrator account |
|
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 |
|
SSO administrator account |
|
SSO service account |
|
Enterprise application administrator account |
|
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:
|
SSO service account |
Server farm account |
|
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.
.gif "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
Back up the encryption key.
Disable the Single Sign-On service on all computers in the farm.
Log on to the new encryption-key server, which is the index server in this example.
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.
Start the Single Sign-On service.
To access Central Administration on this server, browse to the index server.
Configure SSO farm-level settings in the Central Administration site. Specify the existing SSO database.
Restore the encryption key.
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
Back up the encryption key.
On all server computers in the farm that are running the Single Sign-On service, reconfigure the service with the new service account.
Reconfigure SSO farm-level settings in the Central Administration site with the new SSO service account. Specify the existing SSO database.
Restore the encryption key.
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
Restore the SSO database to the intended database server computer.
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.
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
Regenerate the encryption key.
Reencrypt the credentials in the SSO database (the new encryption key is used).
Change passwords for enterprise applications if the passwords might be compromised.
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
Restore the SSO environment to an isolated server computer.
Regenerate the encryption key.
Reencrypt the credentials in the SSO database.
Back up the SSO environment.
Restore the SSO environment to the existing Office SharePoint Server 2007 server farm.
Worksheets
Use the following worksheets to plan for single sign-on:
Single sign-on enterprise application definition worksheet (https://go.microsoft.com/fwlink/?LinkId=798133&clcid=0x409)
Single sign-on server farm settings worksheet (https://go.microsoft.com/fwlink/?LinkId=798133&clcid=0x409)
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.