Wer in Azure SQL Database oder Managed Instance noch mit aktivierter SQL-Authentifizierung arbeitet, kennt die lästigen Kompromisse. Passwörter müssen separat verwaltet werden, die Angriffsfläche wächst, und für Governance bleibt kaum Spielraum. In den meisten Tenants, die ich betreue, war SQL-Authentifizierung ursprünglich der Standard. Häufig ist sie es bis heute, weil alte Anwendungen oder Tools darauf angewiesen sind. Seit Microsoft die Option „nur Microsoft Entra-Authentifizierung“ im Azure-Portal gut sichtbar untergebracht hat (SQL-Server → Einstellungen → Microsoft Entra ID), gibt es aber kaum noch einen Grund, an SQL-Logins festzuhalten. Wer weiß, worauf er achten muss, erlebt den Umstieg in den meisten Umgebungen als erstaunlich schmerzlos.
Vor dem Umschalten braucht der Server einen Entra-Admin
Zuerst legt man eine Microsoft-Entra-Administratorgruppe für die SQL-Instanz fest. Ich empfehle fast immer eine eigene Entra-Gruppe statt einzelner Personen, weil sich damit sowohl die Verwaltung als auch die Break-Glass-Strategie deutlich einfacher gestalten. Die neue Option „Nur Entra“ ist im Azure-Portal mit einem Klick aktiviert. Ab diesem Moment sperrt der Server klassische SQL-Logins. In der Doku (hier) beschreibt Microsoft den Schalter und seine Auswirkungen sehr genau, einschließlich wichtiger Hinweise zu Ausnahmen und zum Zurücksetzen. Ist die Option aktiv, lässt der Server nur noch Anmeldungen über Microsoft Entra ID zu, gleichgültig ob sie von interaktiven Benutzern, Service Principals oder Managed Identities kommen.
Bevor ich umschalte, kontrolliere ich jedes Mal:
- Ob ein Entra-Admin gesetzt ist und sich dessen Mitglieder tatsächlich anmelden können
- Ob jede produktive Datenbank mindestens einen Entra-basierten SQL-User hat (z. B. angelegt mit
CREATE USER [Anwendungsname] FROM EXTERNAL PROVIDER) - Ob Dokumentation und Monitoring für die Zugriffe bereitstehen
Anwendungen melden sich mit einem Token statt mit einem Passwort an
Nutzt eine Anwendung moderne Authentifizierungsbibliotheken, ist die Umstellung meist kein großes Thema. Statt Benutzername und Passwort (SQL Authentication) holt sie sich ein Access Token von Microsoft Entra ID, beispielsweise über eine Managed Identity oder einen Service Principal. Bei Azure App Services, Functions oder Workloads auf VMs gehört das längst zum Alltag: Die Anwendung fordert ein Token an, etwa über DefaultAzureCredential, und weist sich damit gegenüber der Datenbank aus.
So sieht das in C# typischerweise aus (Azure-App mit systemseitig zugewiesener Managed Identity):
using Azure.Identity;
using Microsoft.Data.SqlClient;
var credential = new DefaultAzureCredential();
var token = credential.GetToken(
new Azure.Core.TokenRequestContext(new[] { "https://database.windows.net/.default" })
).Token;
using var conn = new SqlConnection(connectionString);
conn.AccessToken = token;
conn.Open();
Schwieriger wird es bei On-Premises-Anwendungen oder schlampig gebauten Integrationen, vor allem wenn sie weder mit Entra ID noch mit aktuellen Bibliotheken zurechtkommen. In solchen Fällen bleibt oft nur ein Refactoring oder ein Azure App Proxy als Brücke.
Welche Identitätsoptionen es für Anwendungen gibt und wie man Managed Identities sauber absichert, habe ich ausführlich im Beitrag Workload-Identitäten in Entra ID: Managed Identities, App-Registrierungen und sichere Alternativen beschrieben.
Im Entra-only-Betrieb führen alle Anmeldewege über ein Access Token
Im Diagramm ist zu sehen, auf welchem Weg sich die einzelnen Identitäten im Entra-only-Modus anmelden und wo die Übergänge liegen:
flowchart TD
User["Entra User"] --> Token["Access Token"]
ManagedIdentity["Managed Identity"] --> Token
ServicePrincipal["Service Principal"] --> Token
Token --> SQLServer["Azure SQL Server"]
SQLServer --> DBUser["Entra-User in Datenbank"]
Abbildung: Authentifizierungspfade im Azure-SQL-Entra-only-Betrieb
Azure Policy erzwingt Entra-only im gesamten Unternehmen
Dass sich die Entra-only-Option per Azure Policy tenantweit vorschreiben lässt, wird oft übersehen. Der Policy-Katalog enthält passende Definitionen für die Einstellung „Support only Microsoft Entra authentication for this server“ (siehe Doku). Damit stelle ich sicher, dass weder neue noch bestehende SQL-Server versehentlich wieder SQL-Authentifizierung zulassen.
Ist die Policy zugewiesen, überprüft sie alle SQL-Server in regelmäßigen Abständen und meldet jede Abweichung.
Praxistipp: „Ich setze Azure Policy immer zuerst im Audit-Modus ein und vergewissere mich, dass tatsächlich keine Altanwendung betroffen ist. Das erspart mir Rollbacks und Ärger mit den Fachbereichen.“
Bei der Migration dürfen Altsysteme und Break-Glass-Zugänge nicht untergehen
Technisch lässt sich Azure SQL Entra-only in den meisten Fällen problemlos umsetzen, organisatorisch bleibt aber einiges zu tun. Diese Stolpersteine begegnen mir immer wieder:
- Veraltete Tools oder Skripte (z. B. SSMS vor Version 18.5 oder Lösungen von Drittanbietern), die keine Entra-Authentifizierung beherrschen
- SQL-Logins, die fest in Deployments, Pipelines oder Monitoring-Tools hinterlegt sind
- Lückenhafte Dokumentation: Wer ist Entra-Admin, und was passiert bei einem Ausfall?
Mit einem strukturierten Migrationsplan kommt man sicher durch, zum Beispiel so:
- Alle Anwendungen und Benutzer ermitteln, die sich per SQL-Login anmelden (z. B. über das Audit-Log des SQL-Servers)
- Für jede Anwendung einen Entra-basierten User anlegen (
CREATE USER ... FROM EXTERNAL PROVIDER) - Die neuen Anmeldewege gründlich testen
- Erst danach Entra-only aktivieren und die Policy zuweisen
Um das Thema Break-Glass kommt man trotzdem nicht herum. Als Entra-Admin sollte meiner Meinung nach immer eine Entra-Gruppe mit ausgewählten Cloud-Admins eingetragen bleiben, bei Bedarf abgesichert mit Just-in-Time-Zugriff und MFA. Ein klassischer SQL-Login als Hintertür für den Notfall ist mit Entra-only nämlich nicht mehr möglich.
Entra-only ist für mich der neue Standard
Azure SQL Entra-only betrachte ich längst nicht mehr als Experiment, sondern als sichere Grundkonfiguration, besonders in regulierten Umgebungen. Die einmalige Mühe, alle Systeme umzustellen, macht sich durch mehr Kontrolle, bessere Governance und eine kleinere Angriffsfläche bezahlt. Gründlichkeit und eine saubere Dokumentation sind bei der Migration allerdings Pflicht. Bereut hat den Umstieg übrigens noch niemand in einem der Tenants, die ich begleitet habe. Wer tiefer in Details und Fallstricke einsteigen möchte, findet in Microsofts Überblick zur Entra-Authentifizierung (hier) weitere Informationen.
