Windows™ single sign-on for Web clients across multiple Active Directory domains

If your Windows™ environment includes multiple Active Directory domains, you can set up Windows™ single sign-on for Web clients to function across the domains. There are additional requirements and recommendations for this configuration.

Active Directory trust requirements

About this task

Your Windows™ administrator must set up forest trust relationships between domains using the Active Directory Domains and Trusts snap-in utility. External trust relationships do not support Kerberos authentication and cannot be used. Consult the Microsoft™ documentation for information on setting up trust relationships.

Note that a parent domain implicitly trusts a child domain so that no trust configuration is required between the two. A child domain is a domain that is one level down from another domain in the DNS hierarchy. For example, sales.east.renovations.com is a child of east.renovations.com.

The following types of forest trust are supported:

  • Two-way Windows™ forest trust. For example, if there is a two-way trust between forests A and B, users in forests A and B can access servers in either forest.
  • One-way incoming trust for another forest. For example, if forest A has incoming trust for forest B, users in forest A can access servers in forest B. Users in forest B cannot access forest A unless forest B similarly has incoming trust for forest A.
  • One-way outgoing trust for another forest. For example, if forest A has outgoing trust for forest B, users in forest B can access servers in forest A. Users in forest A cannot access servers in forest B unless forest B similarly has outgoing trust for forest A.
  • Transitive trust. If users in forest A can access servers in forest B due to a trust, the users in a child domain of forest A can access servers in forest B if the trust between forests A and B is configured as a transitive trust.

To determine whether trust relationships have been established for your Active Directory domains:

Procedure

  1. Open the Active Directory Domains and Trust utility from the Administrative Tools menu.
  2. Right-click on your domain and click Properties.
  3. Click the Trust tab to see the trusted domains listed.

Computer clock synchronization

About this task

Server clocks within and across domains must be kept as closely synchronized as possible because Kerberos (the underlying security mechanism for Windows™ single sign-on for Web clients) is sensitive to clock skew. You should correct clock skew whenever possible. If necessary, the Windows™ administrator can perform the following steps to increase the tolerance for clock skew:

Procedure

  1. Launch the Group Policy Management console. (For example, on Windows™ Server 2008, click Start > Run, type gpmc.msc, and click OK.)
  2. In the console tree, find your domain and expand the tree.
  3. Expand the Group policy objects.
  4. Under the Group policy objects, click Default Domain policy (which then appears). On the Default Domain policy Settings tab, click Security settings, Account policies/Kerberos policy.
  5. Double-click Maximum tolerance for computer clock synchronization to edit the setting.

DNS requirements

Given that each domain has a distinct name hierarchy (for example, east.renovations.com and west.renovations.com) your network administrator must configure DNS forward lookup zones and reverse lookup zones that enable computers to resolve names from another domain.

Browser requirements

Browsers must be configured to allow Windows™ single sign-on to each destination Active Directory domain.

Domino® name lookup requirements

Each Domino® server must be able to look up Kerberos names for users located in any Active Directory domain. If users’ Kerberos names are stored in multiple Domino® directories, the Domino® administrator must set up each Domino® server to use a directory catalog or directory assistance to look up the user names in secondary Domino® directories. If users’ Kerberos names are instead being resolved by directory assistance to Active Directory, each Domino® server can use directory assistance to lookup names in each of the Active Directories where users are located.

Single sign-on configuration recommendation

About this task

Once Windows™ single sign-on has been accomplished for a user, the Domino® server returns an LTPA token for the user. You should plan your SSO deployment carefully, considering whether Domino® servers will share the same SSO configuration.

For example, if you set the SSO configuration for servers in domain "east.renovations.com" to share the same SSO keys as the servers for domain "west.renovations.com", then an east server can accept an LTPA token created by a west server. In this case, the SSO configuration documents could use a general DNS domain such as "renovations.com".

However, if the servers in east and west do not share the same SSO keys, then your SSO will be inefficient if you use a general DNS domain such as "renovations.com". Instead, you should tailor your SSO domain for the Windows™ DNS domain in which it will operate.

Example: inefficent SSO configuration

The following example illustrates how use of a general SSO domain, renovations.com, is inefficient when servers in west.renovations.com and east.renovations.com do not share SSO keys.

Procedure

  1. User authenticates to server in east.renovations.com using Windows™ single sign-on. The east server creates the user’s LTPA token using the east server’s SSO keys. The user’s browser acquires the LTPA token to be used with renovations.com DNS domains.
  2. User accesses server in west.renovations.com. The browser sends the LTPA token, which has been set to apply to all servers in renovations.com. The server in west.renovations.com spends time attempting to validate the token, but cannot, because it does not share the SSO keys with the east servers.
  3. The west server cannot validate the existing LTPA token so it must authenticate the user via Windows™ single sign-on. The west server creates the user’s LTPA token using the west server’s SSO keys. The user’s browser acquires a new LTPA token to be used with renovations.com DNS domains. The browser now only has the LTPA token created by the west server, which replaces the previous one.
  4. The user accesses a server in east.renovations.com. The browser sends the LTPA token, which has been set to apply to all servers in renovations.com. The east server spends time attempting to validate the token, but can’t (because west server created it using alternate SSO keys). The user must again be authenticated to the east server using Windows™ single sign-on. The east server again will overwrite the existing LTPA token.

Results

The cycle of repeatedly using Windows™ single sign-on and overwriting the LTPA token is highly inefficient.

Example: efficient SSO configuration

The following example illustrates how using SSO domains tailored to Windows™ domains is more efficient when servers in west.renovations.com and east.renovations.com do not share SSO keys.

Procedure

  1. User authenticates to server in east.renovations.com and acquires LTPA token to be used with east.renovations.com DNS domains.
  2. User accesses server in west.renovations.com. The browser does not send the LTPA token, which is only for the east servers.
  3. The west server must authenticate the user via Windows™ single sign-on. The user acquires a second LTPA token to be used with west.renovations.com DNS domains.
  4. The user accesses server in east.renovations.com. The browser sends the first LTPA token it has, which has been set to apply to all the east servers. The east server uses the LTPA token to identify the user.
  5. The user accesses server in west.renovations.com. The browser sends the second LTPA token it has, which has been set to apply to all the west servers. The west server uses the LTPA token to identify the user.