web-dev-qa-db-fra.com

Base de données + Authentification Windows + Nom d'utilisateur/Mot de passe?

J'ai toujours pensé que pour pouvoir se connecter au serveur SQL à l'aide de l'authentification Windows avec des informations d'identification explicitement spécifiées, vous devez utiliser LogonUser, Impersonate, puis vous connecter.

Il me semble que ce lien suggère qu'il est possible de se connecter au serveur SQL sans tout ce problème, en spécifiant simplement "uid = ...; pwd = ..." dans la chaîne de connexion. J'ai testé cette méthode pour m'assurer qu'elle ne fonctionnait pas, et voilà, elle ne fonctionnait pas. Si ce billet de blog n’était pas sur msdn.com, je l’aurais simplement qualifié de noob talk, mais c’est vrai.

Quelqu'un a-t-il une idée de ce qui me manque?

EDIT1: Beaucoup de personnes interrogées ont mal compris de quoi je parlais. Voici un copier/coller de ce dont je parlais. Il s'agit de pas SQL intégré, ni d'un emprunt d'identité ASP.NET par IIS:

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

Il existe deux types de sécurité distincts avec SQL Server. "Authentification Windows" et "Authentification SQL Server". Quand vous voyez uid et pwd, vous voyez ce dernier. L'utilisateur dans ce cas n'est pas un principal Windows - le système d'exploitation n'en sait rien.

La réponse à votre question est donc la suivante: non , vous ne pouvez pas transmettre le nom d'utilisateur et le mot de passe Windows dans la chaîne de connexion pour vous connecter à SQL Server.

28
John Saunders

Cela dépend - si vous vous connectez DIRECTEMENT à votre serveur SQL Server depuis une application de ligne de commande ou Winforms, vous pouvez soit spécifier "Sécurité intégrée = SSPI;" puis utilisez vos informations d'identification Windows comme informations d'identification de connexion, OR vous spécifiez "ID utilisateur = ....; pwd = ....." - mais il s'agit alors d'une ouverture de session SQL - PAS de votre ouverture de session Windows.

Vous mentionnez "imiter puis connectez-vous" - cela semble indiquer ASP.NET - c'est encore une histoire totalement différente. Si vous empruntez l'identité, vous utilisez essentiellement vos informations d'identification Windows, par exemple. le serveur Web va vous "emprunter l'identité" et vous connecter en tant que vous (en utilisant vos informations d'identification Windows). Dans ce cas, encore une fois, il n'est pas nécessaire de spécifier "uid = ....; pwd = ....." (sinon, il sera ignoré).

Comme ce lien l'indique clairement, si vous pouvez vous connecter directement et que vous spécifiez "Sécurité intégrée = SSPI;", cette option est prioritaire sur tout uid = ...; pwd = .... que vous pouvez également spécifier et enregistre vous en utilisant vos informations d'identification Windows; ces extra uid = ...; pwd = .... les morceaux sont ignorés.

Marc

3
marc_s

L'article et le point en question concernent la sécurité SQL, pas la sécurité intégrée. Vous pouvez transmettre les informations d'identification d'un utilisateur SQL et vous connecter de cette manière si l'authentification SQL (mode mixte) est activée. Si le serveur SQL est configuré pour utiliser uniquement la sécurité intégrée, cela ne fonctionnera pas. Cela ne fonctionnera pas non plus pour permettre la connexion à l'aide des informations d'identification d'ouverture de session Windows.

2
BlackWasp

Oui, comme vous le dites, l'article mentionne ceci:

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

Mais si vous lisez attentivement quelques lignes plus tard, il dit ceci:

string sql4 -> se connecte avec Windows, par ex. a priorité sur le nom d'utilisateur/mot de passe.

:)

1
Jagan

Dans notre boutique, nous utilisons régulièrement des chaînes de connexion comme vous le décrivez. Pas de problème. Mais votre base de données de serveur SQL doit être configurée pour utiliser la sécurité SQL, et non l'authentification Windows.

Un exemple de chaîne de connexion (de web.config) dans notre application se présente comme suit:

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

D'autre part, le gourou DBA de notre boutique m'a configuré une base de données personnelle sur le serveur principal qui avait intégré la sécurité à ma connexion Windows. Je n'avais pas besoin de uid ni de pwd, car les informations d'authentification étaient extraites du contexte.

1
Cyberherbalist

C'est très vieux, mais peut-être que quelqu'un a le même problème.

Vous pouvez connecter en utilisant Windows Authentification et spécifiant l'ID utilisateur et le mot de passe sur votre chaîne de connexion, mais pas sur tous les appareils. Vous pouvez y arriver par exemple sur WinCE périphériques ( https://technet.Microsoft.com/en-us/library/aa275613(v=sql.80).aspx ). 

Je ne sais pas si vous pouvez faire la même chose sur un autre système d'exploitation uniquement avec la chaîne de connexion (sans utiliser l'emprunt d'identité).

J'espère que ça aide.

0
Alejandro

juste une contribution aussi pour certains qui rencontraient encore un problème comme celui-ci. D'après mon expérience, si vous ne spécifiez aucun utilisateur/mot de passe dans votre connectivité, il se connectera automatiquement à la base de données en utilisant l'authentification Windows. Cela signifie que l'ID utilisateur et les informations d'identification de l'utilisateur qui s'est connecté à la machine seront obtenus. Le système vous permettra de vous connecter à la base de données s'il identifie que votre ID utilisateur existe/a été créé dans la base de données. Mais une fois que vous avez spécifié votre identifiant et votre mot de passe dans votre connectivité, il ignore l’authentification Windows et utilise à la place l’authentification SQL Server. 

0
elena