| |
Home |
![[Table of Contents]](/dwicons/b_toc.gif)
|
System Administration Guide (Online Only) |
![[-]](/dwicons/i_colpse.gif)
| Chapter 13 Managing Remote Servers |
Chapter 13
This chapter discusses the steps the System Administrator and System Security Officer of each Adaptive Server must execute to enable remote procedure calls (RPCs).
Users on a local Adaptive Server can execute stored procedures on a remote Adaptive Server. Executing an RPC sends the results of the remote process to the calling process--usually displayed on the user's screen.
The use of remote servers is not included in the evaluated configuration.
To enable RPCs, the System Administrator and System Security Officer of each Adaptive Server must execute the following steps:
On the local server:
System Security Officer - use sp_addserver to list the local server and remote server in the system table master..sysservers.
List the remote server in the interfaces file or Directory Service for the local server.
Restart the local server so the global variable @@servername is set to the name of the local server. If this variable is not set properly, users cannot execute RPCs from the local server on any remote server.
On the remote server:
System Security Officer - use sp_addserver to list the server originating the RPC in the system table master..sysservers.
To allow the user who is originating the remote procedure access to the server, a System Security Officer uses sp_addlogin, and a System Administrator uses sp_addremotelogin.
Add the remote login name as a user of the appropriate database and grant that login permission to execute the procedure. (If execute permission is granted to "public", the user does not need to be granted specific permission.)
Figure 13-1 shows how to set up servers for remote access.
Figure 13-1: Setting up servers to allow remote procedure calls
For operating-system-specific information about handling remote servers, see the the installation documentation for your platform.
Table 13-1 lists the tasks related to managing remote servers and the system procedures you use to perform the tasks.
To | Use | See |
Add a remote server | sp_addserver | |
Manage remote server names | sp_addserver | |
Change server connection options | sp_serveroption | |
Display information about servers | sp_helpserver | |
Drop a server | sp_dropserver |
A System Security Officer uses sp_addserver to add entries to the sysservers table. On the server originating the call, you must add one entry for the local server, and one for each remote server that your server will call.
When you create entries for a remote server, you can either:
Refer to them by the name listed in the interfaces file, or
Provide a local name for the remote server. For example, if the name in the interfaces file is "MAIN_PRODUCTION," you may want to call it simply "main."
The syntax is:
sp_addserver lname [{, local | null}
[, pname]]where:
lname - provides the local "call name" for the remote server. If this name is not the same as the remote server's name in the interfaces file, you must provide that name as the third parameter, pname.
The remote server must be listed in the interfaces file on the local machine. If it's not listed, copy the interfaces file entry from the remote server and append it to your existing interfaces file. Be sure to keep the same port numbers.
local - identifies the server being added as a local server. The local value is used only after start-up, or after a restart, to identify the local server name so that it can appear in messages printed out by Adaptive Server. null specifies that this server is a remote server.
For users to be able to run RPCs successfully from the local server, the local server must be added with the local option and restarted. The restarting is required to set the global variable @@servername.
pname - is the remote server listed in the interfaces file for the server named lname. This optional argument permits you to establish local aliases for any other Adaptive Server, Open Server(TM), or Backup Server that you may need to communicate with. If you do not specify pname, it defaults to lname.
This example creates an entry for the local server named DOCS:
sp_addserver DOCS, local
This example creates an entry for a remote server named GATEWAY:
sp_addserver GATEWAY
To run a remote procedure such as sp_who on the GATEWAY server, execute either:
GATEWAY.sybsytemprocs.dbo.sp_who
or:
GATEWAY...sp_who
This example gives a remote server called MAIN_PRODUCTION the local alias "main:"
sp_addserver main, null, MAIN_PRODUCTION
The user can then enter:
main...sp_who
The master.dbo.sysservers table has two name columns:
srvname is the unique server name that users must supply when executing remote procedure calls.
srvnetname is the server's network name, which must match the name in the interfaces file.
To add or drop servers from your network, you can use sp_addserver to update the server's network name in srvnetname.
For example, to remove the server MAIN from the network, and move your remote applications to TEMP, you can use the following statement to change the network name, while keeping the local alias:
sp_addserver MAIN, null, TEMP
sp_addserver displays a message telling you that it is changing the network name of an existing server entry.
sp_serveroption sets the server options timeouts, net password encryption, rpc security model A, and rpc security model B, which affect connections with remote servers. Additionally, if you have set the remote procedure security model to rpc security model B, you can use sp_serveroption to set these additional options: security mechanism, mutual authentication, use message confidentiality, and use message integrity.
The options you specify for sp_serveroption do not affect the communication between Adaptive Server and Backup Server.
The following sections describe timeouts, net password encryption, rpc security model A, and rpc security model B. For information about the additional options you can specify when rpc security model B is on, see "Establishing security for remote procedures".
Using the timeouts optionA System Administrator can use the timeouts option to disable and enable the normal timeout code used by the local server.
By default, timeouts is set to true, and the site handler process that manages remote logins times out if there has been no remote user activity for one minute. By setting timeouts to false on both of the servers involved in remote procedure calls, the automatic timeout is disabled. This example changes timeouts to false:
sp_serveroption GATEWAY, "timeouts", false
After you set timeouts to false on both servers, when a user executes an RPC in either direction, the site handler on each machine runs until one of the servers is shut down. When the server is brought up again, the option remains false, and the site handler will be reestablished the next time a user executes an RPC. If users execute RPCs frequently, it is probably efficient in terms of system resources to set this option to false, since there is some system overhead involved in setting up the physical connection.
Using the net password encryption optionA System Security Officer can use net password encryption to specify whether connections with a remote server are to be initiated with a client-side password encryption handshake or with the usual unencrypted password handshake sequence. The default is false.
If net password encryption is set to true:
The initial login packet is sent without passwords.
The client indicates to the remote server that encryption is desired.
The remote server sends back an encryption key, which the client uses to encrypt its plain text passwords.
The client then encrypts its own passwords, and the remote server uses the key to authenticate them when they arrive.
This example sets net password encription to true:
sp_serveroption GATEWAY, "net password encryption",
trueThis option does not affect Adaptive Server's interaction with Backup Server.
Using the rpc security model optionsThe rpc security model A and rpc security model B options determine what kind of security is available for RPCs. If you use model A, which is the default, Adaptive Server does not support security services such as message confidentiality via encryption between the two servers.
For security model B, the local Adaptive Server gets a credential from the security mechanism and uses the credential to establish a secure physical connection with the remote Adaptive Server. With this model, you can choose one or more of these security services: mutual authentication, message confidentiality via encryption, and message integrity.
To set security model A for the server GATEWAY, execute:
sp_serveroption GATEWAY, "rpc security model A", true
For information about how to set up servers for Security Model B, see "Establishing security for remote procedures".
sp_helpserver reports on servers. Without an argument, it provides information about all the servers listed in sysservers. When you include a server name, it provides information about that server only. The syntax is:
sp_helpserver [server]
sp_helpserver checks for both srvname and srvnetname in the master..sysremotelogins table.
For operating-system-specific information about setting up remote servers, see the the installation documentation for your platform.
A System Security Officer can use the sp_dropserver system procedure to drop servers from sysservers. The syntax is:
sp_dropserver server [, droplogins]
where:
server - is the name of the server you want to drop.
droplogins - allows you to drop a remote server and all of that server's remote login information in one step. If you do not use droplogins, you cannot drop a server that has remote logins associated with it.
The following statement drops the GATEWAY server and all of the remote logins associated with it:
sp_dropserver GATEWAY, droplogins
You don't have to use droplogins if you want to drop the local server; that entry does not have remote login information associated with it.
The System Security Officer and System Administrator of any Adaptive Server share control over which remote users can access the server, and what identity the remote users assume. The System Administrator uses sp_addremotelogin to add remote logins and sp_dropremotelogin to drop remote logins. The System Security Officer uses sp_remoteoption to control whether password checking will be required.
Logins from a remote server can be mapped to a local server in three ways:
A particular remote login can be mapped to a particular local login name. For example, user "joe" on the remote server might be mapped to "joesmith".
All logins from one remote server can be mapped to one local name. For example, all users sending remote procedure calls from the MAIN server might be mapped to "remusers".
All logins from one remote server can use their remote names.
The first option can be combined with the other two options, and its specific mapping takes precedence over the other two more general mappings. The second and third options are mutually exclusive; you can use either of them, but not both.
Use sp_dropremotelogin to remove the old mapping.
Use sp_addremotelogin to add remote logins. The syntax is:
sp_addremotelogin remoteserver [, loginame
[, remotename]]If the local names are not listed in master..syslogins, add them as Adaptive Server logins with sp_addlogin before adding the remote logins.
Only a System Administrator can execute sp_addremotelogin. For more information, see the Reference Manual.
The following example maps the login named "pogo" from a remote system to the local login name "bob". The user logs in to the remote system as "pogo". When that user executes remote procedure calls from GATEWAY, the local system maps the remote login name to "bob".
sp_addlogin bob sp_addremotelogin GATEWAY, bob, pogo
The following example creates an entry that maps all remote login names to the local name "albert". All names are mapped to "albert", except those with specific mappings, as described in the previous section. For example, if you mapped "pogo" to "bob", and then the rest of the logins to "albert", "pogo" still maps to "bob".
sp_addlogin albert sp_addremotelogin GATEWAY, albert
If you use sp_addremotelogin to map all users from a remote server to the same local name, use sp_remoteoption to specify the "trusted" option for those users. For example, if all users from server GATEWAY that are mapped to "albert" are to be trusted, specify:
sp_remoteoption GATEWAY, albert, NULL, trusted, true
If you do not specify the logins as trusted, the logins will not be allowed to execute RPCs on the local server unless they specify passwords for the local server when they log in to the remote server. Users, when they use Open Client Client-Library can use the routine ct_remote_pwd to specify a password for server-to-server connections. isql and bcp do not permit users to specify a password for RPC connections. See "Password checking for remote users" for more information about sp_remoteoption.
Warning!
Do not map more than one remote login to a single local login, as it reduces individual accountability on the server. Audited actions can be traced only to the local server login, not to the individual logins on the remote server.
If users are logged into the remote server using "unified login", the logins must also be trusted on the local server, or they must specify passwords for the server when they log into the remote server. For information about "unified login", see "Using unified login".
Warning!
Using the trusted mode of sp_remoteoption reduces the security of your server, as passwords from such "trusted" users are not verified.
To enable remote users to keep their remote login names while using a local server:
Use sp_addlogin to create a login for each login from the remote server.
Use sp_addremotelogin for the server as a whole to create an entry in master..sysremotelogins with a null value for the remote login name and a value of -1 for the suid. For example:
sp_addremotelogin GATEWAY
This statement displays the local and remote server information recorded in master..sysservers:
select srvid, srvname from sysservers
srvid srvname
----- ----------
0 SALES
1 CORPORATE
2 MARKETING
3 PUBLICATIONS
4 ENGINEERINGThe SALES server is local. The other servers are remote.
This statement displays information about the remote servers and users stored in master..sysremotelogins:
select remoteserverid, remoteusername, suid from sysremotelogins
remoteserverid remoteusername suid -------------- -------------- ------ 1 joe 1 1 nancy 2 1 NULL 3 3 NULL 4 4 NULL -1
By matching the value of remoteserverid in this result and the value of srvid in the previous result, you can find the name of the server for which the remoteusername is valid. For example, in the first result, srvid 1 indicates the CORPORATE server; in the second result remoteserverid 1 indicates that same server. Therefore, the remote user login names "joe" and "nancy" are valid on the CORPORATE server.
The following statement shows the entries in master..syslogins:
select suid, name from syslogins
suid name
------ ------------
1 sa
2 vp
3 admin
4 writerThe results of all three queries together show:
The remote user name "joe" (suid 1) on the remote CORPORATE server (srvid and remoteserverid 1) is mapped to the "sa" login (suid 1).
The remote user name "nancy" (suid 2) on the remote CORPORATE server (srvid and remoteserverid 1) is mapped to the "vp" login (suid 2).
The other logins from the CORPORATE server (remoteusername "NULL") are mapped to the "admin" login (suid 3).
All logins from the PUBLICATIONS server (srvid and remoteserverid 3) are mapped to the "writer" login (suid 4).
All logins from the ENGINEERING server (srvid and remoteserverid 4) are looked up in master..syslogins by their remote user names (suid -1).
There is no remoteserverid entry for the MARKETING server in sysremotelogins. Therefore, users who log in to the MARKETING server cannot run remote procedure calls from that server.
The remote user mapping procedures and the ability to set permissions for individual stored procedures give you control over which remote users can access local procedures. For example, you can allow the "vp" login from the CORPORATE server to execute certain local procedures and all other logins from CORPORATE to execute the procedures for which the "admin" login has permission.
In many cases, the passwords for users on the remote server must match passwords on the local server.
A System Security Officer can use sp_remoteoption to determine whether passwords will be checked when remote users log in to the local server. By default, passwords are verified ("untrusted" mode). In trusted mode, the local server accepts remote logins from other servers and front-end applications without user-access verification for the particular login.
When sp_remoteoption is used with arguments, it changes the mode for the named user. The syntax is:
sp_remoteoption [remoteserver, loginame, remotename,
optname, {true | false}] The following example sets trusted mode for the user "bob":
sp_remoteoption GATEWAY, pogo, bob, trusted,
trueThe effects of the "untrusted" mode depend on the user's client program. isql and some user applications require that logins have the same password on the remote server and the local server. Open Client(TM) applications can be written to allow local logins to have different passwords on different servers.
To change your password in "untrusted" mode, you must first change it on all the remote systems you access before changing it on your local server. This is because of the password checking. If you change your password on the local server first, when you issue the remote procedure call to execute sp_password on the remote server your passwords will no longer match.
The syntax for changing your password on the remote server is:
remote_server...sp_password caller_passwd, new_passwd
On the local server, the syntax is:
sp_password caller_passwd, new_passwd
See "Changing passwords" for more information about changing your password.
sp_helpremotelogin prints information about the remote logins on a server. The following example shows the remote login "pogo" mapped locally to login name "bob", with all other remote logins keeping their remote names.
sp_helpremotelogin
server remote_user_name local_user_name options --------- ---------------- ----------------- -------- GATEWAY **mapped locally** **use local name** untrusted GATEWAY pogo bob untrusted
Table 13-2 shows the configuration parameters that affect RPCs. All these configuration parameters are set using sp_configure and do not take effect until Adaptive Server is restarted.
Configuration parameter | Default |
allow remote access | 1 |
number of remote logins | 20 |
number of remote sites | 10 |
number of remote connections | 20 |
remote server pre-read packets | 3 |
To allow remote access to or from a server, including Backup Server, set allow remote access to 1:
sp_configure "allow remote access", 1
To disallow remote access at any time, set allow remote access to 0:
sp_configure "allow remote access", 0
Only a System Security Officer can set the allow remote access parameter.
You cannot perform database or transaction log dumps while the allow remote access parameter is set to 0.
To set the number of active user connections from this site to remote servers, use number of remote logins. This command sets number of remote logins to 50:
sp_configure "number of remote logins", 50
Only a System Administrator can set the number of remote logins parameter.
To control the number of remote sites that can access a server simultaneously, use number of remote sites. All accesses from an individual site are managed by one site handler. This parameter controls the number of site handlers, not the number of individual, simultaneous procedure calls. For example, if you set number of remote sites to 5, and each site initiates three remote procedure calls, sp_who shows 5 site handler processes for the 15 processes. Only a System Administrator can set the number of remote sites.
To control the limit on active remote connections that are initiated to and from a server, use the number of remote connections parameter. This parameter controls connections initiated from the server and connections initiated from remote sites to the server. Only a System Administrator can set number of remote connections.
To reduce the needed number of connections, all communication between two servers is handled through one site handler. This site handler can preread and keep track of data packets for each user before the user process that needs them is ready.
To control how many packets a site handler will preread, use remote server pre-read packets. The default value, 3, is adequate in all cases; higher values can use too much memory. Only a System Administrator can set remote server pre-read packets. For more information, see "remote server pre-read packets".
|
|