In a distributed environment with server-to-server connectivity, there will generally be more than two servers and a large number of users. There can be duplicate AuthIDs on different servers, such as a Bob in development and a Bob in sales.
Different servers can have different levels of privileges and table access. For example, on the XDB Server develop all users might be allowed access to all tables in the products location. On the XDB Server sales, access to the orders location might be restricted to a particular group or AuthID.
The XDB Server provides several methods of security and administration control. Outbound mapping allows you to translate an AuthID (username) and password before a request is sent to a remote XDB Server, providing another method of controlling communications with other XDB Servers. Inbound mapping translates an AuthID on a remote server after login, providing another method of controlling access on an XDB Server.
Trusting allows you to bypass verifying a name and password with the system catalog tables on the remote server, eliminating one step in the login and verification process. Global security allows you to set up one server to handle all security, eliminating redundancy and reducing the possibility of erroneous entries in the system catalog tables.
In a distributed environment with multiple administrators, users and servers, cooperation among administrators is imperative. Coordination can eliminate duplicate location names and AuthIDs. Rejected logins and lack of privileges can also be avoided.
Throughout this documentation, the term primary server is used to refer to the XDB Server to which the user is connected. The term remote server is the XDB Server elsewhere on the LAN that controls the location the user wishes to access.
Be sure to read this Multiserver Security topic carefully before attempting to map AuthIDs or passwords. When using multiple servers, mappings and trusting, it is very easy to miss one step and confuse everything.