Error de inicio de sesión de autenticación de Windows de SQL Server 2008: el inicio de sesión proviene de un dominio que no es de confianza

Cuando intento conectarme a una instancia de SQL Server 2008 mediante Management Studio, aparece el siguiente error:

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

Puedo iniciar sesión usando la autenticación SQL sin problema. He recibido este error de repente. Tengo activada la autenticación de modo mixto.

¿Alguien tiene alguna experiencia con esto?

Información adicional: versión de 64 bits de SQL Enterprise Edition en Windows 2003 Server

Otra razón por la que esto podría suceder (me acaba de pasar) ... es que la contraseña del usuario caduca. No me di cuenta de esto hasta que intenté acceder de forma remota al servidor real y se me pidió que cambiara mi contraseña.

Para mí, esto sucedió cuando edité un drivers/etc/hostsarchivo en blanco y agregué una entrada para un sitio web local, pero olvidé agregar127.0.0.1 localhost

El problema fue causado por un servidor de Active Directory inactivo, que por supuesto no pudo autenticar la cuenta de Windows. Gracias por su asistencia.

Para cualquier otra persona que se encuentre con esto, tenía esto en mi archivo de hosts:

127.0.0.1   localhost
127.0.0.1   customname

y necesitaba que fuera esto:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"El problema fue causado por un servidor de Active Directory inactivo, que por supuesto no pudo autenticar la cuenta de Windows"

No lo es "por supuesto, porque si AD no está disponible, la autenticación Kerberos recurre a NTLM (las credenciales de la cuenta de dominio se almacenan en caché localmente, uno puede iniciar sesión con él incluso si AD / Kerberos no está disponible). Supongo que posiblemente tenga 2 condiciones simultáneas para que esto suceda:

• SQL Server no es local (en otra máquina)
• La confianza está configurada como "solo Kerberos"

u otras configuraciones específicas de red / servidor / AD / máquina de seguridad

Tuve este problema para una instancia de servidor en mi máquina local y descubrí que era porque estaba apuntando a 127.0.0.1 con algo diferente a "localhost" en mi archivo de hosts. Hay dos formas de solucionar este problema en mi caso:

1. Borre la entrada ofensiva que apunta a 127.0.0.1 en el archivo hosts
2. use "localhost" en lugar del otro nombre que en el archivo de hosts que apunta a 127.0.0.1

* Esto solo funcionó para mí cuando estaba ejecutando la instancia del servidor SQL en mi caja local e intentaba acceder a ella desde la misma máquina.

Asegúrese de no estar conectado a una VPN en otro dominio \ usuario . O, por el contrario, asegúrese de que está conectado, si eso es lo que se requiere.

Solucioné este problema en la máquina deshabilitando la configuración de verificación de bucle invertido:

1. Edite el registro de Windows: Inicio -> Ejecutar> Regedit
2. Vaya a: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Agregue un valor DWORD llamado "DisableLoopbackCheck"
4. Establezca este valor en 1

intente usar un inicio de sesión válido diferente usando el comando RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Para mí, fue porque no agregué la cuenta para tener roles que quería usar en la base de datos SQL. Y también debido a intentos de contraseña incorrectos a través del problema de copiar y pegar que bloquea la cuenta.

Está bien, completamente fuera de mi respuesta. Recibí este error de un entorno de desarrollo alojado en VM VirtualBox. Tres servidores; SharePoint, SQL DB y controlador de dominio. El servidor de SharePoint no pudo conectarse a la base de datos de configuración. Todavía podría conectarme a través de ODBC para la autenticación Sql usando la cuenta SA pero no la autenticación de Windows. Pero ese usuario iniciaría sesión felizmente en SSMS en el servidor SQL. También recibí un mejor mensaje de error de ODBC y también al verificar los mensajes de inicio de sesión fallidos en el servidor SQL:

select text from sys.messages where message_id = '18452' and language_id = 1033

No puedo atribuirme el mérito de esto porque le pedí ayuda a uno de nuestros administradores de sistemas empresariales y me lo diagnosticó en unos 5 minutos de mirar algunas capturas de pantalla que le envié. ¡El problema era que el reloj del controlador de dominio estaba configurado incorrectamente! No lo podía creer. Los servidores están configurados para redes de solo host, por lo que no tienen Internet para sincronizar el reloj. Eso también explica por qué volver a una instantánea anterior cuando sé que el sistema estaba funcionando no resolvió el problema.

Editar: la instalación de Guest Additions en el servidor sincroniza el reloj del invitado con el host.

Hay una configuración en el controlador jTDS llamada USENTLMV2 que se establece en falso de forma predeterminada. Establecer esto en 'verdadero' en mi software db (DBVisualizer) lo resolvió.

Otro escenario en el que puede ver esto es cuando está intentando conectarse a otro servidor SQL desde una sesión SSMS que ya estaba conectada mientras cambiaba su contraseña. La secuencia de eventos podría ser algo como:

1. RDP a Server-A (su SQL Server), abra SSMS e inicie sesión
2. RDP a Server-B en el mismo dominio y cambie su contraseña
3. Regrese a la sesión RDP en el servidor A y, a través de SSMS, intente agregar otra base de datos a un grupo de disponibilidad AlwaysOn existente. Cuando se conecta a las réplicas, aparece un "dominio no confiable" -login-error

