SQL Server Logins: DEFAULT_DATABASE & MUST_CHANGE – Sicherheit & Best Practices

SQL Server Logins: DEFAULT_DATABASE & MUST_CHANGE

📅 07. Mai 2025 ✍️ Von einem erfahrenen SQL Server DBA ⏱ 6 Min. Lesezeit

Einleitung: Zwei oft übersehene, aber kritische Login-Eigenschaften

Bei der Erstellung von SQL Server Logins konzentrieren sich viele Administratoren primär auf den Benutzernamen, das Passwort und die zugewiesenen Rollen. Zwei Optionen werden dabei oft vernachlässigt: DEFAULT_DATABASE und MUST_CHANGE. Dabei haben beide erhebliche Auswirkungen auf Sicherheit, Benutzerfreundlichkeit und den täglichen Betrieb. In diesem Blog beleuchten wir, wozu sie dienen, welche Fallstricke lauern und wie man sie optimal einsetzt.

🗄️ DEFAULT_DATABASE – Die Startdatenbank eines Logins

Jedes SQL Server Login besitzt eine Standarddatenbank (DEFAULT_DATABASE). Das ist die Datenbank, in der der Benutzer nach dem Herstellen einer Verbindung landet, wenn er keine andere Datenbank explizit angibt (z. B. in der Verbindungszeichenkette). Standardmäßig ist dies die master-Datenbank – und genau das ist oft ein Problem.

-- Login mit Standarddatenbank 'master' erstellen (Default) 
CREATE LOGIN AppUser WITH PASSWORD = 'komplexesPasswort!',  
DEFAULT_DATABASE = master; 
-- Besser: Eine Anwendungsdatenbank als Standard setzen 
CREATE LOGIN AppUser WITH PASSWORD = 'komplexesPasswort!',  
DEFAULT_DATABASE = MyAppDatabase;

⚠️ Problem: Bleibt ein Login auf master als Standarddatenbank, sehen Benutzer beim Verbinden systemweit alle Metadaten (z. B. sys.databases, sys.server_principals). Zudem können versehentliche Operationen in der Master-Datenbank fatale Folgen haben (z. B. USE master; DROP DATABASE ...).

💡 Best Practice: Setzen Sie die DEFAULT_DATABASE immer auf die Datenbank, die der Benutzer tatsächlich benötigt. Für einen Reporting-User wäre das die Reporting-DB, für eine Anwendung die App-DB. Vergeben Sie minimale Rechte in dieser Datenbank. So verhindern Sie ungewollte Zugriffe auf andere Datenbanken.

Ändern der Standarddatenbank nachträglich:

ALTER LOGIN AppUser WITH DEFAULT_DATABASE = SalesDB;

🔐 MUST_CHANGE – Passwortänderung beim ersten Anmelden erzwingen

Die Option MUST_CHANGE zwingt den Benutzer, das Passwort beim ersten Login zu ändern. Sie ist ein wichtiger Baustein für Sicherheitsrichtlinien, besonders bei temporären Logins oder initialer Passwortvergabe durch Admins. Allerdings gibt es einige wichtige Voraussetzungen und Einschränkungen.

-- Login mit MUST_CHANGE (nur bei SQL Server Authentifizierung möglich) 
CREATE LOGIN NewEmployee WITH PASSWORD = 'Start123!' MUST_CHANGE,  
DEFAULT_DATABASE = HRDB; 
-- Das Login kann sich erst anmelden und wird dann sofort zum Ändern des Passworts aufgefordert.

🚨 Wichtige Einschränkungen:

MUST_CHANGE funktioniert nur bei SQL Server-Authentifizierung (nicht für Windows-Logins).
Die Option ist nur verfügbar, wenn die Windows-Passwortrichtlinie aktiviert ist (CHECK_POLICY = ON und CHECK_EXPIRATION = ON). Diese sind standardmäßig aktiv.
Nach der ersten Passwortänderung verhält sich das Login wie ein normales Login mit eigenem Passwort. Der Administrator kann das Kennwort zurücksetzen und erneut MUST_CHANGE aktivieren.

⚠️ Häufiger Fehler: Wenn Sie ein Login mit MUST_CHANGE erstellen, aber die Passwortrichtlinie deaktiviert haben, erhalten Sie einen Fehler wie: "Die Anforderung MUST_CHANGE ist mit CHECK_POLICY = OFF nicht kompatibel."

-- Explizit CHECK_POLICY und CHECK_EXPIRATION aktivieren (Standard ist ON) 
CREATE LOGIN SecureUser WITH PASSWORD = 'TempPw123!' MUST_CHANGE,  
CHECK_POLICY = ON, CHECK_EXPIRATION = ON;

⚙️ Kombination und praktische Anwendungsfälle

Die wirkliche Stärke ergibt sich aus der Kombination beider Eigenschaften. Ein häufiges Szenario: Neue Mitarbeiter erhalten ein temporäres Login mit Startdatenbank und müssen ihr Passwort sofort ändern.

-- Beispiel: Neuer HR-Mitarbeiter 
CREATE LOGIN jdoe WITH PASSWORD = 'TempPass2025!' MUST_CHANGE,  
DEFAULT_DATABASE = HRDB; 
-- In HRDB den Benutzer anlegen und Rechte geben 
USE HRDB; 
CREATE USER jdoe FOR LOGIN jdoe; 
ALTER ROLE datareader ADD MEMBER jdoe;

