Security Account Delegation

3 4

SQL Server 2000 builds on the Windows 2000 security features by using the Kerberos security model. (Information about the Kerberos security model can be found in Chapter 2.) SQL Server 2000 uses the Kerberos protocol to support mutual authentication between the client and the server. This allows the security credentials of a client to be passed between computers so that the client can connect to multiple servers; when a new server is accessed, the server can proceed by using the credentials of the impersonated client. This credential sharing is known as security account delegation.

Let's look at an example of security account delegation. Suppose a client connects to ServerA as NTDOMAIN\AlexR, and ServerA connects to ServerB. ServerB then knows that the connection security identity is NTDOMAIN\AlexR. This alleviates the need for the client to log in to ServerB.

If you want to use security account delegation, all servers that you are connecting to must be running Windows 2000 with Kerberos support enabled, and you must be using Active Directory services. The following options must be set in Active Directory services for delegation to work:

  • Account Is Sensitive And Cannot Be Delegated This option must not be selected for the user requesting delegation.
  • Account Is Trusted For Delegation This option must be selected for the service account of SQL Server 2000.
  • Computer Is Trusted For Delegation This option must be selected for the server running an instance of SQL Server 2000.

Configuring SQL Server

Prior to using security account delegation, you must configure SQL Server 2000 to accept the delegations. Delegation enforces mutual authentication. To use security account delegation, SQL Server 2000 must have a Service Principal Name (SPN) assigned by the Windows 2000 account domain administrator. The SPN must be assigned to the service account of the SQL server on that computer. The SPN is necessary to prove that SQL Server is verified on the particular server and at the particular socket address by the Windows 2000 account domain administrator. You can have your domain administrator establish an SPN for SQL Server by using the Setspn utility, which is accessible through the Windows 2000 Resource Kit.

To create an SPN for SQL Server, you run the following command:

 setspn -A MSSQLSvc/Host:port serviceaccount 

Here is an example of using this command:

 setspn -A MSSQLSvc/MyServer.MyDomain.MyCompany.com sqlaccount 

MORE INFO


For more information about the Setspn utility, see the Windows 2000 documentation.

You must also be using TCP/IP to use security account delegation. You cannot use named pipes because the SPN targets a particular TCP/IP socket. If you are using multiple ports, you must have an SPN for each port.

You can enable delegation by using the LocalSystem account. SQL Server will self-register at service startup and automatically register the SPN. This option is easier than enabling delegation by using a domain user account. However, when SQL Server shuts down, the SPNs will be unregistered for the LocalSystem account. To enable delegation to run under the LocalSystem account, run the following command in the Setspn utility:

 setspn -A MSSQLSvc/Host:port serviceaccount 

NOTE


If you change a service account in SQL Server 2000, you must delete any previous SPNs that were defined and create new ones.



Microsoft SQL Server 2000 Administrator's Companion
Microsoft SQL Server 2000 Administrators Companion
ISBN: B001HC0RPI
EAN: N/A
Year: 2005
Pages: 264

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net