2009-05-06 42 views
17

Siempre he pensado que para conectarse al servidor SQL mediante la autenticación de Windows con credenciales explícitamente especificadas, debe iniciar sesión, suplantar y luego conectarse.Base de datos + Autenticación de Windows + Nombre de usuario/Contraseña?

Me parece que this link sugiere que es posible conectarse al servidor SQL sin toda esta molestia, simplemente especificando "uid = ...; pwd = ..." en la cadena de conexión. Probé este método solo para asegurarme de que no funciona, y - mira y mira - no fue así. Si esa publicación de blog no estuviera en msdn.com, simplemente la habría descartado como una conversación de novato, pero lo es.

¿Alguien tiene una idea de lo que me estoy perdiendo?

EDIT1: Muchos encuestados entendieron mal a qué me refería. Aquí hay una copia/pega de lo que estaba hablando. Es no SQL integrado, ni se trata de una suplantación ASP.NET hecho por IIS:

string sql4 = String.Format(
    @"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);  
// Database + Windows Authentication + Username/Password 
+0

que es probable que para inicios de sesión de SQL Server. – DForck42

+0

para postular: cadena sql4 = String.Format (@ "Data Source = {0}; Integrated Security = SSPI; uid = ; pwd = ", servidor); // base de datos de autenticación de Windows + + nombre de usuario/contraseña – galets

Respuesta

27

Hay dos tipos distintos de seguridad con SQL Server. "Autenticación de Windows" y "Autenticación de SQL Server". Cuando ves uid y pwd estás viendo lo último. El uid en este caso no es un principal de Windows, el sistema operativo no sabe nada al respecto.

Así que la respuesta a su pregunta es no, no puede pasar el nombre de usuario y la contraseña de Windows en la cadena de conexión para iniciar sesión en SQL Server.

+0

Integrado de Seguridad = SSPI [indica autenticación NT]; uid = ; pwd = [auth indica sql] - las dos opciones en una línea, ¿por qué utilizar lo que en este ejemplo? – galets

+2

No es un ejemplo. Es un articulo Ve a leer el artículo y lo entenderás. –

+0

Sí ... Supongo que simplemente no he leído el artículo con cuidado :( – galets

3

Depende - si se conecta desde una línea de comandos o Winforms aplicación directamente a su SQL Server, especificar "Integrated Seguridad = SSPI; " y luego use sus credenciales de Windows como credenciales de inicio de sesión, O especifique "user id = ....; pwd = ....." - pero eso es entonces un inicio de sesión SQL - NO su inicio de sesión de Windows.

Menciona "suplantar y luego conectar", lo que parece indicar que ASP.NET es una historia totalmente diferente. Si se hace pasar, básicamente está usando sus credenciales de Windows, p. el servidor web lo "personificará" e iniciará sesión como usted (usando sus credenciales de Windows). En ese caso, nuevamente, no debe especificarse "uid = ....; pwd = ....." (si lo es, se ignorará).

Como ese enlace que usted menciona muestra claramente: si puede conectarse directamente, y especifica "Integrated Security = SSPI;", esto tiene prioridad sobre cualquier uid = ...; pwd = .... que podría también especificado e inicia sesión con sus credenciales de Windows; esas piezas extra uid = ...; pwd = .... son ignoradas.

Marc

2

El artículo y el punto en cuestión se refiere a la seguridad de SQL, no la seguridad integrada. Puede pasar las credenciales para un usuario de SQL e iniciar sesión de esta manera si la autenticación SQL (modo mixto) está habilitada. Si el servidor SQL está configurado para usar seguridad integrada solo entonces esto no funcionará. Tampoco funcionará para permitir el inicio de sesión utilizando las credenciales de inicio de sesión de Windows.

1

En nuestra tienda, rutinariamente usamos cadenas de conexión como usted describe. No hay problema. Pero su base de datos del servidor sql debe estar configurada para usar seguridad sql, no autenticación de Windows.

Una cadena de conexión de muestra (de web.config) en nuestra aplicación se parece a:

<connectionStrings> 
<add name="ConfigurationData" connectionString="server=DevServer; 
database=travel_expense_management_dv;uid=userid;pwd=password!;" 
providerName="System.Data.SqlClient" /> 
</connectionStrings> 

Por otro lado, el gurú DBA para nuestra tienda me ponga una base de datos personales en el servidor principal que tenía seguridad integrada con mi inicio de sesión de Windows.No necesitaba uid y pwd porque me quitaba la información de autenticación del contexto.

0

Sí, como usted dice, el artículo menciona lo siguiente:

string sql4 = String.Format(@"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);  // Database + Windows Authentication + Username/Password 

Pero si se lee con cuidado unas líneas más adelante, se dice lo siguiente:

cadena sql4 -> Registros de la conexión de Windows , es decir. tiene prioridad sobre el nombre de usuario/contraseña.

:)

0

Esto es muy antiguo, pero tal vez alguien tiene el mismo problema.

Usted puede conectarse a través deWindowsAuthentication y de especificar el ID de usuario y contraseña en la cadena de conexión, pero no en todos los dispositivos. Puede lograr esto, por ejemplo, en dispositivos WinCE (https://technet.microsoft.com/en-us/library/aa275613(v=sql.80).aspx).

No sé si puede hacer lo mismo en otro sistema operativo simplemente con la cadena de conexión (sin hacer la suplantación).

Espero que ayude.

0

solo una contribución también para algunos que todavía tenían problemas como este. Según mi experiencia, si no especifica ningún usuario/contraseña en su conectividad, se conectará automáticamente a db mediante la autenticación de Windows. Lo que significa que obtendrá el ID de usuario y su credencial del usuario que inició sesión en la máquina. El sistema le permitirá conectarse a la base de datos si identifica que su ID de usuario existe/creado en la base de datos. Pero una vez que especifique su nombre de usuario y contraseña en su conectividad que pasar por alto la autenticación de Windows y autenticación del servidor SQL en lugar utilización.

Cuestiones relacionadas