Sql server windows service name
Всем привет, сегодня хочу вам рассказать как настраивать SPN в Active Directory, на примере SPN для MS SQL Server 2012. В процессе загрузки свежее установленного экземпляра SQL Server в его логе можно обнаружить ошибку регистрации SPN, в случае если службы SQL Server запускаются от имени пользовательской доменной учетной записи. Необходимо зарегистрировать имя участника-службы (SPN — Service Principal Name) для учетной записи службы SQL Server, чтобы в работе службы могла использоваться проверка подлинности с помощью протокола Kerberos.
Для того чтобы получить информацию о том, что на доменной учетной записи, от имени которой производится запуск SQL Server действительно не зарегистрировано SPN связанных с SQL с помощью утилиты SetSPN выполним команду:
В нашем примере KOM-AD01-DB03 — это имя сервера SQL, а s-KOM-AD01-DB03-SQL01 — это имя пользовательской доменной учетной записи, из под которой запускаются службы SQL Server на этом сервере.
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-02
Как мы видим, ни на учетной записи компьютера ни на учетной записи пользователя нет SPN содержащих указатели MSSQLSvc. Помимо утилиты SetSPN мы можем воспользоваться оснасткой “AD Users and Computers” (dsa.msc) с включенным режимом отображения дополнительных компонент…
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-03
открыв свойства соответствующей учётной записи и перейдя на вкладку редактирования атрибутов можно посмотреть и изменить значение атрибута servicePrincipalName
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-04
Особенности работы с Kerberos аутентификацией в SQL Server (и в частности управление SPN) рассмотрены в статье KB319723 — How to use Kerberos authentication in SQL Server
Для того чтобы обеспечить нужное для корректной работы Kerberos содержание атрибута servicePrincipalName можно пойти двумя путями:
- Создать необходимую SPN запись вручную с помощью утилиты SetSPN. Синтаксис команд будет следующий:
пример setspn -S MSSQLSvc/server19.contoso.com:1433 sqlservice (имя учетки запуска)
setspn -S MSSQLSvc/server19.contoso.com:MSSQL2012 sqlservice
- Разрешить учетной записи, от имени которой запускается SQL Server, динамическое обновление атрибута servicePrincipalName, выдав разрешения на чтение и запись атрибута servicePrincipalName. Для того чтобы выполнить второй вариант, откроем оснастку ADSIEdit.msc, перейдём к свойствам объекта – учетной записи. На закладке “Безопасность” (Security) нажмём кнопу “Дополнительно” (Advanced)
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-05
В диалоговом окне «Дополнительные параметры безопасности» (Advanced Security Settings) нажмём кнопку «Добавить» (Add)
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-06
введём SELF и в открывшемся окне перейдём на закладку «Свойства» (Properties). В окне выбора области применения выберем пункт «Только этот объект» (This object only) и в списке разрешений отметим два пункта:
- Read servicePrincipalName
- Write servicePrincipalName
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-07
Сохраним внесённые изменения и затем, при запуске службы SQL Server, сможем убедиться в том, что в журнале регистрации событий появилась запись об успешном создании SPN
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-08
а так же увидим что вывод утилиты SetSPN изменился
Как настроить SPN (Service Principal Name) в SQL Server и динамическая регистрация SPN-09
Как удалить SPN
Вот пример ситуации когда нужно удаление. Был раньше сервер virt105 и использовался под одни нужды, сервер удален. После по этому же имени virt105 подняли другой сервер, и столкнулись с тем, что SPN уже был занят. Вот запрос на проверку SPN у virt105
Далее попытка его зарегистрировать, и видим, что он уже есть на учетную запись Семина Ивана
После удаления старого SPN, по новому все зарегистрировалось.
Службы SQL Server SQL Server Services
Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) — только Windows Управляемый экземпляр SQL Azure Azure SQL Managed Instance Управляемый экземпляр SQL Azure Azure SQL Managed Instance Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) — Windows only Управляемый экземпляр SQL Azure Azure SQL Managed Instance Управляемый экземпляр SQL Azure Azure SQL Managed Instance
В этом разделе содержатся разделы справки F1 диалоговых окон служб SQL Server SQL Server в диспетчере конфигурации Microsoft Microsoft SQL Server SQL Server . This section contains F1 Help topics for the SQL Server SQL Server Services dialog boxes in Microsoft Microsoft SQL Server SQL Server Configuration Manager.
Если диспетчер конфигурации SQL Server открывается на узле кластера, не содержащем ресурсы, то службы отображаются как остановленные. If you open SQL Server Configuration Manager on a node of a cluster that does not host the resources, the services show as stopped.
Если узлы служб SQL Server SQL Server не заполняются с помощью служб SQL Server SQL Server , доступных на компьютере, то у вас, возможно, недостаточно прав для доступа к инструментарию WMI. If the nodes of the SQL Server SQL Server Services do not populate with the SQL Server SQL Server services available on the computer, you may not have sufficient permissions to access Windows Management Instrumentation (WMI). Описание настройки разрешений на инструментарий WMI см. в электронной документации в статье «Настройка инструментария WMI для отображения состояния сервера в инструментальных средствах SQL Server». To configure permissions on WMI, search Books Online for the topic, «How to: Configure WMI to Show Server Status in SQL Server Tools.»
Register a Service Principal Name for Kerberos Connections
Applies to: SQL Server (all supported versions)
To use Kerberos authentication with SQL Server requires both the following conditions to be true:
The client and server computers must be part of the same Windows domain, or in trusted domains.
A Service Principal Name (SPN) must be registered with Active Directory, which assumes the role of the Key Distribution Center in a Windows domain. The SPN, after it’s registered, maps to the Windows account that started the SQL Server instance service. If the SPN registration hasn’t been performed or fails, the Windows security layer can’t determine the account associated with the SPN, and Kerberos authentication isn’t used.
If the server can’t automatically register the SPN, the SPN must be registered manually. See Manual SPN Registration.
You can verify that a connection is using Kerberos by querying the sys.dm_exec_connections dynamic management view. Run the following query and check the value of the auth_scheme column, which will be «KERBEROS» if Kerberos is enabled.
Microsoft Kerberos Configuration Manager for SQL Server is a diagnostic tool that helps troubleshoot Kerberos related connectivity issues with SQL Server. For more information, see Microsoft Kerberos Configuration Manager for SQL Server.
The Role of the SPN in Authentication
When an application opens a connection and uses Windows Authentication, SQL Server Native Client passes the SQL Server computer name, instance name and, optionally, an SPN. If the connection passes an SPN, it’s used without any changes.
If the connection doesn’t pass an SPN, a default SPN is constructed based on the protocol used, server name, and the instance name.
In both of the preceding scenarios, the SPN is sent to the Key Distribution Center to obtain a security token for authenticating the connection. If a security token can’t be obtained, authentication uses NTLM.
A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. The Kerberos authentication service can use an SPN to authenticate a service. When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that instance, connects to the service, and presents the SPN for the service to authenticate.
The information that is provided in this topic also applies to SQL Server configurations that use clustering.
Windows Authentication is the preferred method for users to authenticate to SQL Server. Clients that use Windows Authentication are authenticated by either using NTLM or Kerberos. In an Active Directory environment, Kerberos authentication is always attempted first. Kerberos authentication isn’t available for SQL Server 2005 (9.x) clients using named pipes.
Permissions
When the Database Engine service starts, it attempts to register the Service Principal Name (SPN). Suppose the account starting SQL Server doesn’t have permission to register an SPN in Active Directory Domain Services. In that case, this call fails, and a warning message is logged in the Application event log as well as the SQL Server error log. To register the SPN, the Database Engine must be running under a built-in account, such as Local System (not recommended), or NETWORK SERVICE, or an account that has permission to register an SPN. You can register an SPN using a domain administrator account, but this is not recommended in a production environment. When SQL Server runs on the Windows 7 or Windows Server 2008 R2 operating system, you can run SQL Server using a virtual account or a managed service account (MSA). Both virtual accounts and MSA’s can register an SPN. If SQL Server isn’t running under one of these accounts, the SPN isn’t registered at startup, and the domain administrator must register the SPN manually.
When the Windows domain is configured to run at less than the Windows Server 2008 R2 Windows Server 2008 R2 functional level, then the Managed Service Account will not have the necessary permissions to register the SPNs for the SQL Server Database Engine service. If Kerberos authentication is required, the Domain Administrator should manually register the SQL Server SPNs on the Managed Service Account.
SPN Formats
Beginning with SQL Server 2008, the SPN format is changed in order to support Kerberos authentication on TCP/IP, named pipes, and shared memory. The supported SPN formats for named and default instances are as follows.
Named instance
MSSQLSvc is the service that is being registered.
is the fully qualified domain name of the server.
is the TCP port number.
is the name of the SQL Server instance.
Default instance
| MSSQLSvc/ , where:
MSSQLSvc is the service that is being registered.
is the fully qualified domain name of the server.
is the TCP port number.
The new SPN format doesn’t require a port number. This means that a multiple-port server or a protocol that doesn’t use port numbers can use Kerberos authentication.
is a TCP port number.
In the case of a TCP/IP connection, where the TCP port is included in the SPN, SQL Server must enable the TCP protocol for a user to connect by using Kerberos authentication.
Automatic SPN Registration
When an instance of the SQL Server Database Engine starts, SQL Server tries to register the SPN for the SQL Server service. When the instance is stopped, SQL Server tries to unregister the SPN. For a TCP/IP connection, the SPN is registered in the format MSSQLSvc/ : .Both named instances and the default instance are registered as MSSQLSvc, relying on the value to differentiate the instances.
For other connections that support Kerberos the SPN is registered in the format MSSQLSvc/ / for a named instance. The format for registering the default instance is MSSQLSvc/ .
Manual intervention might be required to register or unregister the SPN if the service account lacks the permissions that are required for these actions.
Manual SPN Registration
To register the SPN manually, the administrator must use the Setspn.exe tool that is provided with the Microsoft Windows Server 2003 Support Tools. For more information, see the Windows Server 2003 Service Pack 1 Support Tools KB article.
Setspn.exe is a command-line tool that enables you to read, modify, and delete the Service Principal Names (SPN) directory property. This tool also enables you to view the current SPNs, reset the account’s default SPNs, and add or delete supplemental SPNs.
The following example illustrates the syntax used to manually register an SPN for a TCP/IP connection using a domain user account:
If an SPN already exists, it must be deleted before it can be reregistered. You do this by using the setspn command together with the -D switch. The following examples illustrate how to manually register a new instance-based SPN. For a default instance using a domain user account, use:
For a named instance, use:
Client Connections
User-specified SPNs are supported in client drivers. However, if an SPN isn’t provided, it will be generated automatically based on the type of a client connection. For a TCP connection, an SPN in the format MSSQLSvc/FQDN:[port] is used for both the named and default instances.
For named pipes and shared memory connections, an SPN in the format MSSQLSvc/ : is used for a named instance and MSSQLSvc/ is used for the default instance.
Using a service account as an SPN
Service accounts can be used as an SPN. They’re specified through the connection attribute for the Kerberos authentication and take the following formats:
username@domain or domain\username for a domain user account
machine$@domain or host\FQDN for a computer domain account such as Local System or NETWORK SERVICES.
To determine the authentication method of a connection, execute the following query.
Authentication Defaults
The following table describes the authentication defaults that are used based on SPN registration scenarios.
| Scenario | Authentication method |
|---|---|
| The SPN maps to the correct domain account, virtual account, MSA, or built-in account. For example, Local System or NETWORK SERVICE. | Local connections use NTLM, remote connections use Kerberos. |
| The SPN is the correct domain account, virtual account, MSA, or built-in account. | Local connections use NTLM, remote connections use Kerberos. |
| The SPN maps to an incorrect domain account, virtual account, MSA, or built-in account | Authentication fails. |
| The SPN lookup fails or doesn’t map to a correct domain account, virtual account, MSA, or built-in account, or isn’t a correct domain account, virtual account, MSA, or built-in account. | Local and remote connections use NTLM. |
‘Correct’ means that the account mapped by the registered SPN is the account that the SQL Server service is running under.
Comments
The Dedicated Administrator Connection (DAC) uses an instance name-based SPN. Kerberos authentication can be used with a DAC if that SPN is registered successfully. As an alternative a user can specify the account name as an SPN.
If SPN registration fails during startup, this failure is recorded in the SQL Server error log, and startup continues.
If SPN de-registration fails during shutdown, this failure is recorded in the SQL Server error log, and shutdown continues.
