Inicios de sesión de SQL Server entre dominios mediante la autenticación de Windows

Como mencioné en la actualización de mi pregunta, cambiar la cuenta de servicio para que esté en Domain2 resolvió el problema. Entonces, ¿qué estaba pasando?

El Problema - Explicado

Por lo que puedo decir (también con la ayuda de un representante de Microsoft), porque la cuenta de servicio era originalmente un Domain1 usuario, no pudo determinar de qué grupos locales de dominio es miembro el usuario que se conecta cuando el usuario se está autenticando a través de Kerberos. La pista principal de que se trataba de un problema de Kerberos fue cuando me conecté con éxito mediante "Conexiones con nombre", ya que utiliza la autenticación NTLM.

Solución general

Para unirlo todo, para agregar correctamente usuarios de Domain1 y Domain3 como miembros de grupos en Domain2 para que los grupos se puedan usar como inicios de sesión de SQL Server con autenticación de Windows, aquí hay una lista de requisitos (o al menos se recomienda encarecidamente):

1. Relaciones de confianza establecidas entre los dominios
   1. Como mínimo, se deben configurar confianzas unidireccionales para que Domain2 confía en Domain1 y Domain3
2. Grupos en Domain2 debe estar en el ámbito "Dominio local"
   1. Esto es para que pueda agregar usuarios y grupos desde Domain1 y Domain3
   2. Ver aquí para más información
3. Utilice el Administrador de configuración de SQL Server para designar un Domain2 no administrativo usuario como la identidad de la cuenta de servicio
   1. MSDN documenta por qué se puede preferir usar una cuenta de usuario de dominio
   2. Aunque se supone que el administrador de configuración agrega usuarios a grupos locales específicos de SQL Server 2005 (es decir, SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), me encontré con algunos casos en los que este no era el caso. Así que solo revisa tus grupos locales para asegurarte de que se hayan actualizado correctamente con tu Domain2 cuenta de usuario.
   3. Aunque la configuración de SQL Server debería asignar automáticamente los permisos apropiados para sus grupos locales, nuevamente, me encontré con algunos casos en los que este no era el caso. Si esto le sucede, puede consultar este artículo de MSDN junto con el artículo mencionado anteriormente para conocer los requisitos de permisos.
4. Configure un nombre principal de servicio (SPN) para el host de la instancia de SQL Server (incluido cualquier alias) y el Domain2 cuenta de servicio
   1. El SPN es necesario para la autenticación mutua entre el cliente y el host del servidor
   2. Consulte este artículo de TechNet para obtener más información
5. Dependiendo de cómo pretenda utilizar la suplantación de identidad, es posible que desee habilitar el Domain2 cuenta de servicio de confianza para la delegación
   1. Consulte este artículo de TechNet para obtener más información
6. Habilitar conexiones remotas para la instancia del Servicio SQL
7. Finalmente, cree inicios de sesión para el Domain2 deseado grupos y cualquier Domain1 o Domain3 ¡los miembros deberían poder conectarse de forma remota!

Nota

Como siempre con cualquier actividad de red remota, verifique sus firewalls para asegurarse de que sus puertos de SQL Server no estén bloqueados. Aunque el puerto predeterminado es 1433, verifique que su puerto esté limpio.