SQL Server Backup and Restore - Simple Talk

Chapter 4: Restoring From Full Backup
production. Even if a user doesn't have a login on the production database server, the
restored database still holds the permissions. If that user is eventually given access to
the production machine, he or she will automatically have that level of access, even if it
wasn't explicitly given by the DBA team.
The only case when this may not happen is when the user is using SQL Server authentication
and the internal SID, a unique identifying value, doesn't match on the original and
target server. If two SQL logins with the same name are created on different machines,
the underlying SIDs will be different. So, when we move a database from Server A to
Server B, a SQL login that has permission to access Server A will also be moved to Server
B, but the underlying SID will be invalid and the database user will be "orphaned." This
database user will need to be "de-orphaned" (see below) before the permissions will be
valid. This will never happen for matching Active Directory accounts since the SID is
always the same across a domain.
In order to prevent this from happening in our environments, every time we restore a
database from one environment to another we should:
• audit each and every login – never assume that if a user has certain permissions in one
environment they need the same in another; fix any internal user mappings for logins
that exist on both servers, to ensure no one gets elevated permissions
• perform orphaned user maintenance – remove permissions for any users that do not
have a login on the server to which we are moving the database; the sp_change_
users_login stored procedure can help with this process, reporting all orphans,
linking a user to its correct login, or creating a new login to which to link:
• EXEC sp_change_users_login 'Report'
• EXEC sp_change_users_login 'Auto_Fix', 'user'
• EXEC sp_change_users_login 'Auto_Fix', 'user', 'login',
'password'
121