Jaka jest różnica między Integrated Security = True a Integrated Security = SSPI?

531

Mam dwie aplikacje korzystające ze zintegrowanych zabezpieczeń. Jeden przypisuje Integrated Security = trueciąg połączenia, a drugi zestaw Integrated Security = SSPI.

Jaka jest różnica między zintegrowanym bezpieczeństwem SSPIi truew jego kontekście?

— JD.
źródło

70

Przyjęta odpowiedź nie jest najlepsza, nie jest też w pełni poprawna. Integrated Security = Truelub SSPInie są takie same. Integrated Security=true;nie działa u wszystkich dostawców SQL, zgłasza wyjątek, gdy jest używany z OleDbdostawcą. Zasadniczo Integrated Security=SSPI;jest to preferowane, ponieważ działa zarówno z usługodawcą, jak SQLClienti OleDBdostawcą. Dodałem odpowiedź dla lepszego wyjaśnienia.

— Pranav Singh

3

@PranavSingh ma właściwy pomysł, to pytanie jest niepełne, chyba że określisz, którego usługodawcy używasz. Różni dostawcy akceptują i / lub tłumaczą różne ciągi znaków na stany wewnętrzne.

— Mark

Chociaż są one takie same, uważam, że na jednej ze stron internetowych był bardzo stary dokument, w tym czasie byłem ciekawy jak Ty, który powiedział, że jeśli tworzysz dla systemu Windows Mobile (nie to, co widzisz dzisiaj, stare urządzenia, które ja nie pamiętam sufiksu systemu operacyjnego, ponieważ nigdy go nie miałem), powinieneś używać SSPI i hasła użytkownika razem. ale ponieważ nigdy go nie napisałem i nie pamiętam źródła tego dokumentu, nie mogę tego zagwarantować.

— deadManN,

436

Według Microsoft są one tym samym.

Kiedy falseidentyfikator połączenia i hasło są określone w połączeniu. Jeśli ma wartość true, do uwierzytelnienia używane są bieżące poświadczenia konta Windows.
Uznane wartości true, false, yes,no i sspi(zalecane), która jest równoważna true.

— cptScarlet
źródło

28

Początkowo myślę, że była różnica w tym, że „True” używał NTLM, a „SSPI” używał Kerberos, ale teraz są one wymienne.

— SqlRyan

5

Nie sprawdziłem ostatniego komentarza, ale jeśli jest prawdziwy, powinien być odpowiedzią, ale nie komentarz

— Johnny_D

20

@RodneyFoley przepraszam, moje testy potwierdzają, że ta odpowiedź jest poprawna, a twój komentarz nie. Może to kiedyś działało w ten sposób, ale teraz nie działa i nie możesz podać żadnego odniesienia do dokumentu Microsoft, który popiera Twoją opinię.

— Kirk Broadhurst,

3

Zgadzam się z Kirkiem. Użytkownik / hasło są ignorowane, gdy określono SSPI - .net 4.0, SQL Server 2012.

— Alex des Pelagos

3

Jeśli więc „są tym samym”, dlaczego SSPI jest „zdecydowanie zalecane”, a nie „prawdziwe” lub „tak?”. To dlatego podszedłem do tego pytania ...

— Zé Carlos,

171

Integrated Security=true;nie działa u wszystkich dostawców SQL, zgłasza wyjątek, gdy jest używany z OleDbdostawcą.

Zasadniczo Integrated Security=SSPI;jest to preferowane, ponieważ działa zarówno z dostawcą, jak SQLClienti OleDBdostawcą.

Oto pełny zestaw składni zgodnie z MSDN - Składnia ciągu połączenia (ADO.NET)

— Pranav Singh
źródło

73

Korzystanie z uwierzytelniania systemu Windows

Aby połączyć się z serwerem bazy danych, zaleca się korzystanie z uwierzytelniania systemu Windows, zwanego potocznie zintegrowanym zabezpieczeniem. Aby określić uwierzytelnianie systemu Windows, możesz użyć dowolnej z dwóch poniższych par klucz-wartość z dostawcą danych. NET Framework dla SQL Server:

 Integrated Security = true;
 Integrated Security = SSPI;

