The Administration Console contains all the configuration information for all Access Manager components. If you federate your users with other servers, it stores configuration information about these users. You need to protect the Administration Console so that unauthorized users cannot change configuration settings or gain access to the information in the configuration store. When you develop a security plan for Access Manager, consider the following:
When you look for ways to secure the Administration Console from unauthorized access, consider the following:
Admin User: The admin user you create when you install the Administration Console has all rights to the Access Manager components. We recommend that you protect this account by configuring the following features:
Password Restrictions: When the admin user is created, no password restrictions are set. To ensure that the password meets your minimum security requirements, you should configure the standard eDirectory password restrictions for this account. In the Administration Console, select the view in the iManager header, then click . Browse to the admin user (found in the novell container), then click . For configuration help, use the button.
Intruder Detection: The admin user is created in the novell container. You should set up an intruder detection policy for this container. In the Administration Console, select the view in the iManager header, then click > . Select then click . Click . For configuration help, use the button.
Multiple Administrator Accounts: Only one admin user is created when you install Access Manager. If something happens to the user who knows the name of this user and password or if the user forgets the password, you cannot access the Administration Console. Novell recommends that you create at least one backup user and make that user security equivalent to the admin user. For instructions, see Section 1.3.1, Creating Multiple Admin Accounts. For other considerations when you have multiple administrators, see Section 1.3, Multiple Administrators, Multiple Sessions.
Network Configuration: You need to protect the Administration Console from Internet attacks. It should be installed behind your firewall.
If you are installing the Administration Console on its own machine, ensure that the DNS names resolve between the Identity Server and the Administration Console. This ensures that SSL security functions correctly between the Identity Server and the configuration store in the Administration Console.
Delegated Administrators: If you create delegated administrators for policy containers (see Section 1.4, Managing Delegated Administrators), be aware that they have sufficient rights to implement a cross-site scripting attack using the Deny Message in an Access Gateway Authorization policy.
They are also granted rights to the LDAP server, which gives them sufficient rights to access the configuration datastore with an LDAP browser. Modifications done with an LDAP browser are not logged by Access Manager. To enable the auditing of these events, see Activating eDirectory Auditing for LDAP Events.
Test Certificates: When you install the Administration Console, the following test certificates are automatically generated:
For tight security, we recommend that you replace these certificates, except the test-stunnel certificate, with certificates from a well-known certificate authority.
Two years after you install the Administration Console, new versions of these certificates are automatically generated as the old certificates expire. If you are using any of the test certificates in your configuration, the Administration Console cannot use the new version until you reboot the machine.
The configuration store is an embedded, modified version of eDirectory. It is backed up and restored with command line options, which back up and restore the Access Manager configuration objects in the ou=accessManagerContainer.o=novell object.
You should back up the configuration store on a regular schedule, and the ZIP file created should be stored in a secure place. See Section 2.0, Backing Up and Restoring.
In addition to backing up the configuration store, you should also install at least two Administration Consoles (a primary and a secondary). If the primary console goes down, the secondary console can keep the communication channels open between the various components. You can install up to three Administration Consoles. For installation information, see Installing Secondary Versions of the Administration Console
in the Novell Access Manager 3.1 SP2 Setup Guide.
The configuration store should not be used for a user store.
For a secure system, you need to set up either auditing or syslogging to notify the system administrator when certain events occur. The most important audit events to monitor are the following:
Configuration changes
System shutdowns and startups
Server imports and deletes
Intruder lockout detection (available only for eDirectory user stores)
User account provisioning
Audit events are device-specific. You can select events for the following devices:
Administration Console: In the Administration Console, click > .
Identity Server: In the Administration Console, click > > >
Access Gateway: In the Administration Console, click > > >
J2EE Agent: In the Administration Console, click > > .
SSL VPN: In the Administration Console, click > > > .
You can configure Access Manager to send audit events to a Novell Audit Server, a Sentinel server, or a Sentinel Log Manager. For configuration information, see Section 1.5, Enabling Auditing.
In addition to the selectable events, device-generated alerts are automatically sent to the audit server. These Management Communication Channel events have an ID of 002e0605. All Access Manager events begin with 002e except for SSL VPN events, which start with 0031. You can set up Novell Auditing to send e-mail whenever these events or your selected audit events occur. See “Configuring System Channels” in the Novell Audit 2.0 Guide.
For information about audit event IDs and field data, see Section C.0, Access Manager Audit Events and Data.
The Access Gateway also supports a syslog that allows you to send e-mail notification to system administrators. To configure this system in the Administration Console, click > > >
You can force all client communication with the Administration Console to use 128-bit encryption by modifying the server.xml file used by Tomcat. If the browser is unable to supported the encryption level specified in this file, the user is not allowed to authenticate. If the Identity Server is installed on the same machine as the Administration Console, the following procedure forces all client communication with the Identity Server to use 128-bit encryption.
At a command prompt, change to the Tomcat configuration directory:
Linux: /var/opt/novell/tomcat5/conf
Windows Server 2003: \Program Files\Novell\Tomcat\conf
Windows Server 2008: \Program Files (x86)\Novell\Tomcat\conf
To the server.xml file, add the cipher suites you want to support. For 128-bit encryption, add the following line:
ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
This is a comma separated list of the JSSE names for the TLS cipher suites.
IMPORTANT:If you enter a cipher name incorrectly, Tomcat reverts to the default values, which allow the weak ciphers to be used.
If you want to allow the SSL cipher suites, the following JSSE names can be added to the list:
For a complete list of supported cipher suites and their requirements, see “The SunJSSE Provider”.
To activate the cipher list, restart Tomcat.
Linux: Enter the following command:
/etc/init.d/novell-tomcat5 restart
Windows: Enter the following commands:
net stop Tomcat5
net start Tomcat5
(Conditional) If you have multiple Identity Servers in your cluster configuration, repeat these steps on each Identity Server.