24

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

 Forest1    Forest2 
    / \     | 
Domain1  Domain2  Domain3 

objetos se organizan en los siguientes dominios:

Forest1.Domain1

  • Usuarios
  • grupos globales

F orest1.Domain2

  • instancia de SQL Server
  • grupos locales de dominio (que sirven como inicios de sesión)

Forest2.Domain3

  • Usuarios
  • grupos globales

Todos mis usuarios existen en Domain1 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 se agrega un usuario en Domain1 a un grupo local de dominio en Domain2 e intenta conectarse usando el protocolo TCP/IP para la instancia de SQL Server, recibe el siguiente mensaje de error:

Cannot connect to <instance>. Login failed for user 'Domain1\userName'. (Microsoft SQL Server, Error: 18456)

Otras cosas que he intentado:

  • Si añado al usuario como un inicio de sesión explícitamente, se puede conectar.

  • Si añado un grupo global de Domain1 que el usuario es un miembro como un inicio de sesión explícitamente, se puede conectar.

  • Si añado un grupo global de Domain1 que el usuario es un miembro como miembro del grupo Domain2 dominio local utilizado como un inicio de sesión, no se puede conectar .

  • EDIT: Si añado el grupo local Domain2 dominio al grupo de usuarios Disminuir nivel de escritorio en el servidor Domain2 que aloja la instancia de SQL Server, el usuario Domain1 puede conectarse correctamente al servidor - que también puede conectarse a la instancia localmente como el usuario Domain1 (solo que no de forma remota).

  • EDIT: Si añado el grupo local Domain2 dominio a un grupo de servidores local y crear un inicio de sesión de SQL Server para ese grupo de servidores local, el usuario Domain1 todavía no puede conectarse a la instancia remota.

  • EDIT: Si cambio el protocolo de red de conexión en "canalizaciones", el usuario puede conectarse correctamente Domain1 forma remota.


Por lo que entiendo (referencia a estos artículos de TechNet: Group Scope y Nesting Groups), el grupo de dominio debe ser un grupo local de dominio con el fin de incluir a usuarios de ambas Domain1 y Domain3.

¿Cómo puedo utilizar un grupo de dominio como un inicio de sesión de SQL Server mediante la autenticación de Windows de tal manera que el grupo de dominio puede contener usuarios, tanto de Domain1 y Domain3 y los usuarios pueden conectarse de forma remota a través de TCP/IP?

NOTAS MÁS

  • la cuenta de servicio de SQL Server que se denomina instancia es una cuenta de usuario en Domain1
  • de SPN se han añadido a la cuenta de servicio (que incluye el nombre del servidor de alias o nombres)

ACTUALIZACIÓN

Parece que la modificación de la cuenta del servicio de instancia de SQL Service en Domain2 ha resuelto el problema. Investigaré más a fondo y publicaré mis hallazgos.

Respuesta

16

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

El Problema - Explicación

De lo que puedo decir (también con la ayuda de un representante de Microsoft), debido a que la cuenta de servicio era originalmente un usuario Domain1, no podía determinar qué grupos de dominio del usuario que se conecta locales es miembro de cuando el usuario se está autenticando a través de Kerberos. El principal motivo por el que se trató de un problema de Kerberos fue cuando me conecté con éxito utilizando "Canalizaciones con nombre", ya que utiliza la autenticación NTLM.

solución global

Para ponerlo todo junto, añadir con éxito a los usuarios de Domain1 y Domain3 como miembros de grupos en Domain2 para que los grupos se pueden utilizar como inicios de sesión de SQL Server con la autenticación de Windows, aquí está una lista de los requisitos (o al menos alentado fuertemente):

  1. relaciones de confianza establecida entre los dominios
    1. Como mínimo, 1 confianzas unidireccionales se debe configurar para que Domain2 fideicomisos Domain1 y Domain3
  2. Grupos en Domain2 debe estar al alcance "de dominio local"
    1. Esto es lo que puede añadir usuarios y grupos de Domain1 y Domain3
    2. Ver here para obtener más información
  3. uso de SQL Server Confi Gestor de configuración para designar un Domain2 usuario no administrativo como la identidad de cuenta de servicio
    1. MSDN documentos por qué el uso se puede preferir una cuenta de usuario de dominio
    2. A pesar de que el gestor de configuración se supone que añadir usuarios al local de SQL Server 2005 específica grupos para ti (es decir, SQLServer2005MSSQLUser $ MY_MACHINE $ MY_INSTANCE), encontré algunas instancias en las que este no era el caso. Por lo tanto, solo verifique sus grupos locales para asegurarse de que se hayan actualizado adecuadamente con su cuenta de usuario Domain2.
    3. Aunque la configuración de SQL Server debe asignar automáticamente los permisos apropiados para sus grupos locales, de nuevo, me encontré con algunas instancias en las que este no era el caso. Si esto le sucede, puede consultar este artículo MSDN junto con el artículo mencionado anteriormente para conocer los requisitos de permiso.
  4. Configurar un nombre principal de servicio (SPN) para el anfitrión instancia de SQL Server (incluyendo cualquier alias) y la cuenta Domain2 servicio
    1. El SPN se requiere para la autenticación mutua entre el cliente y el host de servidor
    2. Consulte este artículo para obtener más información TechNet
  5. Dependiendo de cómo se va a utilizar la suplantación, es posible que desee habilitar la cuenta de servicio a Domain2 confianza para delegación
    1. Ver este artículo TechNet para obtener más información
  6. habilitar las conexiones remotas para la instancia de servicio de SQL
  7. Por último, cree inicios de sesión para Domain2 grupos deseados y cualquier Domain1 o Domain3 miembros deberían poder para conectarse remotamente!

Nota

Como siempre con cualquier actividad de red remoto, revisar sus cortafuegos para asegurar que sus puertos de SQL Server no están bloqueados. Aunque el puerto predeterminado es 1433, verifique que su puerto esté despejado.

1

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

Mi entorno,

Forest 1 (Domain1) --- TRUST --- Forest 2(Domain2)

que tienen una cuenta de servicio en Domain2 intentar iniciar sesión en el servidor SQL en Dominio1 mediante la autenticación de Windows.

Y aparece el siguiente mensaje de error.

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)

La solución es bastante simple, en domain1, abiertos dominios de Active Directory y confianzas herramienta,

Trusts -> outgoing trusts -> properties -> authentication -> change to "Forest-wide authentication"

Mi problema resuelto.

Cuestiones relacionadas