Applies to: SQL Server
Creates or updates a mapping between a login on the local instance of SQL Server and a security account on a remote server.
[ @rmtsrvname = ] N'rmtsrvname'
[ , [ @useself = ] 'useself' ]
[ , [ @locallogin = ] N'locallogin' ]
[ , [ @rmtuser = ] N'rmtuser' ]
[ , [ @rmtpassword = ] N'rmtpassword' ]
[ ; ]
[ @rmtsrvname = ] N'rmtsrvname'
The name of a linked server that the login mapping applies to. @rmtsrvname is sysname, with no default.
[ @useself = ] 'useself'
Determines whether to connect to rmtsrvname by impersonating local logins or explicitly submitting a login and password. @useself is varchar(8), with a default of
- A value of
truespecifies that logins use their own credentials to connect to @rmtsrvname, with the @rmtuser and @rmtpassword arguments being ignored.
falsespecifies that the @rmtuser and @rmtpassword arguments are used to connect to @rmtsrvname for the specified @locallogin.
If @rmtuser and @rmtpassword are set to
NULL, no login or password is used to connect to the linked server.
[ @locallogin = ] N'locallogin'
A login on the local server. @locallogin is sysname, with a default of
NULL specifies that this entry applies to all local logins that connect to @rmtsrvname. If not
NULL, @locallogin can be a SQL Server login or a Windows account. The Windows account must have access to SQL Server directly, or through membership in a Windows group.
[ @rmtuser = ] N'rmtuser'
The remote login used to connect to @rmtsrvname when @useself is
false. @rmtuser is sysname, with a default of
NULL. When the remote server is an instance of SQL Server that doesn't use Windows Authentication, @rmtuser is a SQL Server login.
[ @rmtpassword = ] N'rmtpassword'
The password associated with @rmtuser. @rmtpassword is sysname, with a default of
Return code values
0 (success) or
When a user logs on to the local server and executes a distributed query that accesses a table on the linked server, the local server must log on to the linked server on behalf of the user to access that table. Use
sp_addlinkedsrvlogin to specify the credentials that the local server uses to sign into the linked server.
To create the best query plans when you're using a table on a linked server, the query processor must have data distribution statistics from the linked server. Users that have limited permissions on any columns of the table might not have sufficient permissions to obtain all the useful statistics, and might receive a less efficient query plan and experience poor performance. If the linked server is an instance of SQL Server, to obtain all available statistics, the user must own the table or be a member of the sysadmin fixed server role, the db_owner fixed database role, or the db_ddladmin fixed database role on the linked server. SQL Server 2012 SP1 (11.0.3x) modifies the permission restrictions for obtaining statistics and allows users with SELECT permission to access statistics available through DBCC SHOW_STATISTICS. For more information, see the Permissions section of DBCC SHOW_STATISTICS (Transact-SQL).
A default mapping between all logins on the local server and remote logins on the linked server is automatically created by executing
sp_addlinkedserver. The default mapping states that SQL Server uses the user credentials of the local login when connecting to the linked server on behalf of the login. This is equivalent to executing
sp_addlinkedsrvlogin with @useself set to
true for the linked server, without specifying a local user name. Use
sp_addlinkedsrvlogin only to change the default mapping or to add new mappings for specific local logins. To delete the default mapping or any other mapping, use
Instead of having to use
sp_addlinkedsrvlogin to create a predetermined login mapping, SQL Server can automatically use the Windows security credentials (Windows login name and password) of a user issuing the query to connect to a linked server when all the following conditions exist:
A user is connected to SQL Server by using Windows Authentication Mode.
Security account delegation is available on the client and sending server.
The provider supports Windows Authentication Mode; for example, SQL Server running on Windows.
Delegation doesn't have to be enabled for single-hop scenarios, but it's required for multiple-hop scenarios.
After the authentication has been performed by the linked server by using the mappings that are defined by executing
sp_addlinkedsrvlogin on the local instance of SQL Server, the permissions on individual objects in the remote database are determined by the linked server, not the local server.
sp_addlinkedsrvlogin can't be executed from within a user-defined transaction.
Requires ALTER ANY LOGIN permission on the server.
A. Connect all local logins to the linked server by using their own user credentials
The following example creates a mapping to make sure that all logins to the local server connect through to the linked server
Accounts by using their own user credentials.
EXEC sp_addlinkedsrvlogin 'Accounts';
EXEC sp_addlinkedsrvlogin 'Accounts', 'true';
If there are explicit mappings created for individual logins, they take precedence over any global mappings that might exist for that linked server.
B. Connect a specific login to the linked server by using different user credentials
The following example creates a mapping to make sure that the Windows user
Domain\Mary connects through to the linked server
Accounts by using the login
MaryP and password
EXEC sp_addlinkedsrvlogin 'Accounts', 'false', 'Domain\Mary', 'MaryP', 'd89q3w4u';
This example doesn't use Windows Authentication. Passwords will be transmitted unencrypted. Passwords might be visible in data source definitions and scripts that are saved to disk, in backups, and in log files. Never use an administrator password in this kind of connection. Consult your network administrator for security guidance specific to your environment.