Security Considerations when Using Single Sign-On

The Microsoft Single Sign-On service (SSOSrv) uses the following types of accounts: configuration account, single sign-on administrator account, single sign-on service account, and the enterprise application manager account. For information about the rights required by each of these accounts, see Specifying Settings for Single Sign-On and Application Definitions.

Security Recommendations Regarding the Topology of the Server Farm

When using the single sign-on service, you can help enhance security by distributing your resources in the server farm. Specifically, the configuration of the front-end Web server, the job server, and the computer storing the single sign-on database can affect security.

• Less secure configuration   Everything is deployed on one server. This configuration is less secure because the front-end Web server, the single sign-on database stored in Microsoft SQL Server, and the encryption key are on the same computer.

  Note  This configuration is not recommended.

• More secure configuration   Two-computer configuration where one computer is the front-end Web server. The second computer is the job server containing the single sign-on database stored in SQL Server and the encryption key.
• Recommended configuration for better security   Configuration of three or more computers in which the front-end Web server, the job server containing the encryption key, and the server containing the single sign-on database stored in SQL Server are different computers.

If you are using single sign-on in a shared services scenario, the user credentials stored in the parent server farm are available to the administrators of all child server farms. It is recommended that you run applications using single sign-on on the parent portal site only and use an iFrame in the application for child portal sites. You should disable the single sign-on service on child server farms.

Security Recommendations for Storing the Backup Copy of the Encryption Key

You should store the backup disk for the encryption key in a safe place.

The encryption key is used as part of the encryption process for each of the credentials. Since it is the key that decrypts the encrypted credentials stored in the database, the backup copy of the key should not be stored with the backup copy of the database.

Note  If a user obtains a copy of both the database and the key, the user names and passwords may be compromised.

Enabling Auditing for the Encryption Key

You should enable auditing for the encryption key. Then, if the key is read or written to, there will be an audit trail in the security log in Microsoft Windows Server 2003 Event Viewer.

Enable auditing for the encryption key

1. Modify the registry by doing the following:

   Caution  Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

   1. On the taskbar, click Start, and then click Run.
   2. Type regedit and then click OK.
   3. In Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ssosrv\Config.
   4. Right-click Config, and then click Permissions.
   5. In the Permissions for Config dialog box, click Advanced.
   6. In the Advanced Security Settings for Config dialog box, click the Auditing tab, and then click Add.
   7. In the Select User, Computer, or Group dialog box, in the Enter the object name to select box, type everyone
   8. Click OK.
   9. In the Auditing Entry for Config dialog box, in the Failed column, select the Full Control check box, and then click OK.
   10. Click OK, and then click OK again to close all dialog boxes.
   11. Close Registry Editor.
2. Enable auditing by doing the following:
   1. On the taskbar, click Start, and then click Run.
   2. Type mmc and then click OK.
   3. In the console, on the File menu, click Add/Remove Snap-in.
   4. In the Add/Remove Snap-in dialog box, on the Standalone tab, click Add.
   5. In the Add Standalone Snap-in dialog box, in the Available Standalone Snap-ins list, click Group Policy Object Editor, and then click Add.
   6. In the Select Group Policy Object dialog box, ensure that Local Computer appears in the Group Policy Object box, and then click Finish.
   7. In the Add Standalone Snap-in dialog box, click Close.
   8. In the Add/Remove Snap-in dialog box, click OK.
   9. Expand the following nodes:
      • Local Computer Policy
      • Computer Configuration
      • Windows Settings
      • Security Settings
      • Local Policies
      • Audit Policy
   10. In the details pane, double-click Audit object access.
   11. In the Audit object access Properties dialog box, select the Failure check box, and then click OK.

You can verify that auditing is working by doing the following:

1. Log off.
2. Log on as a user who should not have access to the registry key.
3. Try to read the registry key.
4. Look in the security log in Windows Server 2003 Event Viewer for audit entries.