sql-server - ejemplos - django

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 (30)

Cuando intento 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

"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

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.

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.

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

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 ...

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

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".

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ó.

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.

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.

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> era deshabilitar la red inalámbrica (la máquina también estaba conectada a la LAN con cable).

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.

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 ...

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:

RDP para Servidor-A (su Servidor SQL), abra SSMS e inicie sesión
RDP a Server-B en el mismo dominio y cambie su contraseña
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

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

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 intento de contraseña incorrecta a través de la cuenta de bloqueo del problema de copiar y pegar.

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

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.

Reemplacé la cadena de conexión y comenzó a funcionar

main_sqlconnection = New SqlConnection("Data Source=Server1/SQLEXPRESS;Initial Catalog=Master;Trusted_Connection=True")

main_sqlconnection = New SqlConnection("Data Source=Server1/SQLEXPRESS;Initial Catalog=Master;User ID=ARM;Password=1;")

Creé la cuenta User ID=User;Password=1; en Microsoft SQL Server Management Studio: haga clic en Seguridad y agregue un nuevo usuario.

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

Edite el registro de Windows: Inicio -> Ejecutar> Regedit
Navegue a: HKLM / System / CurrentControlSet / Control / LSA
Agregue un valor DWORD llamado "DisableLoopbackCheck"
Establezca este valor en 1

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.

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:

Borre la entrada ofensiva señalando a 127.0.0.1 en el archivo hosts
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 intento acceder desde la misma máquina.

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"

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

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".

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 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

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.

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