Qual è la differenza tra Sicurezza integrata = True e Sicurezza integrata = SSPI?

531

Ho due app che utilizzano la sicurezza integrata. Uno assegna Integrated Security = truenella stringa di connessione e l'altro imposta Integrated Security = SSPI.

Qual è la differenza tra SSPIe truenel contesto della sicurezza integrata?

sql-server  security  connection-string  database-security 
— JD.
fonte
70
La risposta accettata non è la migliore, non è neppure del tutto corretta. Integrated Security = Trueo SSPInon sono uguali. Integrated Security=true;non funziona in tutti i provider SQL, genera un'eccezione se utilizzato con il OleDbprovider. Quindi, in pratica, Integrated Security=SSPI;è preferito poiché funziona con entrambi SQLCliente OleDBprovider. Ho aggiunto una risposta per un migliore chiarimento.
— Pranav Singh,
3
@PranavSingh ha l'idea giusta, questa domanda è incompleta a meno che non specifichi quale provider stai utilizzando. Diversi provider accettano e / o traducono varie stringhe in stati interni.
— Segna il
Anche se sono uguali, credo che ci fosse un documento molto vecchio in uno dei siti Web, al momento ero curioso come te, che diceva se stai sviluppando per Windows Mobile (non quello che vedi oggi, i vecchi dispositivi che ho non ricordo il suffisso del sistema operativo poiché non ne ho mai avuto uno), dovresti usare SSPI e password utente insieme. ma dal momento che non ne ho mai scritto uno e non ricordo la fonte di quel documento, non posso garantirlo.
— deadManN il

Risposte:

436

Secondo Microsoft sono la stessa cosa.

Quando false, ID utente e password sono specificati nella connessione. Se vero, le credenziali dell'account Windows corrente vengono utilizzate per l'autenticazione.
Valori riconosciuti sono true, false, yes, no, e sspi(fortemente raccomandato), che è equivalente a true.

— cptScarlet
fonte
28
Inizialmente, penso che ci fosse una differenza nel fatto che "True" utilizzava NTLM e "SSPI" utilizzava Kerberos, ma ora sono intercambiabili.
— SqlRyan,
5
Non ho controllato l'ultimo commento, ma se vero, dovrebbe essere come risposta, ma non il commento
— Johnny_D
20
@RodneyFoley mi dispiace, i miei test confermano che questa risposta è corretta e il tuo commento non lo è. Forse ha funzionato in quel modo una volta, ma non ora, e non puoi fornire alcun riferimento a un documento Microsoft che supporti la tua opinione.
— Kirk Broadhurst,
3
D'accordo con Kirk. Utente / password vengono ignorati quando SSPI specificato - .net 4.0, SQL server 2012.
— Alex des Pelagos
3
Quindi, se "sono la stessa cosa" perché SSPI è "fortemente raccomandato" piuttosto che "vero" o "sì? Questo è il motivo per cui sono arrivato a questa domanda ...
— Zé Carlos,
73

Utilizzo dell'autenticazione di Windows

Per connettersi al server di database si consiglia di utilizzare l'autenticazione di Windows, comunemente nota come sicurezza integrata. Per specificare l'autenticazione di Windows, è possibile utilizzare una delle due seguenti coppie chiave-valore con il fornitore di dati. NET Framework per SQL Server:

 Integrated Security = true;
 Integrated Security = SSPI;

Tuttavia, solo il secondo funziona con il provider di dati .NET Framework OleDb . Se si imposta Integrated Security = trueper ConnectionString, viene generata un'eccezione.

Per specificare l'autenticazione di Windows nel fornitore di dati. NET Framework per ODBC, è necessario utilizzare la seguente coppia chiave-valore.

Trusted_Connection = yes;

Fonte: MSDN: utilizzo delle stringhe di connessione

— Asereware
fonte
33

Molte domande ottengono risposte se usiamo .Net Reflectorper vedere il codice effettivo di SqlConnection:) truee sspisono le stesse:

internal class DbConnectionOptions

...

internal bool ConvertValueToIntegratedSecurityInternal(string stringValue)
{
    if ((CompareInsensitiveInvariant(stringValue, "sspi") || CompareInsensitiveInvariant(stringValue, "true")) || CompareInsensitiveInvariant(stringValue, "yes"))
    {
        return true;
    }
}

...

EDIT 20.02.2018 Ora in .Net Core possiamo vedere il suo open source su github! Cerca il metodo ConvertValueToIntegratedSecurityInternal:

https://github.com/dotnet/corefx/blob/fdbb160aeb0fad168b3603dbdd971d568151a0c8/src/System.Data.SqlClient/src/System/Data/Common/DbConnectionOptions.cs

— Pavel Biryukov
fonte
2
Quella parte del codice è proprietà solo per un caso che è spiegabile per nome ConvertValueToIntegratedSecurityInternal. Che la proprietà viene utilizzata solo quando provider è SqlClientcosì in SqlClient, SSPIe truesono gli stessi, ma non quando il cliente è OleDbo OracleClient. Ho chiarito che in stackoverflow.com/a/23637478/704008 con riferimento
— msdn
Votazione negativa per la ragione di Pranav qui.
— Scott,
21

Sicurezza integrata = Falso: ID utente e password sono specificati nella connessione. Sicurezza integrata = true: le credenziali dell'account Windows corrente vengono utilizzate per l'autenticazione.

Sicurezza integrata = SSPI: questo è equivalente a vero.

Possiamo evitare gli attributi di nome utente e password dalla stringa di connessione e utilizzare la sicurezza integrata

— NITIN KAUSHIK
fonte
13

Vorrei iniziare Integrated Security = false

false ID utente e password sono specificati nella stringa di connessione.
true Le credenziali dell'account Windows vengono utilizzate per l'autenticazione.

I valori riconosciuti sono true, false, yes, no, e SSPI.

Se User IDe Passwordsono specificati e Integrated Security è impostato su true, allora User IDe Passwordverrà ignorato e verrà utilizzato Integrated Security

— kudlatiger
fonte
7

Si noti che le stringhe di connessione sono specifiche di cosa e come ci si connette ai dati. Si stanno connettendo allo stesso database ma il primo utilizza .NET Framework Data Provider per SQL Server. Sicurezza integrata = True non funzionerà per OleDb.

  • Origine dati = .; Catalogo iniziale = aspnetdb; Sicurezza integrata = True
  • Provider = SQLOLEDB; Origine dati = .; Sicurezza integrata = SSPI; Catalogo iniziale = aspnetdb

In caso di dubbi, utilizzare le connessioni dati Explorer di Visual Studio Server.

— user1874524
fonte
2

Dal mio punto di vista,

Se non si utilizza Integrated security = SSPI, è necessario codificare il nome utente e la password nella stringa di connessione, il che significa "relativamente insicuro" perché, poiché tutti gli impiegati hanno accesso, anche gli ex dipendenti potrebbero utilizzare le informazioni in modo dannoso.

— Sathishkumar
fonte
1
La stringa di connessione non è necessariamente visibile a nessun dipendente.
— underscore_d
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.