SECURITY

Examples of account choices and SPNs
This topic provides examples of using the setspn utility to assign SPNs in Active Directory. It is a best practice to use a named Windows account when assigning SPNs, however some scenarios do not strictly require use of a named Windows account. The examples below illustrate the use of the setspn command and discuss viable choices for account usage.

Web Site serviced by multiple Domino servers through an IP sprayer

If your SSO environment is a Web Site with an IP sprayer that distributes connection requests among multiple Domino servers, you must define SPNs in one named account in Active Directory. All the Domino servers log on to that same account as a Windows service rather than to individual Local System accounts. For example, assume a Web Site document is configured as follows:


You would run setspn three times on a named account (in this example, ssorenovations) to define three SPNs for the account:

setspn -a HTTP/ipsprayer.renovations.com ssorenovations

setspn -a HTTP/domino1.ad.renovations.com ssorenovations

setspn -a HTTP/domino2.ad.renovations.com ssorenovations

Web users who are logged in to the Active Directory domain are not prompted for passwords when accessing Domino1/Renovations or Domino2/Renovations through HTTP or HTTPS URLs containing any of these DNS names:

ipsprayer.renovations.com

domino1.ad.renovations.com

domino2.ad.renovations.com

Web Site serviced by one Domino server

If you have a Web Site serviced by just one Domino server, you can define SPNs in either a named account or the Local System account. For example, assume that a Web Site document is configured as follows:


You would run setspn twice on the account (in this example, the Local System account, domino1) as follows:

setspn -a HTTP/www.sso1.renovations.com domino1

setspn -a HTTP/www.sso2.renovations.com domino1

Web users who are logged in to the Active Directory domain are not prompted for passwords when accessing the Domino1/Renovations server through HTTP or HTTPS URLs that contain either www.sso1.renovations.com or www.sso2.renovations.com.

Web Site serviced by multiple Domino servers that do not share DNS names in URLs

If you have a Web Site serviced by multiple Domino servers that do not share DNS names in URLs, you can:


For example, assume that a Web Site document is configured as follows:
Domino1/Renovations services only URLs containing domino1.ad.renovations.com and Domino2/Renovations services only URLs containing domino2.ad.renovations.com. To define an SPN for each Local System account (domino1, domino2), you would run setspn once on each account as follows:

setspn -a HTTP/domino1.ad.renovations.com domino1

setspn -a HTTP/domino2.ad.renovations.com domino2

Web users who are logged in to the Active Directory domain are not prompted for passwords when accessing the Domino1/Renovations through URLs that contain domino1.ad.renovations.com or when accessing the Domino2/Renovations server through domino2.ad.renovations.com.

SSO configuration that uses Server documents

If your SSO configuration uses Server documents rather than Web Site documents, you can:


For example, assume that each server is configured for multi-server session authentication and that the specified Web SSO Configuration document lists the following servers in the Participating Servers field:
Also assume that the corresponding host names are:
To use the Local System accounts, run setspn once on each account as follows:

setspn -a HTTP/domino1.ad.renovations.com domino1

setspn -a HTTP/domino2.ad.renovations.com domino2

setspn -a HTTP/domino3.ad.renovations.com domino3

Web clients are not prompted for passwords when accessing HTTP or HTTPS URLs that contain domino1.ad.renovations.com when domino1 is logged on under the Local System account. URLs that contain domino2.ad.renovations or domino3.ad.renovations work similarly.

Related topics