EINFÜHRUNG
Beschreibt das Übertragen von Anmeldeinformationen und Kennwörtern zwischen verschiedenen Instanzen von Microsoft SQL Server.
Hinweis: Die Instanzen befinden sich möglicherweise auf demselben Server oder auf einem anderen Server und ihre Versionen können sich unterscheiden.
Für weitere Informationen zum Übertragen von Anmeldeinformationen und Kennwörtern zwischen Instanzen von anderen Versionen von SQL Server klicken Sie auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:
246133 Übertragen von Anmeldeinformationen und Kennwörtern zwischen Instanzen von SQL Server, die ältere Versionen von SQL Server ausführen
Weitere Informationen
In diesem Artikel sind Server A und Server B verschiedene Server.
Nachdem Sie eine Datenbank von der Instanz von SQL Server auf Server A auf die Instanz von SQL Server auf Server B verschoben haben, können sich Benutzer unter Umständen nicht bei der Datenbank auf Server B anmelden. Außerdem erhalten Benutzer möglicherweise die folgende Fehlermeldung:
Fehler bei der Anmeldung für den Benutzer „MeinBenutzer". (Microsoft SQL Server, Fehler: 18456)“ (Fehler bei der Anmeldung für den Benutzer ‚<Benutzername>‘. Der Benutzer ist nicht einer vertrauenswürdigen SQL Server-Verbindung zugeordnet. (Microsoft SQL Server, Fehler: 18452))
Dieses Problem tritt auf, weil Sie die Benutzernamen und Kennwörter nicht von der Instanz von SQL Server auf Server A auf die Instanz von SQL Server auf Server B übertragen haben.
Gehen Sie je nach Ihrer speziellen Situation folgendermaßen vor, um die Benutzernamen zu übertragen.
Methode 1: Zurücksetzen des Kennworts auf dem SQL Server-Computer (Server B)
Um dieses Problem zu beheben, setzen Sie das Kennwort auf dem Computer mit SQL Server zurück und schließen Sie dann die Anmeldung ab.
Hinweis: Beim Zurücksetzen des Kennworts wird der Algorithmus für das Kennwort-Hashing verwendet.
Methode 2: Übertragen von Anmeldeinformationen und Kennwörtern an den Zielserver (Server A) mithilfe von Skripts, die auf dem Quellserver generiert wurden (Server B)
Gehen Sie folgendermaßen vor, um ein Protokoll mit einem leeren Kennwort zu erstellen:
-
Starten Sie SQL Server Management Studio auf dem Server A und stellen Sie dann eine Verbindung mit der Instanz von SQL Server her, von der aus Sie die Datenbank verschoben haben.
-
Öffnen Sie ein neues Fenster im Abfrage-Editor und führen Sie dann das folgende Skript aus.
USE master
GO
IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL
DROP PROCEDURE sp_hexadecimal
GO
CREATE PROCEDURE sp_hexadecimal
@binvalue varbinary(256),
@hexvalue varchar (514) OUTPUT
AS
DECLARE @charvalue varchar (514)
DECLARE @i int
DECLARE @length int
DECLARE @hexstring char(16)
SELECT @charvalue = '0x'
SELECT @i = 1
SELECT @length = DATALENGTH (@binvalue)
SELECT @hexstring = '0123456789ABCDEF'
WHILE (@i <= @length)
BEGIN
DECLARE @tempint int
DECLARE @firstint int
DECLARE @secondint int
SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))
SELECT @firstint = FLOOR(@tempint/16)
SELECT @secondint = @tempint - (@firstint*16)
SELECT @charvalue = @charvalue +
SUBSTRING(@hexstring, @firstint+1, 1) +
SUBSTRING(@hexstring, @secondint+1, 1)
SELECT @i = @i + 1
END
SELECT @hexvalue = @charvalue
GO
IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL
DROP PROCEDURE sp_help_revlogin
GO
CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS
DECLARE @name sysname
DECLARE @type varchar (1)
DECLARE @hasaccess int
DECLARE @denylogin int
DECLARE @is_disabled int
DECLARE @PWD_varbinary varbinary (256)
DECLARE @PWD_string varchar (514)
DECLARE @SID_varbinary varbinary (85)
DECLARE @SID_string varchar (514)
DECLARE @tmpstr varchar (1024)
DECLARE @is_policy_checked varchar (3)
DECLARE @is_expiration_checked varchar (3)
DECLARE @defaultdb sysname
IF (@login_name IS NULL)
DECLARE login_curs CURSOR FOR
SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
sys.server_principals p LEFT JOIN sys.syslogins l
ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name <> 'sa'
ELSE
DECLARE login_curs CURSOR FOR
SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
sys.server_principals p LEFT JOIN sys.syslogins l
ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name = @login_name
OPEN login_curs
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
IF (@@fetch_status = -1)
BEGIN
PRINT 'No login(s) found.'
CLOSE login_curs
DEALLOCATE login_curs
RETURN -1
END
SET @tmpstr = '/* sp_help_revlogin script '
PRINT @tmpstr
SET @tmpstr = '** Generated ' + CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'
PRINT @tmpstr
PRINT ''
WHILE (@@fetch_status <> -1)
BEGIN
IF (@@fetch_status <> -2)
BEGIN
PRINT ''
SET @tmpstr = '-- Login: ' + @name
PRINT @tmpstr
IF (@type IN ( 'G', 'U'))
BEGIN -- NT authenticated account/group
SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' FROM WINDOWS WITH DEFAULT_DATABASE = [' + @defaultdb + ']'
END
ELSE BEGIN -- SQL Server authentication
-- obtain password and sid
SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS varbinary (256) )
EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT
EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT
-- obtain password policy state
SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' WITH PASSWORD = ' + @PWD_string + ' HASHED, SID = ' + @SID_string + ', DEFAULT_DATABASE = [' + @defaultdb + ']'
IF ( @is_policy_checked IS NOT NULL )
BEGIN
SET @tmpstr = @tmpstr + ', CHECK_POLICY = ' + @is_policy_checked
END
IF ( @is_expiration_checked IS NOT NULL )
BEGIN
SET @tmpstr = @tmpstr + ', CHECK_EXPIRATION = ' + @is_expiration_checked
END
END
IF (@denylogin = 1)
BEGIN -- login is denied access
SET @tmpstr = @tmpstr + '; DENY CONNECT SQL TO ' + QUOTENAME( @name )
END
ELSE IF (@hasaccess = 0)
BEGIN -- login exists but does not have access
SET @tmpstr = @tmpstr + '; REVOKE CONNECT SQL TO ' + QUOTENAME( @name )
END
IF (@is_disabled = 1)
BEGIN -- login is disabled
SET @tmpstr = @tmpstr + '; ALTER LOGIN ' + QUOTENAME( @name ) + ' DISABLE'
END
PRINT @tmpstr
END
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
END
CLOSE login_curs
DEALLOCATE login_curs
RETURN 0
GO
Hinweis Dieses Skript erstellt zwei gespeicherte Prozeduren in der Master-Datenbank. Die Prozeduren heißen sp_hexadecimal und sp_help_revlogin. -
Führen Sie die folgende Anweisung in demselben oder einem neuen Abfragefenster aus:
EXEC sp_help_revlogin
Das Ausgabeskript, das die gespeicherte Prozedur sp_help_revlogin generiert, ist das Anmeldeskript. Dieses Anmeldeskript erstellt die Anmeldungen mit dem ursprünglichen Security Identifier (SID) und dem ursprünglichen Kennwort.
Schritte auf dem Zielserver (Server B):
-
Starten Sie SQL Server Management Studio auf dem Server B und stellen Sie dann eine Verbindung mit der Instanz von SQL Server her, in die Sie die Datenbank verschoben haben.
Wichtig: Bevor Sie Schritt 2 durchführen, lesen Sie die Informationen im Abschnitt „Hinweise“ weiter unten. -
Öffnen Sie ein neues Abfrageeditorfenster und führen Sie dann das in Schritt 2 des vorherigen Verfahrens generierte Ausgabeskript aus.
Anmerkungen
Überprüfen Sie die folgenden Informationen, bevor Sie das Ausgabeskript auf der Instanz auf dem Server B ausführen:
-
Das Add-In kann auf folgende Arten deaktiviert werden:
-
-
VERSION_SHA1: Dieser Hash wird mithilfe des SHA1-Algorithmus generiert und in SQL Server 2000 über SQL Server 2008 R2 verwendet.
-
VERSION_SHA2: Dieser Hash wird mithilfe des SHA2-512-Algorithmus generiert und wird in SQL Server 2012 und höheren Versionen verwendet.
-
-
Überprüfen Sie das Ausgabeskript sorgfältig. Befinden sich Server A und Server B in unterschiedlichen Domänen, müssen Sie das Ausgabeskript ändern. Anschließend müssen Sie den ursprünglichen Domänennamen durch Verwendung des neuen Domänennamens in den „Anmeldung erstellen“ -Anweisungen ersetzen. Die integrierten Benutzernamen, die Zugriff in der neuen Domäne erhalten, haben nicht dieselbe SID wie die Anmeldungen in der ursprünglichen Domäne. Daher sind die Benutzer von diesen Anmeldungen verwaist. Weitere Informationen zur Behebung des Problems der verwaisten Benutzer finden Sie im folgenden Artikel der Microsoft Knowledge Base:
240872 Lösen von Zugriffsproblemen, wenn eine Datenbank auf einen anderen SQL-Server verschoben wird
Wenn Server A und Server B in derselben Domäne enthalten sind, wird dieselbe SID verwendet. Daher sind die Benutzer wahrscheinlich nicht verwaist. -
Im Ausgabeskript werden die Anmeldungen mithilfe des verschlüsselten Kennworts erstellt. Der Grund hierfür ist das Argument mit Hash in der „Anmeldung erstellen“-Anweisung. Dieses Argument gibt an, dass das Kennwort, das nach dem Passwort-Argument eingegeben wird, bereits mit Hash verwendet wird.
-
Standardmäßig kann nur ein Mitglied der festen Serverrolle sysadmin eine SELECT-Anweisung aus der sys.server_principals-Ansicht ausführen. Sofern nicht ein Mitglied der sysadmin-Rolle die erforderlichen Berechtigungen erteilt, können Endbenutzer diese gespeicherten Prozeduren weder erstellen noch ausführen.
-
Die Schritte in diesem Artikel übertragen die standardmäßigen Datenbankinformationen für eine bestimmte Anmeldung nicht. Dies liegt daran, dass die Standarddatenbank möglicherweise nicht immer auf dem Server B vorhanden ist. Verwenden Sie die Anweisung „Anmeldung ändern“, um die Standarddatenbank für eine Anmeldung zu definieren, indem Sie den Anmeldenamen und die Standarddatenbank als Argumente übergeben.
-
Sortieren von Bestellungen auf Quell- und Zielserver:
-
-
Groß-/Kleinschreibung in Server A und Server B: Bei der Sortierreihenfolge von Server A wird möglicherweise die Groß-/Kleinschreibung nicht beachtet und die Sortierreihenfolge des Servers B muss zwischen Groß- und Kleinschreibung unterscheiden. In diesem Fall müssen die Benutzer die Kennwörter in Großbuchstaben eingeben, nachdem Sie die Benutzernamen und die Kennwörter für die Instanz auf dem Server B übertragen haben.
-
Groß-/Kleinschreibung in Server A und Server B: Bei der Sortierreihenfolge von Server A wird möglicherweise zwischen Groß- und Kleinschreibung unterschieden und bei der Sortierreihenfolge von Server B wird die Groß-/Kleinschreibung möglicherweise nicht beachtet. In diesem Fall können sich Benutzer nicht mit den Anmeldeinformationen anmelden und die Kennwörter, die Sie auf dem Server B auf die Instanz übertragen, nur dann verwenden, wenn eine der folgenden Bedingungen zutrifft:
-
Die ursprünglichen Kennwörter enthalten keine Buchstaben.
-
Alle Buchstaben in den ursprünglichen Kennwörtern sind Großbuchstaben.
-
-
Groß-/Kleinschreibung bei beiden Servern: Bei der Sortierreihenfolge von Server A und Server B muss zwischen Groß- und Kleinschreibung unterschieden werden. Ansonsten kann in der Sortierreihenfolge von Server A und Server B nicht zwischen Groß- und Kleinschreibung unterschieden werden. In diesen Fällen tritt kein Problem auf.
-
-
Eine Anmeldung, die sich bereits in der Instanz auf dem Server B befindet, hat möglicherweise einen Namen, der mit einem Namen im Ausgabeskript übereinstimmt. In diesem Fall wird die folgende Fehlermeldung angezeigt, wenn Sie das Ausgabeskript auf der Instanz auf dem Server B ausführen:
Msg 15025, Level 16, State 1, Line 1
Der Serverprinzipal „MyLogin“ ist bereits vorhanden.Entsprechend kann eine Anmeldung, die sich bereits in der Instanz auf dem Server B befindet, eine SID besitzen, die mit einer SID im Ausgabeskript identisch ist. In diesem Fall wird die folgende Fehlermeldung angezeigt, wenn Sie das Ausgabeskript auf der Instanz auf dem Server B ausführen:
Msg 15433, Level 16, State 1, Line 1
Der bereitgestellte sid-Parameter wird verwendet.Deshalb müssen Sie Folgendes tun:
-
Überprüfen Sie das Ausgabeskript sorgfältig.
-
Überprüfen Sie den Inhalt der sys.server_principals-Ansicht in der Instanz auf dem Server B.
-
Behandeln Sie diese Fehlermeldungen entsprechend.
In SQL Server 2005 wird die SID für eine Anmeldung zum Implementieren des Zugriffs auf Datenbankebene verwendet. Eine Anmeldung kann unterschiedliche SIDs in unterschiedlichen Datenbanken auf einem Server aufweisen. In diesem Fall kann die Anmeldung nur auf die Datenbank zugreifen, die die SID besitzt, die der SID in der sys.server_principals-Ansicht entspricht. Dieses Problem kann auftreten, wenn die beiden Datenbanken über verschiedene Server kombiniert werden. Um dieses Problem zu beheben, entfernen Sie manuell die Anmeldung aus der Datenbank, deren SID nicht übereinstimmt, mit der Anweisung „DROP USER“ (Benutzer löschen). Fügen Sie dann die Anmeldung erneut mithilfe der Anweisung „CREATE USER“ (Benutzer erstellen) hinzu.
-
-
Wenn Sie versuchen, eine neue Anmeldung für SQL Server 2012 mit einer Anmeldung, für die ein Skript erstellt wurde, von SQL Server 2000 oder älter zu erstellen, wird die folgende Fehlermeldung angezeigt:
Msg 15021, Level 16, State 2, Line 1
Ungültiger Wert für Parameter „KENNWORT“. Geben Sie einen gültigen Parameterwert an.
Hinweis: Dieser Fehler wird in SQL Server 2012 angezeigt aufgrund des für die Anweisungen „CREATE LOGIN“ (Anmeldung erstellen) und „ALTER LOGIN“ (Anmeldung ändern) bereitgestellten 16-Byte-Kennworthashs.
Um dieses Problem auf einem Server mit SQL Server 2012 zu beheben, erstellen Sie eine Anmeldung mit einem leeren Kennwort. Führen Sie dazu das folgende Skript aus:CREATE LOGIN [Test] WITH PASSWORD = '', SID = 0x90FD605DCEFAE14FAB4D5EB0BBA1AECC, DEFAULT_DATABASE = [master], CHECK_POLICY = ON, CHECK_EXPIRATION = OFFNachdem Sie die Anmeldung mit einem leeren Kennwort erstellt haben, kann der Benutzer das Kennwort beim nächsten Anmeldeversuch ändern.
Methode 3: Anmelden mit dem Kennwort der Version vor SQL Server 2000
Hinweis: Diese Methode ist nur relevant, wenn Sie SQL Server 2000 zu einer neueren unterstützten Version von SQL Server migrieren.
Bitten Sie den Benutzer in diesem Fall, sich auf dem Server, auf dem SQL Server ausgeführt wird, mit dem Benutzernamen der Version vor SQL Server 2000 anzumelden.
Hinweis: Das Kennworthashing wird automatisch aktualisiert, wenn sich der Benutzer mit dem Kennwort der Version vor SQL Server 2000 anmeldet.
Informationsquellen
Weitere Informationen zur Fehlerbehebung bei verwaisten Benutzern finden Sie unter Problembehandlung bei verwaisten Benutzern auf der MSDN-Website (Microsoft Developer Network).
Weitere Informationen zur Anweisung „CREATE LOGIN“ finden Sie unter CREATE LOGIN (Transact-SQL) auf der MSDN-Website.
Weitere Informationen zur Anweisung „ALTER LOGIN“ finden Sie unter ALTER LOGIN (Transact-SQL) auf der MSDN-Website.