Jednak tylko drugi działa z dostawcą danych .NET Framework OleDb . Jeśli ustawisz Integrated Security = trueConnectionString, zgłaszany jest wyjątek.

Aby określić uwierzytelnianie systemu Windows w dostawcy danych. NET Framework dla ODBC, należy użyć następującej pary klucz-wartość.

Trusted_Connection = yes;

Źródło: MSDN: Praca z ciągami połączeń

— Asereware
źródło

33

Wiele pytań otrzymuje odpowiedzi, jeśli używamy .Net Reflectordo wyświetlenia rzeczywistego kodu SqlConnection:) truei sspisą takie same:

internal class DbConnectionOptions

...

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

...

EDYCJA 20.02.2018 Teraz w .Net Core możemy zobaczyć jego open source na github! Wyszukaj metodę ConvertValueToIntegratedSecurityInternal:

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

— Pavel Biryukov
źródło

2

Ta część kodu jest własnością tylko dla jednego przypadku, który można wyjaśnić nazwą ConvertValueToIntegratedSecurityInternal. Ta właściwość jest używana tylko wtedy, gdy dostawca SqlClienttak jest SqlClient, SSPIi truesą takie same, ale nie, gdy klient jest OleDblub OracleClient. Wyjaśniłem, że w stackoverflow.com/a/23637478/704008 z referencją msdn

— Pranav Singh

Głosuj w dół z powodu Pranava tutaj.

— Scott

21

Zintegrowane zabezpieczenia = Fałsz: identyfikator użytkownika i hasło są określone w połączeniu. Zintegrowane zabezpieczenia = prawda: bieżące poświadczenia konta Windows są używane do uwierzytelniania.

Zintegrowane zabezpieczenia = SSPI: jest to równoważne z wartością true.

Możemy uniknąć atrybutów nazwy użytkownika i hasła z ciągu połączenia i użyć zintegrowanych zabezpieczeń

— NITIN KAUSHIK
źródło

13

Zacznę od Integrated Security = false

false Identyfikator użytkownika i hasło są określone w ciągu połączenia.
true Poświadczenia konta Windows są używane do uwierzytelniania.

Uznane wartości true, false, yes, no, i SSPI.

Jeśli User IDi Passwordsą określone, a Zintegrowane zabezpieczenia są ustawione na true, wówczas User IDi Passwordzostaną zignorowane, a Zintegrowane zabezpieczenia zostaną użyte

— kudlatiger
źródło

7

Pamiętaj, że parametry połączenia są specyficzne dla tego, co i jak łączysz się z danymi. Łączą się one z tą samą bazą danych, ale pierwsza korzysta z .NET Framework Data Provider dla SQL Server. Zintegrowane zabezpieczenia = True nie będzie działać dla OleDb.

Źródło danych = .; katalog początkowy = aspnetdb; zintegrowane zabezpieczenia = prawda
Dostawca = SQLOLEDB; Źródło danych = .; Zintegrowane zabezpieczenia = SSPI; Początkowy katalog = aspnetdb

W razie wątpliwości użyj połączeń danych programu Visual Studio Server Explorer.

Co to jest sspi ?
Składnia ciągów połączeń

— użytkownik1874524
źródło

5

Prawda jest poprawna tylko w przypadku korzystania z biblioteki .NET SqlClient. Nie działa przy korzystaniu z OLEDB. Gdzie SSPI jest bvaid w obu, albo używasz biblioteki .net SqlClient lub OLEDB.

— Amit Shishodia
źródło

social.msdn.microsoft.com/Forums/en-US/…

— Amit Shishodia

2

Z mojego punktu widzenia,

Jeśli nie używasz zintegrowanego zabezpieczenia = SSPI, musisz zakodować nazwę użytkownika i hasło w ciągu połączenia, co oznacza „względnie niepewne” dlaczego, ponieważ wszyscy pracownicy mają dostęp, nawet były pracownik może złośliwie wykorzystać informacje.

— Sathishkumar
źródło

1

Ciąg połączenia niekoniecznie jest widoczny dla żadnego pracownika.

— underscore_d