2009-05-06 24 views
17

Ho sempre pensato che per connettersi al server SQL utilizzando l'autenticazione di Windows con credenziali esplicitamente specificate, è necessario LogonUser, Impersonate, quindi connettersi.Database + Autenticazione di Windows + Nome utente/password?

Mi sembra che this link suggerisca che è possibile connettersi al server SQL senza tutti questi problemi, semplicemente specificando "uid = ...; pwd = ..." nella stringa di connessione. Ho provato questo metodo solo per essere sicuro che non funzioni, e - ecco, non è così. Se quel post sul blog non fosse su msdn.com, lo avrei appena respinto come un discorso da noob, ma lo è.

Qualcuno ha un'idea di cosa mi manca?

EDIT1: Molti intervistati hanno frainteso ciò a cui mi riferivo. Ecco una copia/incolla di ciò di cui stavo parlando. E 'Non SQL integrato, né si tratta di una rappresentazione ASP.NET realizzato da IIS:

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

che è probabilmente per gli accessi al server SQL. – DForck42

+0

QUOTAZIONE: stringa sql4 = String.Format (@ "Origine dati = {0}; Sicurezza integrata = SSPI; uid = ; pwd = ", server); // Database + Autenticazione Windows + Nome utente/password – galets

risposta

27

Esistono due diversi tipi di sicurezza con SQL Server. "Autenticazione di Windows" e "Autenticazione di SQL Server". Quando vedi uid e pwd stai vedendo quest'ultimo. L'uid in questo caso non è un principal di Windows - il sistema operativo non ne sa nulla.

Quindi la risposta alla tua domanda è, no, non è possibile passare il nome utente e la password di Windows nella stringa di connessione per accedere a SQL Server.

+0

Sicurezza integrata = SSPI [indica autenticazione NT]; uid = ; pwd = [indica sql auth] - entrambe le opzioni in una riga, perché dovrebbero utilizzarla in questo esempio? – galets

+2

Non è un esempio. È un articolo Vai a leggere l'articolo e capirai. –

+0

Sì ... Credo di non aver letto l'articolo attentamente :( – galets

3

Dipende - se ci si connette da una riga di comando o WinForms app direttamente ai vostri SQL Server, è specificare "integrato Security = SSPI;" e quindi utilizzare le credenziali di Windows come credenziali di accesso, OPPURE specificare "id utente = ....; pwd = ....." - ma questo è quindi un accesso SQL - NON l'accesso a Windows.

Si parla di "impersonare e quindi connettersi", che sembra indicare ASP.NET, è una storia completamente diversa. Se impersonate, in pratica utilizzate le credenziali di Windows, ad es. il web server "impersonerà" te e si collegherà come te (usando le tue credenziali di Windows). In tal caso, di nuovo, non è necessario specificare "uid = ....; pwd = ....." (se lo è, verrà ignorato).

Come indica chiaramente quel collegamento che hai citato, se puoi collegarti direttamente e specificare "Sicurezza integrata = SSPI;", questo ha la precedenza su qualsiasi uid = ...; pwd = .... che potresti anche specificato e ti accede usando le tue credenziali di Windows; quelli extra uid = ...; pwd = .... i pezzi vengono ignorati.

Marc

2

L'articolo e il punto in questione riguarda la sicurezza di SQL, non integrato di sicurezza. È possibile passare le credenziali per un utente SQL e accedere in questo modo se l'autenticazione SQL (modalità mista) è abilitata. Se il server SQL è configurato per utilizzare solo la sicurezza integrata, questo non funzionerà. Non funzionerà anche per consentire l'accesso utilizzando le credenziali di accesso di Windows.

1

Nel nostro negozio, utilizziamo abitualmente stringhe di connessione come le descrivi. Nessun problema. Ma il tuo database SQL Server deve essere impostato per utilizzare la sicurezza SQL, non l'autenticazione di Windows.

Una stringa di connessione del campione (dal web.config) nella nostra applicazione si presenta come:

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

D'altra parte, il guru DBA per il nostro negozio mi ha istituito un database personale sul server principale che aveva sicurezza integrata con il mio accesso a Windows.Non avevo bisogno di uid e pwd perché ci sono volute le mie informazioni di autenticazione dal contesto.

0

Sì, come dici tu, l'articolo cita questo:

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

Ma se leggete con attenzione poche righe dopo, si dice questo:

stringa sql4 -> log in con il login di Windows , cioè. ha la precedenza sul nome utente/password.

:)

0

Questo è molto vecchio, ma forse qualcuno ha lo stesso problema.

È possibile connettersi utilizzando WindowsAuthentication e specificando ID utente e la password la stringa di connessione, ma non su tutti i dispositivi. È possibile ottenere questo ad esempio su dispositivi WinCE (https://technet.microsoft.com/en-us/library/aa275613(v=sql.80).aspx).

Non so se si può fare la stessa cosa su un altro SO solo con la stringa di connessione (senza fare la cosa di rappresentazione).

Spero che aiuti.

0

solo un contributo anche per alcuni che stavano ancora incontrando un problema come questo. In base alla mia esperienza, se non si specifica alcun utente/password nella propria connettività, si connetterà automaticamente a db utilizzando l'autenticazione di Windows. Significa che otterrà l'ID utente e le credenziali dell'utente che ha effettuato l'accesso alla macchina. Il sistema ti permetterà di collegarti al database se identifica che il tuo ID utente esiste/creato nel database. Ma una volta specificato l'ID utente e la password nella connettività, ignorare l'autenticazione di Windows e utilizzare invece l'autenticazione SQL Server.

Problemi correlati