Customize Your Multi-Tier Security The following instructions will enable you to provide greater security for your database: List all Domain aliases (aka "ServerTypes") used in your client-side DSNs. For example: Oracle 8.0.x Use a text editor to open the oplrqb.ini file which resides in the /bin sub-directory of your OpenLink server components installation. Locate [Domain Aliases] and determine how those listed above are resolved. For example: [Domain Aliases] Oracle 8.0.x = ora80 Locate the resolved names of the Domain Aliases under [Mapping Rules]. For instance: [Mapping Rules] ora80:*:*:*:*:*:* = accept generic_ora80. Determine whether any of these fields need added security. Here is a breakdown: domain_name:database:user:client_os:machine_id:app_name:operation_mode (Note: "operation_mode" refers to read-only (ro) or read-and-write (rw) access.) Build rules to govern whether connection requests will be accepted or rejected by the Broker. For instance: ora80:*:scott:*:*:*:* = reject User "scott" is not allowed to connect to this service. This rule rejects all connection attempts made by user scott, and tells them so. You can substitute any plain-text rejection message here, and it will be delivered to users who are blocked by this rule. Order each rule properly. For example: ora80:*:*:*:*:*:* = accept generic_ora80 ora80:*:*:*:*:msaccess:* = reject Microsoft Access is not allowed to connect to this service. The first rule permits access to generic_ora80 in all scenarios. The second rule is never visited, since the preceding rule permits all ora80 requests. ora80:*:*:*:*:msaccess:* = reject Microsoft Access is not allowed to connect to this service. ora80:*:*:*:*:*:* = accept generic_ora80 The first rule screens for and rejects connections requested by Microsoft Access. Connections not originating with Microsoft Access are passed on to the second rule, which permits all requests. Save your changes and exit the file. Restart your Broker.