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/FQDNEl 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/sqlbox1MSSQLSvc/sqlbox1:1433MSSQLSvc/sqlbox1.mydomain.orgMSSQLSvc/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:1522MSSQLSvc/sqlbox1:instance2MSSQLSvc/sqlbox1.mydomain.org:1522MSSQLSvc/sqlbox1.mydomain.org:instance2MSSQLSvc/sqlbox1.mydomain.org/instance2MSSQLSvc/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).
fuente
Respuestas:
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 :
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:
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 ...
fuente
Cuando el servicio SQL Server crea SPN, crea dos para cada instancia. Este es el formato que usa.
Instancia predeterminada:
Instancia nombrada:
Para sus instancias con nombre, si crea SPN manualmente, deberá tener un puerto estático en lugar del puerto dinámico predeterminado.
fuente