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

Question

J'ai toujours pensé que pour vous connecter au serveur SQL en utilisant l'authentification Windows avec des informations d'identification explicitement spécifiées, vous devez vous connecter, emprunter l'identité, puis vous connecter.

Il me semble que this link suggère qu'il est possible de se connecter au serveur SQL sans tous ces tracas, simplement en spécifiant "uid = ...; pwd = ..." dans la chaîne de connexion. J'ai testé cette méthode juste pour être sûr que ça ne marche pas, et - voilà, ce n'est pas le cas. Si ce post de blog n'était pas sur msdn.com, je l'aurais simplement rejeté comme une discussion de noob, mais c'est le cas.

Est-ce que quelqu'un a une idée de ce qui me manque?

EDIT1: De nombreux répondants ont mal compris ce dont je parlais. Voici un copier/coller de ce dont je parlais. Il est pas SQL intégré, ni c'est une usurpation d'identité ASP.NET faite par IIS:

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

Answer 1

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'uid dans ce cas n'est pas un principal Windows - l'OS ne sait rien à ce sujet. Donc, la réponse à votre question est: no, vous ne pouvez pas passer le nom d'utilisateur et le mot de passe Windows dans la chaîne de connexion pour vous connecter à SQL Server.

Answer 2

Cela dépend - si vous vous connectez à partir d'une ligne de commande ou une application Winforms directement sur votre SQL Server, soit vous spécifiez « Integrated Sécurité = SSPI; " puis utilisez vos informations d'identification Windows en tant qu'identifications de connexion, OU vous spécifiez "id utilisateur = ....; pwd = ....." - mais c'est alors une connexion SQL - pas votre connexion Windows. Vous mentionnez "impersonate et ensuite connect" - ce qui semble indiquer ASP.NET - c'est une histoire totalement différente à nouveau. Si vous personnifiez, vous utilisez essentiellement vos informations d'identification Windows, par ex. le serveur Web vous "usurpe" et vous connecte comme vous (en utilisant vos informations d'identification Windows). Dans ce cas, encore une fois, pas de "uid = ....; pwd = ....." doit être spécifié (si c'est le cas, il sera ignoré). Comme ce lien que vous avez mentionné montre clairement - si vous pouvez vous connecter directement, et vous spécifiez "Integrated Security = SSPI;", alors cela a préséance sur tout uid = ...; pwd = .... que vous pourriez également spécifié et vous connecte en utilisant vos informations d'identification Windows; ces uid supplémentaires = ...; pwd = .... les pièces sont ignorées.

Marc

Answer 3

L'article et le point en question a trait à la sécurité SQL, pas de sécurité intégrée. Vous pouvez transmettre les informations d'identification pour 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 autoriser la connexion à l'aide des informations d'identification Windows.

Answer 4

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 SQL Server doit être configurée pour utiliser la sécurité SQL, et non l'authentification Windows.

Une chaîne de connexion de l'échantillon (de web.config) dans notre application ressemble à:

<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 de DBA pour notre boutique me mis en place une base de données personnelle sur le serveur principal qui avait sécurité intégrée avec ma connexion Windows.Je n'avais pas besoin d'uid et de pwd parce qu'il a fallu mes informations d'authentification du contexte.

Answer 5

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, il dit plus tard ceci:

chaîne sql4 -> Journaux avec connexion Windows , c'est à dire. a priorité sur le nom d'utilisateur/mot de passe.

:)

Answer 6

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

Vous pouvez vous connecter en utilisantWindowsAuthentication et spécifiant l'ID utilisateur et mot de passe sur votre chaîne de connexion, mais pas sur tous les appareils. Vous pouvez réaliser ceci par exemple sur les périphériques WinCE (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 juste avec la chaîne de connexion (sans faire l'usurpation d'identité).

Espérons que ça aide.

Answer 7

juste une contribution aussi pour certains qui rencontraient encore un problème comme celui-ci. Basé sur mon expérience si vous ne spécifiez aucun utilisateur/mot de passe dans votre connectivité, il se connectera automatiquement à DB en utilisant l'authentification Windows. Ce qui signifie qu'il obtiendra l'ID utilisateur et les informations d'identification de l'utilisateur qui s'est connecté à la machine. Le système vous permettra de vous connecter à la base de données si elle identifie que votre ID utilisateur existe/a été créé dans la base de données. Mais une fois que vous spécifiez votre ID utilisateur et votre mot de passe dans votre connectivité, il contourne l'authentification Windows et utilise plutôt l'authentification du serveur SQL.