ACE/Server Rules

You may find it easier to perform Screen setup without SecurID first, as it adds complexities. Consider that the Screen may be in the path between the ACE/Server primary server and its secondary(ies). These things considered, it is important to create rules that allow the ACE/Servers to communicate with each other: Create an address group to contain the various ACE/Servers addresses. Create a rule that allows them to communicate with each other using the securidprop service.

The following is an example of what you type to create an address group to contain the various ACE/Servers addresses, then create a rule that allows them to communicate with each other using the securidprop service:

# ssadm edit config
edit> add rule securidprop ace-servers ace-servers ALLOW ...

The above rule assumes un-secured communication. The ACE/Server protocol uses its own encryption, but if SunScreen SKIP security is also needed, the above simple rule does not suffice.

If the Screen is in the path between the primary and secondary(ies), you can manipulate rules that can be used to test primary --> secondary fallback.

SunScreen EFS 3.0 ACE/Client Rules

You can allow the ACE/Clients to contact the ACE/Servers to perform the SecurID authentication when configuring ACE/Server rules.

The following is an example of what you type to create another address group to contain the various ACE/Client and ACE/Agent hosts addresses, then create a rule that allows them to communicate with the ACE/Server(s) in the address group created above:

# ssadm edit configedit> add rule securid ace-clients ace-servers ALLOW ...

Again, the above assumes un-secured communication and relies on the variety of forms of encryption within the ACE/Client protocol itself; but if SunScreen SKIP security is also needed, the above simple rule will not suffice.

ACE/Server Setup

Refer to the ACE/Server documentation for the setup required to get a server running.

As part of the server-side configuration, the routing-mode Screen must be configured as a Unix client on the server.

Ensure that you either add alias addresses as needed for all routing-mode interfaces or be certain that the address configured for the routing-mode Screen is the one from which SecurID requests originate toward the ACE/Server.

The result of the server-side setup is an important file named "sdconf.rec." This file contains security information required by the client to enable it to contact the server and to establish communication. Arrange for this file to be available on your system for the client-side setup.

Although it is possible to install ACE/Server on a multi-homed host, such as most SunScreen EFS 3.0 Screens, it is unfortunately not convenient to protect the ACE/Server through direct routing-mode installation.

SecurID Client Setup on a Routing-Mode Screen

To learn about the Screen as a client, see sdconf.rec from the server after it has been configured.

Two possible client mechanisms:

• Install ACE/Agent 3.3 on Solaris 2.6 SPARC.

This software is on the CD with the server. Install it per the documented instructions.

• Install ACE/Client stub.

The stub files are installed by the SUNWicgSS package:

/opt/SUNWicg/SunScreen/etc/securid_stubclient_setup /opt/SUNWicg/SunScreen/etc/securid_stubclient.tar

The first file is a script that uses the second file.

Become root in the directory where sdconf.rec resides, execute:

# /opt/SUNWicg/SunScreen/etc/securid_stubclient_setup sdconf.rec

Once the client is installed, be sure to test it.

The first time a new client contacts the ACE/Server, it receives the node secret to allow this first-time exchange.

The first authentication request must be performed as root.

You also need a SecurID token that is configured for a user and for which user is activated on the routing-mode client. A simple means to test it out is to use the SecurID PIN Server:

	# telnet localhost 3855SunScreen Vx.0 SecurID
PIN and Re-Keying Server

Type the SecurID login: user Type PASSCODE: passcode

Whether the passcode is accepted or access is denied, the client and server have exchanged the node secret.

If the above interaction receives an error about not being able to establish server communications, ensure that you used the correct login and so forth.