¿Cómo deberían ser mis entradas SPN para cada instancia de SQL?

Estoy encontrando información contradictoria sobre cómo formatear exactamente los SPN (nombres principales de servicio) para obtener las conexiones Kerberos adecuadas, y cuántos necesito para cada instancia de SQL.

Este documento de MS 2017 contiene lo siguiente:

A partir de SQL Server 2008, el formato SPN se cambia para admitir la autenticación Kerberos en TCP / IP, canalizaciones con nombre y memoria compartida. Los formatos SPN compatibles para instancias con nombre y predeterminadas son los siguientes.

• Instancia nombrada: MSSQLSvc/FQDN:[port|instancename]
• Instancia predeterminada: MSSQLSvc/FQDN:port|MSSQLSvc/FQDN

El nuevo formato SPN no requiere un número de puerto . Esto significa que un servidor de múltiples puertos o un protocolo que no usa números de puerto puede usar la autenticación Kerberos.

Tomé este último párrafo para significar que solo necesito una sola entrada, una de las siguientes:

• Instancia nombrada: MSSQLSvc/sqlbox1.mydomain.org/instance2
• Instancia predeterminada: MSSQLSvc/sqlbox1.mydomain.org

Eso parece contradecir este documento antiguo de MS (2011) , no solo sobre el número de puerto, sino también sobre qué nombre usar:

Para crear el SPN, puede usar el nombre NetBIOS o el Nombre de dominio completo (FQDN) del Servidor SQL. Sin embargo, debe crear un SPN para el nombre NetBIOS y el FQDN .

Cuando miro los SPN que ya existen en mi entorno, veo una gran variedad de combinaciones, algunos servidores tienen hasta 4 entradas:

• MSSQLSvc/sqlbox1
• MSSQLSvc/sqlbox1:1433
• MSSQLSvc/sqlbox1.mydomain.org
• MSSQLSvc/sqlbox1.mydomain.org:1433

Incluso el propio administrador de configuración Kerberos de MS parece querer generar las dos últimas versiones (con la ofuscación adecuada):

De manera similar para instancias con nombre existentes, veo una mezcla extraña, algunas de ellas casi seguramente inválidas:

• MSSQLSvc/sqlbox1:1522
• MSSQLSvc/sqlbox1:instance2
• MSSQLSvc/sqlbox1.mydomain.org:1522
• MSSQLSvc/sqlbox1.mydomain.org:instance2
• MSSQLSvc/sqlbox1.mydomain.org/instance2
• MSSQLSvc/sqlbox1.mydomain.org:1522:instance2

Entonces, ¿cómo deberían ser realmente mis DSN, tanto para instancias predeterminadas como con nombre, si solo uso TCP en mi entorno?

¿Debo incluir el puerto o no? ¿O incluir uno con el puerto y otro sin él?

Utilice el FQDN solamente, ¿o necesito las entradas solo con el nombre de Netbios? ¿O eso solo sería si estuviéramos usando tuberías con nombre (que no somos)?

(Para el contexto, ejecutamos SQL 2005 hasta 2014, algunos agrupados, otros independientes. La conectividad es solo a través de TCP, las canalizaciones con nombre están deshabilitadas en el administrador de configuración. Las repararemos / crearemos manualmente en lugar de permitir que la cuenta del servicio SQL las cree en inicio del servidor).

Si solo usa TCP / IP para conectarse a sus instancias, solo necesita los puertos especificados. Los nombres de instancia se utilizan cuando se conecta a las instancias de SQL a través de los protocolos de canalizaciones con nombre. Lamentablemente, el artículo de MS no sale directamente de qué formato se requiere para cada protocolo, pero se deriva de (muchas pruebas en mi entorno) y la siguiente sesión de artículo de MS :

Para las canalizaciones con nombre y las conexiones de memoria compartida, se utiliza un SPN en el formato MSSQLSvc / FQDN: nombre de instancia para una instancia con nombre y MSSQLSvc / FQDN para la instancia predeterminada.

