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

Cuando bash conectarme a una instancia de SQL Server 2008 con 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 usar con la autenticación de Windows. (Microsoft SQL Server, error: 18452)

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

¿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 pasó a mí) … es que la contraseña del usuario expira. No me di cuenta de esto hasta que traté de acceder de manera remota al servidor real y me pidieron que cambiara mi contraseña.

Para mí, esto sucedió cuando edité un archivo de drivers/etc/hosts blanco y agregué una entrada para un sitio web local, pero olvidé agregar 127.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.

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

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

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

u otra configuración específica de red / servidor / AD / máquina de seguridad

Para cualquier otra persona que se encuentre con esto, tuve esto en mi archivo hosts:

 127.0.0.1 localhost 127.0.0.1 customname 

y yo necesitaba que fuera esto:

 127.0.0.1 localhost 127.0.0.1 localhost customname 

Tuve este problema para una instancia de servidor en mi equipo local y descubrí que era porque estaba señalando 127.0.0.1 con algo más que “localhost” en mi archivo de hosts. Hay dos maneras de solucionar este problema en mi caso:

  1. Borre la entrada ofensiva señalando a 127.0.0.1 en el archivo hosts
  2. use “localhost” en lugar del otro nombre que en el archivo hosts que apunta a 127.0.0.1

* Esto solo funcionó para mí cuando estaba ejecutando la instancia de servidor sql en mi casilla local e bash acceder 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 estar conectado, si eso es lo que se requiere.

intente utilizar un inicio de sesión válido diferente con 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 los roles que quería usar para la base de datos SQL. Y también debido a un bash de contraseña incorrecta a través de la cuenta de locking del problema de copiar y pegar.

De acuerdo, completamente por ahí respuesta de mí. 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 se pudo conectar 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 estaría feliz de iniciar sesión en SSMS en el mismo servidor sql. Recibí un mensaje de error mejor de ODBC también 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 al observar algunas capturas de pantalla que le envié. ¡El problema fue que el reloj del controlador de dominio estaba mal configurado! No lo podía creer. Los servidores están configurados para redes de Host Only, por lo que no tienen Internet para sincronizar el reloj. Eso también explica por qué retroceder 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 de invitados con el host.

Hay una configuración en el controlador jTDS llamada USENTLMV2 que está establecida en falso de forma predeterminada. Configurar esto en ‘true’ en mi software db (DBVisualizer) lo resolvió.

Otro escenario en el que puede ver esto es cuando intenta conectarse a otro servidor SQL desde una sesión SSMS que ya inició sesión mientras cambió su contraseña. La secuencia de eventos puede ser algo así como:

  1. RDP para Servidor-A (su Servidor SQL), 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 de RDP en el Servidor A y, a través de SSMS, intente agregar otra base de datos en un grupo de disponibilidad de AlwaysOn existente. Cuando se conecta a réplicas obtiene un “dominio no confiable” -login-error

Para resolverlo, simplemente finalice sesión y vuelva a iniciar sesión

He intentado iniciar sesión en SQL Server 2008 desde una cuenta de dominio. SQL Server 2008 está alojado en una computadora diferente del grupo de trabajo que no es 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 computadora | Más … (botón) e ingrese el “sufijo DNS principal de esta computadora” (estaba en blanco, ingrese el sufijo deseado para su red) y marque la casilla “Cambiar el sufijo DNS principal cuando la membresía de dominio cambie”. Esto permitió completar el proceso de Autenticación de Windows 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 para el usuario predeterminado de SQL

esto me pasó hace un par de minutos cambiando a un nuevo controlador de dominio …

Puede estar mal informado 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 net config workstation , parece que el nombre del usuario es spc01 . Parece que alguien renombró al usuario, pero el nombre interno permaneció sin cambios.

Sin saber cómo arreglar el nombre de usuario de Windows (y el nombre de la carpeta en C:\Users , que también hace referencia al nombre interno original), agregué un nuevo usuario en mi servidor de db.

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 BD tenía el conjunto de banderas “El usuario debe cambiar la contraseña en el siguiente 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”. Eliminar texto en “Sufijo DNS para esta conexión”.

Tampoco pude conectarme remotamente al servidor SQL. Tanto el servidor SQL como el servidor remoto estaban en el mismo dominio. Y me habían pedido un cambio de contraseña algunos días antes. Reiniciar tanto el servidor SQL como el servidor remoto al que intentaba acceder me dejó el truco.

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

En mi caso, el servidor había sido desactivado en el controlador de dominio. Entré en la OU de COMPUTERS en el directorio Active, hice clic con el botón derecho en el servidor, lo habilité y luego hice un gpupdate / force desde el servidor SQL. Tardó un momento, pero finalmente funcionó.

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

Ubicación del archivo 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 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 correlacionara con mi nuevo nombre de servidor para SQL Connection (IT Security acababa de hacer un cambio de nombre en mi caja de desarrollo.

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úrate de tener una entrada como a continuación

 127.0.0.1 localhost 127.0.0.1 localhost servername 

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

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

Estaba usando un alias para una instancia de SQL Server que apuntaba a “127.0.0.1”. Cambiarlo a “localhost” hizo el truco.

Si su servidor Sql se está ejecutando en un servidor que no es parte de un dominio y en la cadena de conexión utiliza un nombre de dominio completamente calificado (por ejemplo, xyz.mypc.com) con Seguridad integrada = Verdadero, es posible que tenga que cambiar a usar cualquiera la dirección IP, MachineName (SERVER01) o el punto (.) en caso de que esté alojado localmente.

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