¿Cómo puedo hacer que mi servidor vinculado funcione con la autenticación de Windows?

Estoy tratando de obtener un servidor vinculado al Servidor A creado en otro servidor, el Servidor B usando "Realizar usando el contexto de seguridad actual del inicio de sesión" en un entorno de dominio. Leí que necesitaría tener SPN creados para las cuentas de servicio que ejecutan SQL Server en cada uno de los servidores para habilitar Kerberos. Lo hice y ahora ambos muestran que el esquema de autenticación es Kerberos, sin embargo, todavía me enfrento al error:

"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'".

En Active Directory, puedo ver que la cuenta de servicio para ServerB es confiable para la delegación a MSSQLSvc, pero noté que la cuenta de servicio para ServerA aún no tiene "confiar en este usuario para la delegación" habilitado. ¿El servidor de destino también necesita tener esa opción habilitada? ¿Es necesario algo más para poder usar el inicio de sesión de Windows actual para usar un servidor vinculado?

Cada máquina de la cadena, desde su escritorio hasta el servidor al que está llamando, debe estar habilitada para Kerberos para que la confianza avance más allá del primer salto. Entonces, sí, el servidor necesita confiar en el usuario para la delegación.

El "Error de inicio de sesión para el usuario 'NT AUTHORITY \ ANONYMOUS LOGON'" casi siempre indica un problema de delegación.

• Su cuenta de Windows debe tener acceso a ServerA y ServerB.
• No debe tener la configuración "La cuenta es confidencial y no se puede delegar".
• Tanto el Servidor A como el Servidor B deben tener su propio SPN registrado.
• Los servidores deben ser TCP / IP o tuberías con nombre conectadas.

El artículo de los Libros en pantalla de SQL Server que ofrece más detalles es "Configuración de servidores vinculados para la delegación": http://msdn.microsoft.com/en-us/library/ms189580(v=sql.105).aspx

Dos cosas aquí:

1. Cuando utilice un servidor vinculado sin asignar el inicio de sesión del servidor local al servidor remoto, no inicie sesión en una máquina remota y utilice un inicio de sesión de Windows para ejecutar scripts. El problema del doble salto entra en juego ya que utiliza la suplantación.

2. Además, deberá configurar el DTC local a través de DCOMCNFG para la comunicación. Ver imagen adjunta.

(DCOMCNFG -> Servicios de componentes -> Computadoras -> Mi computadora -> Coordinador de transacciones distribuidas -> LocalDTC -> Propiedades -> Seguridad)