Con respecto a los FQDN frente a los nombres NETBIOS, recomendaré los FQDN ya que no son tan propensos a los problemas si se encuentra con problemas aleatorios del servidor DNS.

Levantado de mi publicación de blog sobre el tema, los formatos deben verse de la siguiente manera:

La referencia fuente de MS se puede encontrar aquí .

Ahora para hacer el Día del administrador de su red (por ejemplo, configuración de unidad organizativa que permite SPN de registro automático)

Su administrador de red puede crear una unidad organizativa en el dominio que contiene todas sus cuentas de servicio de SQL Server que se pueden configurar de tal manera que la cuenta de servicio puede crear un SPN para sí misma y solo. El método sigue principalmente el blog de Ryan Reis , pero tiene algunos pequeños ajustes para que no se realicen subvenciones en exceso.

Este proceso describe la creación de una unidad organizativa en el dominio que permite a las cuentas dentro de él registrar automáticamente sus propios SPN:

1. Como una cuenta con derechos elevados en el dominio, abra ADSI Edit (adsiedit desde el símbolo del sistema)
2. Haga clic derecho en Edición ADSI -> Conectar a ...
3. Conectarse al contexto de nomenclatura predeterminado
4. Navegue hasta / Cree el contenedor de OU que contiene las cuentas de servicio a las que desea otorgar derechos SPN
5. Haga clic derecho en la unidad organizativa -> Propiedades
6. Haga clic en la pestaña Seguridad
7. Haga clic en el botón Avanzado
8. Resalte SELF y haga clic en Editar ... o si el usuario especial SELF no aparece en la lista de nombres de Grupo o Usuario, haga clic en Agregar ... e ingrese SELF para el nombre del objeto
9. Haga clic en la pestaña Propiedades
10. Seleccione los objetos de Usuario descendiente de la lista desplegable junto a Aplicar a: Nota: Este es el ligero ajuste a los pasos descritos en la publicación del blog de Ryan por las razones mejor descritas en esta publicación de ServerFault / StackExchange .
11. Marque la casilla Permitir junto a lo siguiente:
    • Leer servicePrincipalName
    • Escribir servicePrincipalName
12. Haga clic en Aceptar (en la ventana de entrada de permisos)
13. Haga clic en Aceptar (en la ventana Configuración de seguridad avanzada)
14. Haga clic en Aceptar (en la ventana de propiedades de OU)
15. Agregar cuentas de servicio que ejecutan servicios de SQL Server a la unidad organizativa
16. (Opcionalmente) Reinicie los Servicios de SQL Server que se ejecutan en dicha (s) cuenta (s)
17. Disfruta golosinas

Después de seguir los pasos anteriores, el contenedor de unidades organizativas en cuestión ahora está configurado de tal manera que cualquier cuenta agregada podrá registrar y eliminar SPN para sí mismo y solo. Esta es exactamente la cantidad correcta de permisos, ya que estas cuentas no podrán pisotear los SPN registrados por otras cuentas.

El propósito de reiniciar SQL Server en el paso 16 es garantizar que los SPN se registren como se esperaba. SQL intentará eliminar cualquier SPN registrado en el apagado y agregarlo al inicio, por lo que el reinicio solo es necesario si actualmente no existen SPN para dicho servicio de SQL Server.

La nota final sobre este enfoque es que si está ejecutando SQL Server en una configuración tradicional de instancia en clúster de conmutación por error (FCI), NO se recomienda agregar la cuenta de servicio de esta instancia a esta unidad organizativa, según KB 2443457 .

Realmente necesito publicar la Parte 2 de mi serie Kerberos ...

Cuando el servicio SQL Server crea SPN, crea dos para cada instancia. Este es el formato que usa.

Instancia predeterminada:

MSSQLSvc/servername.domain.com
MSSQLSvc/servername.domain.com:1433

Instancia nombrada:

MSSQLSvc/servername.domain.com:54321
MSSQLSvc/servername.domain.com:instancename

Para sus instancias con nombre, si crea SPN manualmente, deberá tener un puerto estático en lugar del puerto dinámico predeterminado.