Para resolverlo, simplemente cierre la sesión y vuelva a iniciarla

Es posible que lo engañen sobre el nombre de usuario que usa localmente. Ese fue mi caso en Windows 10 Home. Cuando miro a los usuarios en el panel de control, veo el nombre usrpc01 . Sin embargo, cuando escribonet config workstation , parece que el nombre del usuario es spc01 . Parece que alguien cambió el nombre del usuario, pero el nombre interno se mantuvo sin cambios.

Sin saber cómo arreglar el nombre de usuario de Windows (y el nombre de la carpeta debajo C:\Users, que también se refiere al nombre interno original), agregué una nueva cuenta de usuario en mi servidor de base de datos.

He intentado iniciar sesión en SQL Server 2008 desde una cuenta de dominio. SQL Server 2008 está alojado en un equipo de grupo de trabajo diferente que no forma parte del dominio. Por extraño que parezca, en el servidor del grupo de trabajo donde se ejecuta SQL Server 2008, tuve que ir a Propiedades del sistema | Nombre de la computadora (pestaña) | Cambiar (botón) | Cambio de nombre de equipo | Más ... (botón) e ingrese el "Sufijo DNS primario de esta computadora" (estaba en blanco, así que ingrese el sufijo deseado para su red) y marque la casilla "Cambiar el sufijo DNS primario cuando cambie la membresía del dominio". Esto permitió que el proceso de autenticación de Windows se completara al iniciar sesión en SQL Server 2008.

Tuve que usar netonly para que esto funcione en Windows moderno:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Otra razón> alguien cambió la contraseña del usuario SQL predeterminado

esto me sucedió hace un par de minutos al cambiar a un nuevo controlador de dominio ...

Tuve una entrada incorrecta en el archivo de hosts en C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Asegúrese de tener una entrada como la siguiente

127.0.0.1   localhost
127.0.0.1   localhost   servername

Estaba usando un alias para una instancia de SQL Server que apuntaba a "127.0.0.1". Cambiarlo a "localhost" en su lugar funcionó.

Si su servidor Sql se ejecuta en un servidor que no es parte de un dominio y en la cadena de conexión usa un nombre de dominio completamente calificado (por ejemplo, xyz.mypc.com) con Integrated Security = True, es posible que deba cambiar a usar cualquiera la dirección IP, MachineName (SERVER01) o el punto (.) en caso de que esté alojado localmente.

Esto funcionó para mí, usar el fqdn resultó en el error anterior.

Para habilitar la autenticación de Windows, ambas computadoras deben estar en el mismo dominio. para permitir que los estudios de gestión pasen las credenciales actuales y se autentiquen en el cuadro SQL

Para mí, tengo que desconectarme (cambiar de grupo de trabajo / dominio) del Dominio y volver a conectarme.

Y otra posible razón: la nueva cuenta local creada en el servidor de base de datos tenía el indicador: "El usuario debe cambiar la contraseña en el próximo inicio de sesión".

Esto es lo que me solucionó: Propiedades de la conexión de red Haga clic en: "Protocolo de Internet versión 4 (TCT / IPv4)". Haga clic en el botón "Propiedades". Haga clic en el botón "Avanzado". Seleccione la pestaña "DNS". Elimina el texto en "Sufijo DNS para esta conexión".

Tampoco pude conectarme de forma remota al servidor SQL. Tanto el servidor SQL como el servidor remoto estaban en el mismo dominio. Y me habían solicitado un cambio de contraseña unos días antes. Reiniciar tanto el servidor SQL como el servidor remoto desde el que estaba tratando de acceder al servidor SQL funcionó para mí.

En nuestro caso, fue el hecho de que el desarrollador estaba ejecutando el grupo de aplicaciones con su propia cuenta y había restablecido su contraseña, pero olvidó cambiarla en el grupo de aplicaciones. Duh ...

En mi caso, el servidor se había deshabilitado en el controlador de dominio. Entré en la unidad organizativa COMPUTERS en el directorio activo, hice clic con el botón derecho en el servidor, lo habilité y luego hice un gpupdate / force desde el servidor SQL. Tomó un momento, pero finalmente funcionó.

En mi caso, en el archivo de host, el nombre de la máquina está codificado con una IP más antigua. Reemplazo la IP anterior por la nueva, el problema está resuelto.

Ubicación del archivo de host

WindowsDrive: \ Windows \ System32 \ drivers \ etc \ hosts

Modificaciones realizadas 159.xx.xx.xxx MachineName

Ninguno de los anteriores funcionó para mí. Lo que tenía que hacer era: En SQL Server Management Studio en la pantalla de inicio de sesión, seleccione Opciones >> En la sección Red cambie el protocolo de red a Canalizaciones con nombre.

Además, lo que tenía que hacer para que funcionara con la <default>configuración era deshabilitar la red inalámbrica (la máquina también estaba conectada a la LAN con cable).

Mi solución fue cambiar el archivo web.config para que se correlacione con mi nuevo nombre de servidor para Conexión SQL (IT Security acababa de cambiar el nombre de netdom en mi cuadro de desarrollo.