Übertragen von Benutzernamen und Kennwörtern zwischen Instanzen von SQL Server

Gilt für: Microsoft SQL Server 2005 Standard EditionMicrosoft SQL Server 2005 Workgroup EditionMicrosoft SQL Server 2005 Developer Edition

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:
  1. 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.
  2. Ö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.
  3. 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):

  1. 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.
  2. Ö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:
    1. Überprüfen Sie das Ausgabeskript sorgfältig.
    2. Überprüfen Sie den Inhalt der sys.server_principals-Ansicht in der Instanz auf dem Server B.
    3. 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 = OFF
    Nachdem 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.