Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy: 
.NET Framework .NET Standard
Użyj Microsoft Entra ID, aby połączyć się bez konieczności przechowywania hasła SQL w aplikacji. Wybierz metodę logowania dla hosta, na którym działa aplikacja, udostępnij tę tożsamość w docelowej bazie danych i zachowaj włączoną walidację certyfikatów Transport Layer Security (TLS ).
Przegląd
Tryby uwierzytelniania udostępniane przez sterownik Active Directory ... wymagają zarówno Microsoft.Data.SqlClient, jak i Microsoft.Data.SqlClient.Extensions.Azure. Zainstaluj wersje odpowiadające:
dotnet add package Microsoft.Data.SqlClient --version 7.1.0
dotnet add package Microsoft.Data.SqlClient.Extensions.Azure --version 7.1.0
Rozszerzenie automatycznie rejestruje swoich dostawców. Aplikacje, które udostępniają własne AccessToken, AccessTokenCallback lub własnego dostawcę uwierzytelniania, nie potrzebują rozszerzenia Azure tylko w tym celu. Dodaj bibliotekę tożsamości, której używa Twój własny kod tokenów.
Przed połączeniem:
- Skonfiguruj uwierzytelnianie Microsoft Entra dla Azure SQL lub wykonaj równoważną konfigurację dla usługi docelowej.
- Przyznaj aplikacji lub tożsamości użytkownika dostęp do zamierzonej bazy danych. Uzyskanie tokena nie daje uprawnień do bazy danych.
- Zezwól na dostęp sieciowy do punktu końcowego i wybierz bazę danych wyraźnie.
- Wybierz obsługiwany tryb uwierzytelniania i udostępnij jego dane uwierzytelniające na hostze aplikacji.
Baza danych SQL w Microsoft Fabric obsługuje wyłącznie uwierzytelnianie Microsoft Entra. Nie obsługuje uwierzytelniania SQL ani logowania SQL. Użyj parametrów połączenia z portalu Fabric dla docelowego punktu końcowego.
Wybieranie trybu uwierzytelniania
Ustaw Authentication jedną z wartości stringów połączeń w tej tabeli. Kolumna Wydanie pomaga w migracji ze starszych sterowników. Obecne aplikacje powinny instalować pakiety opisane w Przeglądzie.
| Wartość ciągu łączeń | Użyj | Pierwsze wspierane wydanie |
|---|---|---|
Active Directory Integrated |
Zdobądź token, korzystając z Integrated Windows Authentication (IWA) w skonfigurowanej domenie i środowisku Microsoft Entra. | 1.0 na platformie .NET Framework; 2.0 we wszystkich obsługiwanych platformach docelowych. |
Active Directory Interactive |
Logowanie użytkownika obsługujące uwierzytelnianie wieloskładnikowe (MFA). | 1.0 dla platformy .NET Framework; 2.0 dla wszystkich obsługiwanych platform docelowych. |
Active Directory Service Principal |
ID klienta aplikacji i sekret klienta. | 2.0. |
Active Directory Device Code Flow |
Użytkownik loguje się przez przeglądarkę na innym urządzeniu. | 2.1. |
Active Directory Managed Identity lub Active Directory MSI |
Przypisana przez system lub użytkownikowi zarządzana tożsamość dostępna dla hosta aplikacji. | 2.1. |
Active Directory Default |
Odkryj dostępne poświadczenie uwierzytelniające poprzez łańcuch poświadczeń Azure Identity. | 3.0. |
Active Directory Workload Identity |
Sfederowana tożsamość obciążenia roboczego z projekcyjnym plikiem tokenu. | 5.2. |
Active Directory Password |
Wycofany proces logowania za pomocą nazwy użytkownika i hasła. Nie używaj do nowych zastosowań. | 1.0. |
Authentication=Sql Passwordto uwierzytelnianie SQL, a nie uwierzytelnianie Microsoft Entra. Zobacz SQL Server i uwierzytelnianie systemu Windows.
Otwórz połączenie
W przypadku aplikacji konsolowej .NET ustaw SQL_CONNECTION_STRING na odpowiedni szablon z tego artykułu po zastąpieniu symboli zastępczych. Ten przykład otwiera połączenie i wyświetla nazwę bazy danych:
using Microsoft.Data.SqlClient;
string connectionString = Environment.GetEnvironmentVariable("SQL_CONNECTION_STRING")
?? throw new InvalidOperationException("Set SQL_CONNECTION_STRING before running.");
using var connection = new SqlConnection(connectionString);
await connection.OpenAsync();
using var command = new SqlCommand("SELECT DB_NAME();", connection);
Console.WriteLine(await command.ExecuteScalarAsync());
Każdy tryb ma inne wymagania dotyczące hosta. To, że parser akceptuje parametry połączenia, nie oznacza, że host może uzyskać token ani że tożsamość może uzyskać dostęp do bazy danych.
Użyj uwierzytelniania zintegrowanego
Active Directory Integratedpozyskuje token Microsoft Entra, używając tożsamości domeny zalogowanej. Wymaga odpowiedniej konfiguracji tożsamości połączonej lub federacyjnej. Nie jest to to samo co Integrated Security=true, które używa bezpośrednio uwierzytelniania systemu Windows w programie SQL Server.
Server=tcp:contoso.database.windows.net,1433;Database=<database>;Authentication=Active Directory Integrated;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Nie podawaj hasła ani SqlCredential. Podpowiedź o nazwie użytkownika jest opcjonalna w nowoczesnym .NET; .NET Framework nie akceptuje nazwy użytkownika dla tego trybu. IWA nie spełnia interaktywnego wyzwania MFA. Używaj uwierzytelniania interaktywnego, gdy najemca wymaga interakcji użytkownika.
Korzystanie z uwierzytelniania interakcyjnego
Używaj Active Directory Interactive w przypadku osoby logującej się do aplikacji komputerowej lub deweloperskiej. Dostawca uwierzytelniania wyświetla użytkownikowi monit i obsługuje MFA. Opcjonalna User ID=<user_id> opcja daje podpowiedzi do logowania, a nie hasło.
Server=tcp:contoso.database.windows.net,1433;Database=<database>;Authentication=Active Directory Interactive;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Nie podawaj Password ani SqlCredential. Nie używaj trybu interaktywnego dla usługi bez nadzoru.
Korzystanie z uwierzytelniania podmiotu usługi
Tryb wbudowany Active Directory Service Principal wykorzystuje identyfikator klienta aplikacji jako , User ID a jej sekret klienta jako .Password Utwórz jednostkę usługi w bazie danych i nadaj jej tylko uprawnienia, których potrzebuje.
Pobierz sekret z chronionej konfiguracji zamiast osadzać go w źródle. Ten przykład konsoli odczytuje wartości wstrzyknięte do procesu:
using Microsoft.Data.SqlClient;
static string Required(string name) =>
Environment.GetEnvironmentVariable(name)
?? throw new InvalidOperationException($"Set {name} before running.");
var options = new SqlConnectionStringBuilder
{
DataSource = Required("SQL_SERVER"),
InitialCatalog = Required("SQL_DATABASE"),
Authentication = SqlAuthenticationMethod.ActiveDirectoryServicePrincipal,
UserID = Required("AZURE_CLIENT_ID"),
Password = Required("AZURE_CLIENT_SECRET"),
Encrypt = SqlConnectionEncryptOption.Mandatory,
TrustServerCertificate = false,
MultiSubnetFailover = true
};
using var connection = new SqlConnection(options.ConnectionString);
await connection.OpenAsync();
using var command = new SqlCommand("SELECT DB_NAME();", connection);
Console.WriteLine(await command.ExecuteScalarAsync());
Ustaw SQL_SERVER na punkt końcowy protokołu Transmission Control Protocol (TCP), na przykład tcp:contoso.database.windows.net,1433, a SQL_DATABASE na nazwę bazy danych. Nie zapisuj w dzienniku wartości zmiennych środowiskowych ani parametrów połączenia.
W przypadku poświadczeń aplikacji opartych na certyfikatach tokeny należy uzyskać za ClientCertificateCredential pomocą AccessTokenCallback. W przypadku poświadczeń federacyjnych użyj tożsamości obciążenia lub odpowiedniego wywołania zwrotnego tokenu. Tryb service principal łańcucha łączeń wymaga sekretu klienta.
Użyj uwierzytelniania za pomocą przepływu kodu urządzenia
Używaj tego trybu, gdy host aplikacji nie ma przeglądarki, ale osoba może zalogować się na innym urządzeniu. Skorzystaj z adresu URL i kodu weryfikacyjnego podanych w procesie uwierzytelniania.
Server=tcp:contoso.database.windows.net,1433;Database=<database>;Authentication=Active Directory Device Code Flow;Connect Timeout=180;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Connect Timeout uwierzytelnianie granic; ten przykład pozwala na 180 sekund. Nie podawaj User ID, Password, ani SqlCredential. Przepływ uwierzytelniania za pomocą kodu urządzenia nadal wymaga udziału użytkownika i nie nadaje się do usług bezobsługowych.
Użyj uwierzytelniania za pomocą tożsamości zarządzanej
W przypadku aplikacji hostowanej w Azure używaj tożsamości zarządzanej, gdy host ją obsługuje. Tożsamość należy do hosta aplikacji, a nie automatycznie do serwera bazy danych.
- Tożsamość zarządzana przypisana przez system współdzieli cykl życia zasobu hosta.
- Zarządzana tożsamość przypisana przez użytkownika to osobny zasób, który możesz przypisać wspieranym hostom.
Dla tożsamości przypisanej systemowi pomiń User ID:
Server=tcp:contoso.database.windows.net,1433;Database=<database>;Authentication=Active Directory Managed Identity;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Dla tożsamości przypisanej przez użytkownika podaj jej identyfikator klienta:
Server=tcp:contoso.database.windows.net,1433;Database=<database>;Authentication=Active Directory Managed Identity;User ID=<client_id>;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Active Directory MSI to pisownia kompatybilności dla tego samego trybu. Nie podawaj hasła ani SqlCredential. Host musi udostępnić wybraną tożsamość zarządzaną, a ta tożsamość musi mieć dostęp do bazy danych. Stacja robocza dewelopera nie uzyskuje zarządzanej tożsamości przy użyciu tych parametrów połączenia.
Podczas migracji z SqlClient 2.1 zastąp identyfikator obiektu tożsamości przypisanej przez użytkownika jej identyfikatorem klienta. SqlClient używa identyfikatora klienta zaczynającego się od wersji 3.0.
Użyj domyślnej autentykacji
Active Directory Defaultużywa łańcucha poświadczeń Azure Identity do odkrycia dostępnej tożsamości:
Server=tcp:contoso.database.windows.net,1433;Database=<database>;Authentication=Active Directory Default;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Kandydaci zależą od zainstalowanej wersji i konfiguracji Azure Identity. Należą do nich poświadczenia środowiskowe, tożsamość obciążenia roboczego, tożsamość zarządzana oraz narzędzia programistyczne, do których użytkownik jest zalogowany, takie jak Visual Studio, Azure Command-Line Interface (CLI), Azure PowerShell i Azure Developer CLI. Zobacz DefaultAzureCredential, aby uzyskać informacje o bieżącym łańcuchu.
SqlClient wyłącza InteractiveBrowserCredential w tym trybie. Wybierz, Active Directory Interactive czy aplikacja sama musi wywołać wezwanie do logowania. Poświadczenie narzędzia programistycznego może korzystać z sesji utworzonej podczas wcześniejszego interaktywnego logowania.
Ważne
Active Directory Default może spowolnić pierwsze połączenie, ponieważ DefaultAzureCredential próbuje kolejnych dostawców poświadczeń, aż jeden z nich dostarczy token. Niedostępni dostawcy mogą powodować opóźnienia związane z wykrywaniem, siecią lub uruchamianiem procesu, zanim zostanie osiągnięty dostępny dostawca. Preferuj użycie określonego trybu uwierzytelniania w środowisku produkcyjnym, takiego jak Active Directory Managed Identity, Active Directory Workload Identity lub Active Directory Service Principal, aby uniknąć narzutu związanego z wykrywaniem. Buforowanie poświadczeń i tokenów może ograniczyć nakład pracy przy kolejnych operacjach uzyskiwania; nie zakładaj, że każde połączenie z puli powtarza cały łańcuch.
Przy Active Directory Default, wybrana tożsamość może się zmieniać wraz ze zmianą konfiguracji hosta.
W starszych wdrożeniach, identyfikacja obciążenia w tym łańcuchu oraz wsparcie dla Azure Developer CLI pojawiły się w SqlClient 5.1.4. Ta funkcja różni się od dedykowanego Active Directory Workload Identity trybu, który pojawił się w wersji 5.2. Wsparcie dla Azure PowerShell pojawiło się w wersji 5.0.
Użyj uwierzytelniania za pomocą tożsamości obciążenia
Użyj Active Directory Workload Identity na hoście skonfigurowanym do sfederowanej tożsamości obciążenia. Dostawca tożsamości musi ufać emitentowi i podmiotowi przewidywanego tokena.
Poświadczenie brzmi:
-
AZURE_TENANT_ID: identyfikator najemcy. -
AZURE_CLIENT_ID: identyfikator klienta aplikacji lub zarządzanej tożsamości przypisanej przez użytkownika. -
AZURE_FEDERATED_TOKEN_FILE: ścieżka do pliku rzutowanego tokena.
Server=tcp:contoso.database.windows.net,1433;Database=<database>;Authentication=Active Directory Workload Identity;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Opcjonalne User ID=<client_id> nadpisuje identyfikator klienta. Parametry połączenia nie zastępują identyfikatora dzierżawy ani ścieżki do pliku tokenu. Nie umieszczaj zawartości pliku tokenu w parametrach połączenia ani w dziennikach.
Zastąpienie przestarzałego uwierzytelniania hasłem
Ważne
Opcja uwierzytelniania ActiveDirectoryPassword (uwierzytelnianie hasłem Microsoft Entra ID) została wycofana w sterownikach Microsoft SQL. Ten proces uwierzytelniania wysokiego ryzyka jest niezgodny z obowiązkowym uwierzytelnianiem wieloskładnikowym (MFA) w usłudze Microsoft Entra i może nie działać w dzierżawcach, w których wymuszane jest MFA. Zaplanuj migrację do innej metody uwierzytelniania Microsoft Entra.
Microsoft Entra ID uwierzytelnianie hasłem jest oparte na przyznaniu poświadczeń hasła właściciela zasobu OAuth 2.0 (ROPC), co umożliwia aplikacji logowanie użytkownika bezpośrednio przy użyciu obsługi hasła.
Microsoft zaleca, aby nie używać przepływu ROPC, ponieważ jest on niezgodny z uwierzytelnianiem wieloskładnikowym. W większości scenariuszy dostępne są bezpieczniejsze alternatywy i zalecane. Ten przepływ wymaga wysokiego stopnia zaufania w aplikacji i niesie ze sobą ryzyko, które nie są obecne w innych przepływach. Użyj tego przepływu tylko wtedy, gdy bezpieczniejsze przepływy nie są opłacalne. Firma Microsoft odchodzi od tego przepływu uwierzytelniania wysokiego ryzyka, aby chronić użytkowników przed złośliwymi atakami. Aby uzyskać więcej informacji, zobacz Planowanie obowiązkowego uwierzytelniania wieloskładnikowego dla platformy Azure.
Gdy użytkownik jest obecny podczas logowania, użyj uwierzytelniania ActiveDirectoryInteractive lub ActiveDirectoryIntegrated, aby zastosować atrybuty dziennika inspekcji do zalogowanego użytkownika i zasad dostępu warunkowego.
W przypadku nienadzorowanych scenariuszy komunikacji między usługami postępuj zgodnie z wskazówkami dotyczącymi kont usług Microsoft Entra:
- Jeśli aplikacja działa w infrastrukturze Azure, użyj activedirectoryMSI (lub ActiveDirectoryManagedIdentity w niektórych sterownikach). Tożsamości zarządzane eliminują obciążenie związane z utrzymywaniem i rotacją kluczy tajnych oraz certyfikatów.
- Jeśli tożsamość zarządzana nie jest dostępna (na przykład aplikacja działa poza platformą Azure), użyj ActiveDirectoryServicePrincipal. Jeśli sterownik to obsługuje, preferowane jest użycie certyfikatu klienta zamiast wpisu tajnego klienta. W przypadku certyfikatu klucz prywatny pozostaje na kliencie, a do Microsoft Entra jest wysyłane tylko podpisane potwierdzenie w celu uwierzytelnienia klienta. Jeśli klucz jest przechowywany w sprzęcie (na przykład w module TPM lub HSM) albo oznaczony jako nieeksportowalny, nie można go wyeksportować w postaci ciągu znaków tak, jak można to zrobić z kluczem tajnym klienta.
- Nie używaj konta użytkownika Microsoft Entra jako konta usługi.
Active Directory Password korzysta z procesu logowania hasła właściciela zasobów i nie spełnia wymagań MFA. Odpowiadający SqlAuthenticationMethod.ActiveDirectoryPassword mu członek enum jest przestarzały. Wybierz interaktywną autoryzację dla użytkowników, lub tożsamość zarządzaną, tożsamość obciążenia lub poświadczenie aplikacyjne dla usług.
Dostosowanie uwierzytelniania Microsoft Entra
Wybierz najmniejszą możliwość dostosowania do Twoich potrzeb spośród następujących interfejsów programistycznych (API):
| Wymaganie | API |
|---|---|
| Dostarcz już zdobyty żeton. |
SqlConnection.AccessToken. |
| Zdobywaj i odnawiaj tokeny z wybranym przez aplikację poświadczeniem. |
SqlConnection.AccessTokenCallback. |
| Dostosuj prezentację kodu urządzenia lub interaktywne logowanie. |
ActiveDirectoryAuthenticationProvider z rozszerzenia Azure. |
| Wprowadź dostawcę uwierzytelniania sterowników. | Pobieraj SqlAuthenticationProvider i rejestruj dostawcę. |
Dzięki niestandardowemu ActiveDirectoryAuthenticationProvider możesz podać identyfikator klienta aplikacji, skonfigurować wywołania zwrotne dla kodu urządzenia lub kodu autoryzacyjnego oraz ustawić okno nadrzędne na potrzeby interaktywnego logowania, jeśli jest to obsługiwane. Użyj dokumentacji referencyjnej API dostawcy w przypadku podpisów zainstalowanego pakietu rozszerzenia.
Dostarcz token dostępu bezpośrednio
Ustaw SqlConnection.AccessToken przed otwarciem połączenia. Sterownik rdzeniowy obsługuje tę właściwość bez rozszerzenia Azure.
Token literalny jest częścią klucza poola połączenia. Inny token tworzy inną pulę. SqlClient nie otrzymuje czasu wygaśnięcia za pośrednictwem tej właściwości i nie może odnowić tokenu za Ciebie. Zdobądź ważny token dla nowych połączeń i usuń dotknięte pule, gdy tokeny wygasną, zwłaszcza jeśli ustawisz niezerowy Min Pool Sizetoken.
Nie łącz AccessToken z Authentication, zintegrowanym bezpieczeństwem, User ID lub Password, SqlCredential, AccessTokenCallback, lub SspiContextProvider. Nigdy nie zapisuj tokenu w logach.
Użyj AccessTokenCallback
Wybierz AccessTokenCallback, jeśli Twoja aplikacja sama uzyskuje tokeny i korzysta z puli połączeń. Callback zwraca token i jego czas wygaśnięcia, dzięki czemu SqlClient może zażądać odnowienia dla uwierzytelniania w grupie. API jest dostępne od SqlClient 5.2.
Użyj ponownie tej samej instancji delegata i obiektu poświadczeń dla połączeń, które powinny korzystać ze wspólnej puli. Delegat wywołania zwrotnego jest częścią klucza puli. Utworzenie nowego zamknięcia dla każdego połączenia może stworzyć osobną pulę dla każdego z nich.
Ważne
Zwracaj ten sam kontekst bezpieczeństwa dla takich samych danych wejściowych wywołania zwrotnego. Nie wybieraj innego użytkownika ze stanu żądania ambientowego w ramach wspólnego callbacku. W przeciwnym razie połączenie w grupie mogłoby zostać zwrócone pod błędną tożsamością.
Ten przykład konsoli .NET wykorzystuje zarejestrowaną tożsamość Azure CLI do rozwoju lokalnego. Zainstaluj Microsoft.Data.SqlClient i Azure.Identity, zaloguj się do Azure CLI z tożsamością mająca dostęp do bazy danych, i ustaw SQL_SERVER i SQL_DATABASE. Rozszerzenie Azure nie jest wymagane w tym przykładzie.
using Azure.Core;
using Azure.Identity;
using Microsoft.Data.SqlClient;
internal static class Program
{
private static readonly TokenCredential Credential = new AzureCliCredential();
private static readonly Func<SqlAuthenticationParameters, CancellationToken,
Task<SqlAuthenticationToken>> TokenCallback = async (parameters, cancellationToken) =>
{
string scope = parameters.Resource.EndsWith("/.default", StringComparison.Ordinal)
? parameters.Resource
: parameters.Resource + "/.default";
AccessToken token = await Credential.GetTokenAsync(
new TokenRequestContext(new[] { scope }), cancellationToken);
return new SqlAuthenticationToken(token.Token, token.ExpiresOn);
};
private static async Task Main()
{
var options = new SqlConnectionStringBuilder
{
DataSource = Required("SQL_SERVER"),
InitialCatalog = Required("SQL_DATABASE"),
Encrypt = SqlConnectionEncryptOption.Mandatory,
TrustServerCertificate = false,
MultiSubnetFailover = true
};
using var connection = new SqlConnection(options.ConnectionString)
{
AccessTokenCallback = TokenCallback
};
await connection.OpenAsync();
using var command = new SqlCommand("SELECT DB_NAME();", connection);
Console.WriteLine(await command.ExecuteScalarAsync());
}
private static string Required(string name) =>
Environment.GetEnvironmentVariable(name)
?? throw new InvalidOperationException($"Set {name} before running.");
}
Dla produkcji należy zastąpić AzureCliCredential zamierzonym poświadczeniem, takim jak ManagedIdentityCredential, WorkloadIdentityCredential, lub ClientCertificateCredential, i skonfigurować jego wymagania wstępne. Nie zmieniaj tożsamości wspólnego callbacka, dopóki połączone połączenia pozostają dostępne.
Nie łącz AccessTokenCallback z Authentication, zintegrowanym bezpieczeństwem, AccessToken, ani SspiContextProvider. Funkcja zwrotna może używać User ID jako selektora tożsamości, ale musi interpretować go w sposób spójny. Przykład nie używa selektora, ponieważ ma jedno stałe poświadczenie.
Obsługa niestandardowego dostawcy uwierzytelniania SQL
Utwórz klasę pochodną klasy SqlAuthenticationProvider, zaimplementuj jej kontrakt pozyskiwania tokenów i zarejestruj ją w SqlAuthenticationProvider.SetProvider dla zastępowanej metody uwierzytelniania. Rejestruj dostawców podczas inicjalizacji aplikacji, przed otwarciem połączeń.
Dostawca musi zwrócić ważny token oraz czas wygaśnięcia żądanego zasobu i uprawnień. Ta sama zasada kontekstu bezpieczeństwa, która stosuje się do powołań zwrotnych, dotyczy dostawców. Nadpisanie dostawcy nie usuwa wymagań dotyczących tożsamości, tenanta ani uprawnień do bazy danych usługi docelowej.
Migracja do Microsoft.Data.SqlClient 7.0
Aplikacje aktualizujące się w ramach podziału pakietów powinny przeglądać zależności i konfigurację uwierzytelniania.
Co zmieniło się w wersji 7.0
Podstawowy sterownik nie dołącza już zależności związanych z uwierzytelnianiem Azure i Microsoft Entra. Wbudowany ActiveDirectoryAuthenticationProvider przechodzi do Microsoft.Data.SqlClient.Extensions.Azure, z kontraktami współdzielonymi w Microsoft.Data.SqlClient.Extensions.Abstractions.
Krok 1. Instalowanie pakietu rozszerzenia platformy Azure
W przypadku trybów Microsoft Entra dostarczanych przez sterownik zainstaluj odpowiadające sobie wersje składnika podstawowego i rozszerzenia Azure, jak pokazano w Overview. Wdroż rozszerzenie razem z aplikacją. Dla trybów wbudowanych nie jest wymagana ręczna rejestracja operatora.
Krok 2. Zastępowanie przestarzałych trybów uwierzytelniania
Zastąp Active Directory Password trybem, który odpowiada sposobowi interakcji użytkowników z aplikacją oraz modelowi hostingu. W przypadku wdrożenia nienadzorowanego wybierz konkretną tożsamość obciążenia roboczego, zamiast polegać na logowaniu się programisty.
Krok 3. Przeglądanie parametrów połączenia
Zachowaj istniejącą obsługiwaną wartość Authentication, jeśli nadal odpowiada wdrożeniu. Potwierdź nazwę bazy danych, selektor tożsamości, ustawienia szyfrowania oraz dostęp do sieci. Nie dodawaj Integrated Security=true do Microsoft Entra parametry połączenia.
Aplikacje, które nie korzystają z uwierzytelniania entra ID
Hasło SQL i uwierzytelnianie zintegrowane z Windows nie wymagają rozszerzenia Azure. Aplikacje, które już uzyskują własne tokeny, mogą nadal używać AccessToken lub AccessTokenCallback ze sterownikiem podstawowym i wybraną biblioteką tożsamości.