sql-server - una - privilegios de usuarios en sql server

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

Question

Tengo una instancia con nombre de SQL Server 2005 que utiliza la autenticación de Windows con grupos de dominio que sirven como inicios de sesión. Las estructuras de dominio son las siguientes:

 Forest1 Forest2
/ / |
Domain1 Domain2 Domain3

Los objetos están organizados en los siguientes dominios:

Bosque1.Dominio1

• Usuarios
• Grupos globales

Bosque1.Dominio2

• Instancia de SQL Server
• Grupos locales de dominio (que actúan como inicios de sesión)

Bosque2.Dominio3

• Usuarios
• Grupos globales

Todos mis usuarios existen en Domain3 y Domain3 pero el cuadro de SQL Server existe en Domain2 . Como tal, mis inicios de sesión son grupos de dominio en Domain2 . Cuando un usuario en Domain1 se agrega a un grupo local de dominio en Domain2 e intenta conectarse mediante el protocolo TCP / IP a la instancia de SQL Server, recibe el siguiente mensaje de error:

No se puede conectar a <instancia>. Error de inicio de sesión para el usuario ''Domain1 / userName''. (Microsoft SQL Server, Error: 18456)

Otras cosas que he probado:

• Si agrego al usuario como un inicio de sesión explícito, él puede conectarse.

• Si agrego un grupo global de Domain1 del cual el usuario es miembro como inicio de sesión explícitamente, puede conectarse.

• Si agrego un grupo global de Domain1 del cual el usuario es miembro como miembro del grupo local de dominio Domain2 usado como inicio de sesión, no puede conectarse.

• EDITAR: Si agrego el grupo local de dominio Domain2 al grupo de usuarios de Demote Desktop en el servidor Domain2 aloja la instancia de SQL Server, el usuario de Domain1 puede conectarse correctamente al servidor. También puedo conectarme a la instancia localmente como usuario de Domain1 (solo no remotamente).

• EDITAR: Si agrego el grupo local de dominio Domain2 a un grupo de servidores locales y creo un inicio de sesión de SQL Server para ese grupo de servidores locales, el usuario de Domain1 aún no puede conectarse a la instancia de forma remota.

• EDITAR: Si cambio el protocolo de red de conexión a "Canalizaciones con nombre", el usuario de Domain1 puede conectarse correctamente de forma remota.

Por lo que entiendo (haciendo referencia a estos artículos de TechNet: Ámbito de grupo y grupos de anidación ), el grupo de dominio DEBE ser un grupo local de dominio para incluir usuarios de Domain1 y Domain3 .

¿Cómo puedo usar un grupo de dominio como inicio de sesión de SQL Server usando la autenticación de Windows de modo que el grupo de dominio pueda contener usuarios tanto de Domain3 como de Domain3 y los usuarios puedan conectarse de forma remota a través de TCP / IP?

Más notas

• La cuenta de servicio para la instancia con nombre de SQL Server es una cuenta de usuario en Domain1
• Se han agregado SPN para la cuenta de servicio (incluidos el nombre del servidor y los nombres de alias)

ACTUALIZAR

El cambio de la cuenta del servicio de instancia de SQL Service para estar en Domain2 parece haber resuelto el problema. Voy a investigar más y publicar de nuevo mis resultados!

Answer 1

Como se mencionó en la actualización de mi pregunta, el cambio de la cuenta de servicio para estar 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), dado que la cuenta de servicio originalmente era un usuario de Domain1 , no pudo determinar de qué grupos locales de dominio es miembro el usuario que se conecta cuando el usuario se autentica a través de Kerberos. La ventaja principal de que esto era un problema de Kerberos era cuando me conecté con éxito utilizando "Canalizaciones con nombre", ya que utiliza la autenticación NTLM.

Solución general

Para Domain3 todo, para agregar con éxito usuarios de Domain3 y Domain3 como miembros de grupos en Domain2 para que los grupos puedan usarse como inicios de sesión de SQL Server con la autenticación de Windows, aquí hay una lista de requisitos (o al menos muy recomendable):

1. Relaciones de confianza establecidas entre los dominios.
   1. Como mínimo, se deben configurar confianzas de una manera para que Domain2 confíe en Domain1 y Domain3
2. Los grupos en Domain2 deben tener el ámbito "Dominio local"
   1. Esto es para que pueda agregar usuarios y grupos de Domain3 y Domain3
   2. Vea aquí para más información
3. Use el Administrador de configuración de SQL Server para designar a un usuario de Domain2 no administrativo como la identidad de la cuenta de servicio
   1. MSDN documenta por qué es preferible usar una cuenta de usuario de dominio
   2. Aunque se supone que el administrador de configuración debe agregar usuarios a grupos específicos de SQL Server 2005 locales para usted (es decir, SQLServer2005MSSQLUser $ MY_MACHINE $ MY_INSTANCE), me encontré con algunos casos en los que este no era el caso. Tan solo revise sus grupos locales para asegurarse de que se hayan actualizado adecuadamente con su cuenta de usuario de Domain2 .
   3. Aunque la configuración de SQL Server debería asignar automáticamente los permisos apropiados para sus grupos locales, nuevamente, me encontré con algunas instancias en las 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 permiso.
4. Configure un Nombre principal del servicio (SPN) para el host de la instancia de SQL Server (incluidos los alias) y la cuenta de servicio Domain2
   1. El SPN es necesario para la autenticación mutua entre el cliente y el servidor host
   2. Vea este artículo de TechNet para más información.
5. Dependiendo de cómo pretenda usar la suplantación, es posible que desee habilitar la cuenta de servicio Domain2 para la delegación.
   1. Vea este artículo de TechNet para más información.
6. Habilitar conexiones remotas para la instancia del servicio SQL
7. Finalmente, cree inicios de sesión para los grupos de Domain2 deseados y cualquier miembro de Domain3 o Domain3 debe 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é libre.

Answer 2

Ok, también resolví el problema en 2017, es difícil encontrar una solución, finalmente, lo descubro solo para mi caso.

Mi entorno

Bosque 1 (Dominio 1) --- CONFIANZA --- Bosque 2 (Dominio 2)

Tengo una cuenta de servicio en Domain2 que intenta iniciar sesión en el servidor SQL en Domain1 mediante la autenticación de Windows.

Y, aparece el siguiente mensaje de error.

Error de inicio de sesion. El inicio de sesión es de un dominio que no es de confianza y no se puede usar con la autenticación de Windows. (Microsoft SQL Server, Error: 18452)

La solución es bastante simple, en domain1, abra la herramienta de confianza y dominios de Active Directory,

Fideicomisos -> Fideicomisos salientes -> propiedades -> autenticación -> cambiar a "autenticación de todo el bosque"

Mi problema resuelto.