Recibir una información de advertencia de "Información de SuperSocket advertencia" cuando una cuenta de servicio de SQL Server es un usuario de dominio

Nº DE ERROR: 232774 (SHILOH_BUGS)

Síntomas

Cuando se inicia SQL Server en un equipo que está ejecutando Microsoft SQL Server 2000 o Microsoft SQL Server 2005, el programa de SQL Server siempre intenta registrar el servidor virtual en Active Directory. El suceso siguiente puede anotarse en el registro de eventos: es igual a ERROR_NO_SUCH_DOMAIN NotaError 1355. Error 8344 es igual a permisos insuficientes para realizar la operación de registro. Esto se muestra como una advertencia para la función SPNRegister , como un error de la función SpnUnRegister .

Este mensaje no es un mensaje de error. Este texto es sólo una advertencia de que SQL Server no se puede registrar un nombre principal de servicio (SPN). Esto indica que el mecanismo de seguridad que se utilizará es la autenticación de Microsoft Windows NT elige desafío/respuesta (NTLM) en lugar de la autenticación Kerberos.

Estos mensajes sólo deben considerarse un problema si la instalación de SQL Server requiere autenticación Kerberos o la configuración de seguridad de red evitar el retroceso a negociación de NTLM. De lo contrario, estos mensajes pueden omitirse con seguridad.

Causa

El mensaje aparece normalmente porque la cuenta del servicio SQL Server se ejecuta como un usuario de dominio que no tiene los permisos necesarios para registrar el SPN. Con Microsoft Windows 2000 Service Pack 3 (SP3), puede habilitar la autenticación Kerberos en clústeres de servidores. Para obtener instrucciones sobre cómo hacerlo, consulte el siguiente artículo en Microsoft Knowledge Base:
Soporte de 319723 información acerca de SQL Server 2000 Kerberos, incluyendo servidores virtuales de SQL Server en clústeres de servidores

Solución

También puede editar los permisos de configuración de Control de acceso de la cuenta en el servicio de directorio de Active Directory para habilitar el permiso de lectura servicePrincipalName y el permiso de servicePrincipalName de escritura para la cuenta de servicio de SQL.

Advertencia: Si utiliza el complemento Edición de Interfaces del servicio Active Directory (ADSI), la utilidad LDP o ningún otro cliente de LDAP versión 3 y modifica incorrectamente los atributos de los objetos de Active Directory, puede provocar problemas graves. Estos problemas pueden exigir que vuelva a instalar Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, o tanto Windows y Exchange. Microsoft no puede garantizar que puedan resolverse problemas causados por la modificación incorrecta de los atributos de objeto de Active Directory. Modifique estos atributos bajo su propio riesgo.

Solución alternativa

Para resolver estos mensajes de tipo y habilitar el servicio de SQL Server crear SPN dinámicamente para las instancias de SQL Server, pida al administrador de dominio para agregar los permisos adecuados y derechos de usuario a las cuentas de inicio de SQL Server.