💡 Empfehlung für Admins: Kombinieren Sie DEFAULT_DATABASE mit einer restriktiven Datenbank (z. B. einer dedizierten "LoginStaging"-DB), wenn das Login vor der ersten Passwortänderung nichts sehen soll. Manche Unternehmen legen sogar eine leere Datenbank an, die nur eine einfache Willkommensmeldung enthält.

🔍 Überprüfung bestehender Logins

Mit diesen Abfragen können Sie herausfinden, welche Logins welche Standarddatenbanken haben und ob MUST_CHANGE aktiv ist.

-- Alle SQL Server Logins mit DEFAULT_DATABASE und MUST_CHANGE Status 
SELECT  
name AS LoginName, 
default_database_name AS DefaultDB, 
CASE WHEN is_policy_checked = 1 THEN 'Ja' ELSE 'Nein' END AS PolicyEnabled, 
CASE WHEN is_expiration_checked = 1 THEN 'Ja' ELSE 'Nein' END AS ExpirationEnabled, 
CASE WHEN must_change_password = 1 THEN 'Ja' ELSE 'Nein' END AS MustChange 
FROM sys.sql_logins 
ORDER BY name;

⚠️ Achtung: Ein Login mit must_change_password = 1 kann sich nur anmelden, wenn es sein Passwort ändert. Alte Anwendungen oder geplante Jobs, die mit festen Anmeldeinformationen arbeiten, würden scheitern. Planen Sie daher entsprechende Tests oder schließen Sie solche Logins aus.

🛡️ Sicherheitsempfehlungen & typische Fehler vermeiden

1. Standarddatenbank master für normale Benutzer vermeiden
Ein Login, das standardmäßig in der Master-Datenbank landet, hat potentiell Zugriff auf viele Systemtabellen (je nach Berechtigung). Für Anwendungslogins sollte die Standarddatenbank die entsprechende App-Datenbank sein. Für Administratoren kann master sinnvoll sein – für normale Benutzer nicht.

2. MUST_CHANGE für temporäre oder initiale Logins aktivieren
Wenn Sie einem neuen Benutzer ein Passwort mitteilen (per E-Mail, Ticket), sollte es sofort nach dem ersten Login geändert werden. Das verhindert, dass das anfängliche Passwort längere Zeit gültig bleibt.

3. Kombination mit CHECK_POLICY nutzen
CHECK_POLICY = ON (Standard) erzwingt Komplexität und nutzt die Windows-Passwortrichtlinie. Das sollte nur in besonderen Umgebungen abgeschaltet werden.

🚨 Klassischer Fehler: Ein Admin erstellt ein Login mit MUST_CHANGE, vergisst aber, dem Benutzer die Berechtigung in der Standarddatenbank zu geben. Der Benutzer kann sich zwar anmelden, wird aber sofort zur Passwortänderung aufgefordert und erhält danach eine Fehlermeldung wie „Die Standarddatenbank ist nicht verfügbar“. Das führt zu Frustration und Supportaufrufen.

💡 Lösung: Prüfen Sie vor der Erstellung eines Logins mit MUST_CHANGE, ob der Benutzer (oder die Rolle) zumindest die CONNECT-Berechtigung in der Standarddatenbank besitzt. Am besten legen Sie den Datenbankbenutzer vorher an.

📋 Best Practices: Zusammenfassung

Standarddatenbank immer explizit setzen – nie auf master belassen, wenn es nicht nötig ist.
MUST_CHANGE bei Erstvergabe – vor allem bei temporären oder initialen Passwörtern.
Passwortrichtlinien aktiv lassen – das erhöht die Sicherheit erheblich.
Vor der Login-Erstellung prüfen, ob die Zieldatenbank existiert und der Benutzer zumindest CONNECT darauf hat.
Regelmäßig überwachen, welche Logins noch MUST_CHANGE aktiv haben – könnten auf vergessene, nicht abgeschlossene Einrichtung hindeuten.
Verwenden Sie DEFAULT_DATABASE für Anwendungsverbindungen – dann muss die Verbindungszeichenkette keine Initial Catalog enthalten, was die Konfiguration vereinfacht.

-- Beispiel für eine sichere, vollständige Login-Erstellung 
CREATE LOGIN ApplicationUser  
WITH PASSWORD = 'SecureInit123!' MUST_CHANGE, 
DEFAULT_DATABASE = AppDB, 
CHECK_POLICY = ON, 
CHECK_EXPIRATION = ON; 
USE AppDB; 
CREATE USER ApplicationUser FOR LOGIN ApplicationUser; 
ALTER ROLE db_datareader ADD MEMBER ApplicationUser; 
ALTER ROLE db_datawriter ADD MEMBER ApplicationUser; 
-- Jetzt kann sich der Benutzer anmelden, muss das Passwort ändern und landet direkt in AppDB.

🎯 Fazit

DEFAULT_DATABASE und MUST_CHANGE sind kleine, aber wirkungsvolle Stellschrauben für die Sicherheit und Benutzerfreundlichkeit Ihrer SQL Server Umgebung. Richtig eingesetzt, vermeiden sie ungewollte Zugriffe, erhöhen die Passwortsicherheit und erleichtern das Onboarding neuer Benutzer. Vernachlässigt führen sie hingegen zu Supportfällen, Sicherheitslücken und Verwirrung. Nehmen Sie sich die Zeit, diese Eigenschaften bei jedem Login zu überdenken – Ihre Kollegen und Auditoren werden es Ihnen danken.