Verwaiste SQL-Server-Benutzer nach Restore reparieren

Eine Datenbank kann erfolgreich wiederhergestellt sein und trotzdem für die Anwendung unzugänglich bleiben. Eine häufige Ursache ist ein verwaister Benutzer: In der Datenbank ist eine Login-SID gespeichert, die auf dem Zielserver fehlt. Ein Login mit gleichem sichtbarem Namen erhält beim Neuanlegen nicht zwingend dieselbe SID.

Trennen Sie Authentifizierung und Datenbankberechtigung. Das Login stellt die Identität auf Instanzebene her. Der Datenbankbenutzer repräsentiert sie innerhalb einer Datenbank und trägt dort Rollen und Rechte. Die Wiederherstellung bringt diesen Benutzer zurück, aber nicht automatisch sämtliche Instanzlogins und Abhängigkeiten.

Die SID-Zuordnung untersuchen

Führen Sie diese schreibgeschützte Abfrage in der wiederhergestellten Datenbank mit ausreichender administrativer Sicht auf Serverprinzipale aus.

-- SQL-authenticated, instance-mapped users in the current database.
SELECT dp.name AS DatabaseUser, dp.sid AS DatabaseUserSid,
       dp.authentication_type_desc
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE dp.type = 'S'
  AND dp.authentication_type_desc = 'INSTANCE'
  AND dp.principal_id > 4
  AND sp.principal_id IS NULL
ORDER BY dp.name;

Sie konzentriert sich ausdrücklich auf SQL-authentifizierte Benutzer mit Instanzzuordnung. Windows-Gruppen, enthaltene Benutzer, Zertifikatsbenutzer und externe Identitäten benötigen eigene Betrachtung. Ein Benutzer WITHOUT LOGIN ist nicht allein wegen des fehlenden Serverlogins defekt.

Metadatensichtbarkeit ist wichtig. Ein eingeschränktes Diagnosekonto sieht möglicherweise nicht alle Logins und meldet dadurch vermeintliche Waisen. Bestätigen Sie das Ergebnis im vorgesehenen administrativen Kontext, bevor Zuordnungen verändert werden.

Prüfen Sie das beabsichtigte Ziellogin separat: SID, Aktivierung, Authentifizierungsart und Zweck. Ein gleicher Name ist ein Hinweis, keine ausreichende Freigabe zur Identitätsverknüpfung. Verschiedene Umgebungen können denselben Namen für andere Dienste verwenden.

Unterscheiden Sie außerdem deaktivierte Logins, eine nicht verfügbare Standarddatenbank, falsche Verbindungszeichenfolgen und fehlendes CONNECT. Fehler 18456 allein ist keine vollständige Diagnose. Die serverseitigen Details und ein tatsächlicher Verbindungsversuch helfen, die fehlerhafte Stufe zu bestimmen.

Den vorhandenen Benutzer neu zuordnen

Existiert das richtige Ziellogin bereits, ändern Sie die Zuordnung direkt.

-- Run in the restored database only after verifying the intended mapping.
ALTER USER [AppUser] WITH LOGIN = [AppLogin];

AppUser und AppLogin sind Beispielnamen und müssen durch das geprüfte Paar ersetzt werden. ALTER USER erhält den vorhandenen Datenbankprinzipal, statt ihn neu zu erstellen. Seine bisherigen Berechtigungen und Rollenbeziehungen können dadurch bestehen bleiben.

Das Löschen als vermeintliche Abkürzung kann explizite Rechte verlieren oder wegen vorhandenen Schemabesitzes scheitern. Eine Neuerstellung mit gleichem Namen stellt nicht automatisch sämtliche Beziehungen wieder her. Aus einer Zuordnungsreparatur sollte keine unbeabsichtigte Rechteänderung werden.

Muss das Login wirklich neu entstehen, prüfen Sie die Übernahme der ursprünglichen SID über ein freigegebenes Migrationsverfahren. Damit können Zuordnungen mehrerer wiederhergestellter Datenbanken erhalten bleiben. Zugangsdaten und Kontorichtlinien gehören in den vorgesehenen sicheren Prozess, nicht als Klartext in ein improvisiertes Skript.

Vermeiden Sie eine automatische flächige Zuordnung nur nach Namen. Prüfen Sie eine konkrete Liste von Quell- und Zielidentitäten, besonders bei Zusammenführungen mehrerer Instanzen. Gleiche Namen können unterschiedliche Vertrauensgrenzen verbergen.

Identität und Fähigkeiten prüfen

Bestätigen Sie die SID-Verknüpfung und die erwarteten Datenbankrollen.

SELECT dp.name AS DatabaseUser, sp.name AS MappedLogin,
       dp.sid AS DatabaseUserSid, sp.sid AS LoginSid
FROM sys.database_principals AS dp
JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE dp.name = N'AppUser';

SELECT r.name AS DatabaseRole
FROM sys.database_role_members AS drm
JOIN sys.database_principals AS r ON r.principal_id = drm.role_principal_id
JOIN sys.database_principals AS m ON m.principal_id = drm.member_principal_id
WHERE m.name = N'AppUser';

Die Rollenabfrage bildet nur einen Teil des Rechtebestands ab. Direkte Objektfreigaben, Schemarechte, ausdrückliche Verbote und Besitz beeinflussen ebenfalls den Zugriff. Vergleichen Sie die relevanten Rechte vor und nach der Reparatur.

Öffnen Sie anschließend eine neue Verbindung mit dem tatsächlichen Anwendungslogin und der richtigen Anfangsdatenbank. Prüfen Sie eine erlaubte Operation sowie eine weiterhin verbotene. Ein Test nur als sysadmin umgeht den gerade reparierten Zugriffsweg.

In einer Verfügbarkeitsgruppe müssen notwendige Instanzlogins auf allen möglichen Primärreplikaten vorbereitet sein. Ein funktionierendes aktuelles Primärreplikat beweist keinen erfolgreichen späteren Rollenwechsel. Nehmen Sie Identitätsprüfungen in Wiederherstellungs- und Failover-Übungen auf.

Enthaltene Datenbankbenutzer können Instanzabhängigkeiten reduzieren, wenn das Authentifizierungsmodell passt. Ihre Einführung ist jedoch eine eigenständige Entwurfsentscheidung und keine allgemeine Notreparatur.

Bewahren Sie geprüfte Zuordnung und Ergebnisse bei den Migrationsunterlagen auf. Erfolgreich wiederhergestellt bedeutet auch, dass die richtige Anwendung mit ihren vorgesehenen Rechtegrenzen wieder arbeiten kann.

Technische Referenzen: Microsoft Learn: Troubleshoot orphaned users · Microsoft Learn: ALTER USER.