SQL ServerT-SQL
5
0

SQL Server logins kopieren tussen servers

Wanneer een database wordt gerestored naar een andere server, bevat deze een set users en machtigingen, maar er zijn mogelijk geen overeenkomstige logins of de logins zijn mogelijk niet gekoppeld aan dezelfde users. Dit fenomeen staat beter bekend als ‘orphaned users’.

Hoe zit dit nu ook alweer precies? Laten we beginnen met de theorie:

  • Principals zijn entiteiten die SQL Server-bronnen kunnen aanvragen.
  • Een login geeft een principal toegang tot een server.
  • Een user geeft een login toegang tot een database.

Logins worden aan users gekoppeld middels de security identifier (SID). Een login is vereist voor toegang tot de SQL Server server. Deze login moet zijn gekoppeld aan een database user. U gebruikt deze user om activiteiten te beheren in de database.

Als er geen user bestaat in een database voor een specifieke login, heeft de gebruiker die die login gebruikt geen toegang tot de database, ook al kan die gebruiker mogelijk verbinding maken met de SQL Server. Omgekeerd, als een user bestaat voor een gebruiker maar er is geen login gekoppeld, kan de gebruiker zich niet aanmelden bij de SQL Server-server.

Het proces om te verifiëren dat een bepaalde login geldig is, wordt authenticatie genoemd.

Tot zover de theorie. Laten we dit eens nader gaan onderzoeken aan de hand van een voorbeeld.

Op server WINSRV1 is een login gemaakt genaamd Mary. Deze login is geassocieerd aan de user Mary in database Playground en is lid van de db_datareader database rol.

Laten we een back-up maken van database Playground.

Deze back-up gaan we vervolgens restoren op server LT-RSD-01.

Deze server heeft echter geen login genaamd Mary.

Wel zien we dat de database user genaamd Mary inderdaad hersteld is. Deze blijkt dus inderdaad netjes te zijn meegekomen uit de back-up.

Wanneer we nu proberen in de context van Mary een query uitvoeren op een willekeurige tabel uit de Playground database…

…krijgen we een foutmelding:

Msg 15406, Level 16, State 1, Line 14
Cannot execute as the server principal because the principal “Mary” does not exist, this type of principal cannot be impersonated, or you do not have permission.

Dit was te verwachten.

Maar hoe kunnen we nu zorgen dat Mary toch een login krijgt op deze server LT-RSD-01? Hiertoe gebruiken we een stored procedure genaamd sp_help_revlogin.

Voer onderstaande code uit op de server WINSRV1, dus de server mét de login Mary.

Wanneer je deze Stored Procedure uitvoert via EXEC sp_help_revlogin, krijg je een berichtenvenster te zien met alle CREATE LOGIN commando’s.

Het gewenste commando kunnen we kopiëren en uitvoeren op de andere server LT-RSD-01.

We zien nu dat de login Mary inderdaad is aangemaakt.

Wanneer we dezelfde query op de tabel nu nogmaals uitvoeren uit de context van Mary, zien we dat de foutmelding verdwenen is.

Tags: ,

Soortgelijke Berichten

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Fill out this field
Fill out this field
Geef een geldig e-mailadres op.
Je moet de voorwaarden accepteren voordat je het bericht kunt verzenden.

Meest Bekeken Berichten

Menu