Registrar nombres principales de servicio de Kerberos mediante Http.sys
Servicios web XML nativos están desusados. Esta característica se quitará en una versión futura de Microsoft SQL Server. Evite utilizar esta característica en nuevos trabajos de desarrollo y tenga previsto modificar las aplicaciones que actualmente la utilizan.
Al crear o modificar extremos HTTP mediante CREATE ENDPOINT o ALTER ENDPOINT, se especifica el tipo de autenticación utilizado para autenticar a los usuarios que envían la solicitud HTTP SOAP al extremo. Para obtener más información, vea CREATE ENDPOINT (Transact-SQL) y ALTER ENDPOINT (Transact-SQL).
Mediante CREATE ENDPOINT ALTER ENDPOINT, se pueden configurar extremos para admitir la autenticación Kerberos de los modos siguientes:
Si se establece AUTHENTICATION=KERBEROS, Kerberos se utiliza como el único medio de autenticación HTTP.
Cuando AUTHENTICATION=INTEGRATED, la autenticación HTTP del extremo puede ofrecer las siguientes opciones como parte del desafío de autenticación: NEGOTIATE, KERBEROS y NTLM. Con la opción NEGOTIATE, el cliente y el servidor intentan establecer la autenticación basada en Kerberos. Si el cliente no admite Kerberos o no es posible la negociación, la autenticación volverá a NTLM. Para evitar que el cliente vuelva a NTLM cuando utilice NEGOTIATE, se recomienda que el cliente establezca AUTHENTICATION=KERBEROS en el extremo.
Para admitir la autenticación mutua con Kerberos, una instancia de SQL Server debe asociar un Nombre principal de servicio (SPN) a la cuenta en la que se ejecutará; por ejemplo, una cuenta de sistema local o una cuenta de usuario de dominio. Los detalles específicos del registro de SPN realizados por la instancia específica de SQL Server están determinados por el tipo de cuenta de servicio en la que se han configurado. Si SQL Server se ejecuta en una cuenta del sistema local o en una cuenta del servicio de red, los SPN deben registrarse con el nombre del equipo. Si SQL Server se ejecuta en una cuenta de usuario de dominio, los SPN deben registrarse con el nombre de usuario del dominio.
Usar SetSPN.exe
Para habilitar la asociación de un SPN con la cuenta en la que se está ejecutando la instancia de SQL Server, use la herramienta de compatibilidad SetSPN.exe de Windows. Esta herramienta agrega el SPN del nombre del equipo en el que se ejecuta la instancia de SQL Server a la cuenta de usuario de servicio del dominio de Windows ubicada en Active Directory. En este escenario, la herramienta SetSPN.exe se puede usar para agregar dos SPN: uno para el nombre NetBIOS y otro para el nombre DNS completo.
Por ejemplo, si la herramienta SetSPN.exe se ejecuta desde la instancia de SQL Server que se ejecuta en MyComputer, los dos SPN siguientes se asocian a la cuenta en la que se ejecuta la instancia de SQL Server y se deben agregar al directorio:
HTTP/MyComputer;
HTTP/MyComputer.fully.qualified.domain.name.com
Tenga en cuenta que una sola cuenta puede tener varios SPN, pero que un SPN solo puede estar registrado para una cuenta.
Para eliminar estos dos mismos nombres SPN, NetBIOS y DNS completo, utilice también SetSPN.exe.
Consideraciones
Igual que Httpcfg.exe, SetSPN.exe está disponible con Windows Server 2003 y se instala cuando se usa el mismo procedimiento para instalar Httpcfg.exe y otras herramientas de soporte de Windows. Para obtener más información, vea Configurar el controlador HTTP en modo de kernel (Http.sys).
Si una instancia de SQL Server no se ejecuta como la cuenta del sistema local, únicamente los usuarios con autenticación integrada que tienen privilegios DOMAIN ADMIN pueden cambiar el registro de SPN con la herramienta SetSPN.exe.
Si una instancia de SQL Server se ejecuta como la cuenta del sistema local, únicamente los miembros del rol fijo de servidor sysadmin de SQL Server pueden cambiar los registros de SPN con la herramienta SetSPN.exe.
Si la cuenta de servicio es Sistema local, el SPN se agrega a la cuenta de Active Directory del equipo sin tener que utilizar la herramienta SetSPN.exe.
Sintaxis de SetSPN.exe
La sintaxis de SetSPN.exe es:
setspn { - UNSPN | - DSPN | - L } service_account
Argumentos
-A
Agrega el SPN especificado a la cuenta.-D
Elimina el SPN especificado de la cuenta.-L
Enumera todos los SPN registrados en la cuenta.
Ejemplos
Si una instancia de SQL Server se ejecuta como un usuario de dominio (MyDomain\MySQLAccount) en un equipo que se llama MySQLHost, se pueden utilizar los comandos siguientes para establecer los SPN apropiados:
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySqlHost.Mydomain.Mycorp.com MyDomain\MySQLAccount
Tenga en cuenta que una cuenta puede tener varios SPN (uno por cada nombre de host o servicio), pero que un SPN solo puede estar registrado en una cuenta. Tener el mismo SPN registrado en varias cuentas provoca un error en la autenticación Kerberos.
Por ejemplo, la cuenta MyDomain\MySQLAccount puede tener registrados los siguientes SPN distintos. Los dos primeros comandos son para dos servicios diferentes (http y rpc). El último es para un nombre de host diferente, teniendo en cuenta que el equipo tiene varios nombres de host.
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A rpc/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySecondHost MyDomain\MySQLAccount
Por el contrario, el escenario siguiente provocará un error de Kerberos:
setspn –A http/MySQLHost MyDomain\MySQLAccountOne
setspn –A http/MySQLHost MyDomain\MySQLAccountTwo
El error se produce porque hay dos instancias de SQL Server en un equipo que se ejecuta con dos cuentas de servicio diferentes (MySQLAccountOne y MySQLAccountTwo). Registrar ambos SPN, uno por cada instancia de SQL Server, no es un escenario admitido.
Esto tiene implicaciones cuando hay varias instancias de SQL Server que se ejecutan en el mismo equipo con cuentas diferentes. El SPN solamente se puede registrar para una cuenta. Si necesita que coexistan varias instancias de SQL Server (por ejemplo, Inst1 e Inst2) junto con otras aplicaciones (como IIS) y desea utilizar la autenticación HTTP Kerberos para todos los servicios, utilice una de las siguientes opciones para solucionar los conflictos de registro de SPN:
Hacer que todas las instancias y aplicaciones se ejecuten en la misma cuenta.
Por ejemplo, hacer que Inst1, Inst2 e IIS se ejecuten todos como LocalSystem o Mydomain\MyServiceAccount.
Registrar varios nombres de host para el mismo equipo y que cada instancia y aplicación escuche en un host diferente. Por lo tanto, en este caso, debería hacer lo siguiente:
Crear tres nombres de host diferentes para el equipo.
Asignar cada host a una aplicación diferente.
Registrar tres conjuntos de SPN, uno para cada combinación nombre de host/aplicación.
Solucionar problemas de registro de SPN de Kerberos
Los problemas más habituales que hay que solucionar en el registro de SPN de Kerberos son los siguientes:
Un SPN no está registrado.
Cuando un SPN no está registrado, la autenticación Kerberos funcionará desde el equipo local en el que se ejecuta la instancia de SQL Server, pero generará un error en los equipos cliente remotos.
Un SPN está registrado más de una vez.
Hay varios escenarios en los que un administrador puede duplicar los nombres principales de servicio (SPN) en el directorio de dominio que generarán un error de la autenticación Kerberos. Entre ellos figuran los siguientes:
Realizar cambios en la cuenta de dominio en la que se ejecuta la instancia de SQL Server.
Si SetSpn.exe se ejecuta mientras se ejecuta una instancia de SQL Server como una cuenta de dominio; por ejemplo, DOMINIO\Usuario1, y, a continuación, se cambia la cuenta de dominio utilizada para ejecutar SQL Server; por ejemplo, DOMINIO\Usuario2, cuando se vuelva a ejecutar SetSPN.exe, provocará que se inserte el mismo SPN en el directorio de ambas cuentas.
Instalar varias instancias de SQL Server que se ejecutan en cuentas diferentes.
Si instala varias instancias de SQL Server y ejecuta cada instancia en una cuenta diferente, si SetSpn.exe se ejecuta en cada instancia, habrá cuentas duplicadas en el directorio de cada cuenta de servicio de SQL Server. Esto se aplica a ambas instancias que se ejecutan en una cuenta de usuario de dominio y también a la cuenta del sistema local.
Quitar y reinstalar una instancia de SQL Server en una cuenta diferente.
Si instala SQL Server en una cuenta, registra los SPN, quita y reinstala SQL Server en una cuenta diferente y, a continuación, vuelve a registrar los SPN, cada cuenta de dominio tendrá los mismos SPN. Esto significa que los SPN estarán duplicados.
En cada uno de estos escenarios, el problema es que el extremo HTTP volverá a la autenticación NTLM hasta que se resuelva el problema. Esto suele implicar buscar en el directorio los SPN duplicados u obsoletos y eliminarlos manualmente.