Para habilitar la cuenta de servicio de SQL Server establecer el SPN correctamente durante el inicio, siga estos pasos:
  1. Haga clic en Inicio, haga clic en Ejecutar, escriba Adsiedit.mscy, a continuación, haga clic en Aceptar.
  2. En la ventana Edición de ADSI , expanda el dominio [nombreDeDominio], DC = nombreDeDominioRaíz, expanda CN = Users, haga CN =nombreCuentay, a continuación, haga clic en Propiedades.

    Notas:
    • NombreDeDominio representa el nombre del dominio.
    • NombreDeDominioRaíz es un marcador de posición para el nombre del dominio raíz.
    • Nombre de cuenta representa la cuenta que especifique para iniciar el servicio SQL Server.
    • Si ha especificado el Sistema Local para iniciar el servicio SQL Server, nombre de cuenta representa la cuenta que utilice para iniciar sesión en Microsoft Windows.
    • Si ha especificado una cuenta de usuario de dominio para el servicio de SQL Server, nombre de cuenta representa la cuenta de usuario de dominio.
  3. En la CN =nombreCuenta propiedades diálogo cuadro, haga clic en la ficha seguridad .
  4. En la ficha seguridad , haga clic en Opciones avanzadas.
  5. En el cuadro de diálogo Configuración de seguridad avanzada , asegúrese de que el usuario SELF aparece en entradas de permisos. Si el usuario SELF no aparece, haga clic en Agregary, a continuación, agregue el usuario SELF .
  6. En las entradas de permisos, haga clic en automáticoy, a continuación, haga clic en Editar.
  7. En el cuadro de diálogo Entrada de permiso , haga clic en la ficha Propiedades .
  8. En la ficha Propiedades , haga clic en sólo este objeto en la lista Aplicar en y, a continuación, asegúrese de que los permisos siguientes están activados debajo de permisos:
    • Leer nombrePrincipalDeServicio
    • Escribir nombrePrincipalDeServicio
  9. Haga clic en Aceptar tres veces y, a continuación, cierre la ventana Edición de ADSI .
Para obtener ayuda con este proceso, póngase en contacto con soporte técnico de Active Directory. Si ponerse en contacto con soporte técnico, consulte este artículo de Microsoft Knowledge Base.

Al realizar esta solución, se eliminan problemas SPN para las instalaciones nuevas o que han tenido el nombre de dominio o puerto TCP/IP modificado.

Importante: Le recomendamos que no conceda WriteServicePrincipalName a la cuenta de servicio SQL cuando se cumplen las condiciones siguientes:
  • Hay varios controladores de dominio.
  • SQL Server está agrupado.
En este escenario, lo SPN para el SQL Server puede ser eliminado debido a la latencia de replicación de Active Directory. Esto puede causar problemas de conectividad a la instancia de SQL Server.

Suponga que tiene lo siguiente:
  • Una instancia virtual de SQL denominada Sqlcluster con dos nodos: el nodo A y nodo B.
  • A controlador de dominio autentica el nodo A y nodo B es autenticado por el controlador de dominio B.


Puede ocurrir lo siguiente:
  1. La instancia Sqlcluster está activa en el nodo A y registrado el SPN de SQL en un controlador de dominio durante el inicio de...
  2. La instancia Sqlcluster conmuta por error al nodo B al nodo A está apagado normalmente.
  3. La instancia Sqlcluster borrarse del registro su nombre SPN de un controlador de dominio durante el proceso de apagado en el nodo A.
  4. El SPN se quita de un controlador de dominio, pero el cambio todavía no se ha replicado en el controlador de dominio B.
  5. Cuando se inicia en el nodo B, la instancia Sqlcluster intenta registrar el SPN de SQL con el controlador de dominio B. Desde entonces, el SPN aún existe el nodo B no registra el SPN.
  6. Después de algún tiempo, el controlador de dominio A replica la eliminación del SPN (desde el paso 3) para el controlador de dominio B como parte de la replicación de Active Directory. El resultado final es que no existe ningún SPN válido para la instancia SQL en el dominio y, por tanto, verá los problemas de conexión a la instancia Sqlcluster.

Nota: Este problema se corrigió en SQL Server 2012.

Estado

Microsoft ha confirmado que se trata de un problema de SQL Server 2000 y SQL Server 2005.

Referencias

Para obtener más información, haga clic en los números de artículo siguientes para verlos en Microsoft Knowledge Base:

235529 compatibilidad con Kerberos en clústeres de servidor basado en Windows 2000

269229 cómo volver a crear manualmente la cuenta de servicio de Cluster Server

Propiedades

Id. de artículo: 303411 - Última revisión: 22 ene. 2017 - Revisión: 1

Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2000 Personal Edition, Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 Workgroup Edition, Microsoft SQL Server 2000 Developer Edition, Microsoft SQL Server 2000 Enterprise Edition

Comentarios