Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims
any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.,
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on
the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws.
You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the
Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on
exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export
approvals.
We want to hear your comments and suggestions about this guide and the other documentation
included with this product. Please use the User Comments feature at the bottom of each page of the
online documentation, or go to Documentation Feedback (http://www.novell.com/documentation/
feedback.html) at www.novell.com/documentation/feedback.html and enter your comments there.
About This Guide9
Documentation Updates
For the most recent version of the Access Manager Administration Guide, visit the Novell Access
Manager Documentation Web site (http://www.novell.com/documentation/novellaccessmanager).
Additional Documentation
Before proceeding, you should be familiar with the Novell Access Manager 3.1 SP1 Installation
Guide and the Novell Access Manager 3.1 SP1 Setup Guide, which provides information about
setting up the Access Manager system.
For information about the other Access Manager devices and features, see the following:
Novell Access Manager 3.1 SP1 Identity Server Guide
Novell Access Manager 3.1 SP1 SSL VPN Server Guide
Novell Access Manager 3.1 SP1 Event Codes
novdocx (en) 19 February 2010
Documentation Conventions
In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and
items in a cross-reference path.
A trademark symbol (
®
, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party
trademark.
When a single pathname can be written with a backslash for some platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux* or UNIX*, should use forward slashes as required by your software.
This section discusses the following Administration Console topics:
Section 1.1, “Security Considerations,” on page 11
Section 1.2, “Administration Console Conventions,” on page 14
Section 1.3, “Configuring the Default View,” on page 14
Section 1.4, “Changing the Administration Console Session Timeout,” on page 17
Section 1.5, “Changing the Password for the Administration Console,” on page 17
Section 1.6, “Multiple Administrators, Multiple Sessions,” on page 18
Section 1.7, “Enabling Auditing,” on page 23
For information about installing secondary consoles for fault tolerance, see “Clustering and Fault
Tolera nce” in the Novell Access Manager 3.1 SP1 Setup Guide.
novdocx (en) 19 February 2010
1
For troubleshooting information about converting a secondary console into a primary console, see
Section 6.7, “Converting a Secondary Console into a Primary Console,” on page 95.
1.1 Security Considerations
When developing a security plan for Access Manager, consider the following:
Section 1.1.1, “Access Manager Administration Console,” on page 11
Section 1.1.2, “Configuration Store,” on page 13
Section 1.1.3, “Auditing and Event Notification,” on page 13
1.1.1 Access Manager Administration Console
When looking for ways to secure the Administration Console, 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
select the Roles and Tasks icon in the iManager header, then click Users. Browse to the admin
user (found in the novell container), then click Restrictions. For configuration help, use the
Help button.
Intruder Detection: The admin user is created in the novell policy container. You should set
up a intruder detection policy for this container. In the Administration Console, select the Roles and Tasks icon in the iManager header, then click Directory Administration > Modify Object.
Select novell, then click OK. Click Intruder Detection. For configuration help, use the Help
button.
TM
password restrictions for this account. In the Administration Console,
Administration Console
11
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 back up user and to make that user security equivalent
to the admin user. In the Administration Console, select the Roles and Tasks icon in the
iManager header, then click Users > Create User. After creating the user, select to modify the
user and make the user security equal to the admin user. For other considerations when you
have multiple administrators, see Section 1.6, “Multiple Administrators, Multiple Sessions,” on
page 18.
Network Configuration: You need to protect the Administration Console from Internet attacks. It
should be installed behind your firewall.
If you install secondary consoles for redundancy, these secondary consoles should be on the same
network. For a secure system, they should not be required to cross routers to communicate with each
other.
Also, if you are installing the Administration Console on a separate 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.
novdocx (en) 19 February 2010
Delegated Administrators: If you create delegated administrators for policy containers (see
Section 1.6.2, “Managing Delegated Administrators,” on page 19), 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” on page 22.
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, “Backing Up and Restoring Components,” on page 31.
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.
The configuration store should not be used for a user store.
1.1.3 Auditing and Event Notification
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:
novdocx (en) 19 February 2010
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 Auditing > Novell Auditing.
Identity Server: In the Administration Console, click Devices > Identity Servers > Edit >
Logging.
Access Gateway: In the Administration Console, click Devices > Access Gateways > Edit >
Novell Audit.
J2EE Agent: In the Administration Console, click Devices > J2EE Agents > Edit.
SSL VPN: In the Administration Console, click Devices > SSL VPNs > Edit > Novell Audit
Settings.
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. SSL VPN starts 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”
(http://www.novell.com/documentation/novellaudit20/novellaudit20/data/al6t4sd.html) in the
Novell Audit 2.0 Guide (http://www.novell.com/documentation/novellaudit20/treetitl.html).
For information about audit event IDs and field data, see Appendix D, “Access Manager Audit
Events and Data,” on page 121.
Administration Console13
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 Devices > Access Gateways > Edit > Alerts.
1.2 Administration Console Conventions
The required fields on a configuration page contain an asterisk by the field name.
All actions such as delete, stop, and purge require verification before they are executed.
Changes are not applied to a server until you update the server.
Sessions are monitored for activity. If your session becomes inactive, you are asked to log in
again and unsaved changes are lost.
Do not use the browser Back button. If you need to move back, use one of the following when
available:
Click the Cancel button.
Click a link in the breadcrumb path that is displayed under the menu bar.
Use the menu bar to select a location.
novdocx (en) 19 February 2010
Right-clicking links in the interface, then selecting to open the link in a new tab or window is
not supported. If you are in the Roles and Task view and the left navigation panel is not present
in the window or tab, close the session and start a new one.
The Administration Console uses a modified version of iManager. You cannot use standard
iManager features or plug-ins with the Access Manager version of the product.
If you access the Administration Console as a protected Access Gateway resource, you cannot
configure it for single sign-on. The version of iManager used for the Administration Console is
not compatible with either Identity Injection or Form Fill for single sign-on.
1.3 Configuring the Default View
Access Manager has two views in the Administration Console. Access Manager 3.0 and its Support
Packs used the Roles and Tasks view, with Access Manager as the first listed task in the left hand
navigation frame. It looks similar to the following:
Other tasks that you occasionally need to manage the configuration datastore are visible.
If you are familiar with 3.0, you do not need to learn new ways to navigate to configure
options.
Access Manager 3.1 introduces a new view, the Access Manager view. It looks similar to the
following:
Administration Console15
Figure 1-2 Access Manager View
This view has the following advantages:
You can follow a path to a Identity Server cluster configuration or an Access Gateway proxy
service with one click. The following image shows the path to the My_Reverse proxy service
of the LAG_2 Access Gateway.
novdocx (en) 19 February 2010
It can remember where you have been. For example, if you are configuring the Access
Gateway and need to check a setting for a Role policy, you can go view that setting, and if you
click the Devices tab, the Administration Console remembers where you were in the Identity
Server configuration. If you click Access Gateways, it resets to that view.
With the navigation moved to the top of the page, the wider configuration pages no longer
require a scroll bar to see all of the options.
Navigation is faster.
When you install or upgrade to Access Manager 3.1 and log in to the Administration Console, the
default view is set to the Access Manager view.
2 Click either the Roles and Tasks view or the Access Manager view .
To set a permanent default view:
1 In the iManager Header frame, click the Preferences view.
2 In the left navigation frame, click Set Initial View.
3 Select your preferred view, then click OK.
1.4 Changing the Administration Console
Session Timeout
The
web.xml
inactive before the session times out and the administrator must authenticate again. The default
value is 30 minutes.
file for Tomcat specifies how long an Administration Console session can remain
novdocx (en) 19 February 2010
To change this value:
1 Change to the Tomcat configuration directory:
Linux:
Windows:
2 Open the
3 Modify the value and save the file.
4 Restart Tomcat:
Linux:
Windows:
/etc/opt/novell/tomcat5/web.xml
C:\Program Files\Novell\Tomcat\conf
web.xml
/etc/init.d/novell-tomcat5 restart
net stop Tomcat5
net start Tomcat5
file in a text editor and search for the
<session-timeout>
parameter.
1.5 Changing the Password for the
Administration Console
The admin of the Administration Console is a user created in the novell container of the
configuration store. To change the password:
1 In the Administration Console, click Users > Modify User.
2 Click the Object Selector icon.
3 Browse the novell container and select the name of the admin user, then click OK.
4 Click Restrictions > Set Password.
5 Enter a password in the New password text box.
6 Confirm the password in the Retype new password text box.
7 Click OK twice.
Administration Console
17
1.6 Multiple Administrators, Multiple Sessions
The Administration Console has been designed to warn you when another administrator is making
changes to a policy container or to an Access Manager device (such as an Access Gateway, SSL
VPN, or J2EE Agent). The person who is currently editing the configuration is listed at the top of the
page with an option to unlock and with the person’s distinguished name and IP address. If you select
to unlock, you destroy all changes the other administrator is currently working on.
WARNING: Currently, locking has not been implemented on the pages for modifying the Identity
Server. If you have multiple administrators, they need to coordinate with each other so that only one
administrator is modifying an Identity Server cluster at any given time.
Multiple Sessions: You should not start multiple sessions to the Administration Console with the
same browser on a workstation. Browser sessions share settings that can result in problems when
you apply changes to configuration settings. However, if you are using two different brands of
browsers simultaneously, such as Internet Explorer* and Firefox*, it is possible to avoid the session
conflicts.
Multiple Administration Consoles: As long as the primary console is running, all configuration
changes should be made at the primary console. If you make changes at both a primary console and
a secondary console, browser caching can cause you to create an invalid configuration.
novdocx (en) 19 February 2010
The following sections explain how to create additional administrator accounts and how to delegate
rights to administrators:
Section 1.6.1, “Multiple Admin Accounts,” on page 18
Section 1.6.2, “Managing Delegated Administrators,” on page 19
1.6.1 Multiple Admin Accounts
The Administration Console is installed with one admin user account. If you have multiple
administrators, you might want to create a user account for each one so that log files reflect the
modifications of each administrator. The easiest way to do this is to create an account for each
administrator and make the user security equivalent to the admin user. You can also create delegated
administrators and configure them to have rights to specific components of Access Manager. For
configuration information for this type of user, see Section 1.6.2, “Managing Delegated
Administrators,” on page 19.
To create a user who is security equivalent to the admin user:
1 In the Administration Console from the Roles and Tasks view, click Users > Create User.
2 Create a user account for each administrator.
3 Click Modify User, then select the created user.
4 Click Security > Security Equal To.
5 Select the admin user, then click Apply > OK.
6 Repeat Step 3 through Step 5 for each user you want to make security equivalent to the admin
As the Access Manager admin user, you can create delegated administrators to manage the
following Access Manager components.
Individual Access Gateways or an Access Gateway cluster
Identity Server clusters
Individual J2EE agents or a J2EE agent cluster
Individual SSL VPN servers or an SSL VPN cluster
Policy containers
IMPORTANT: You need to trust the users you assign as delegated administrators. They are granted
sufficient rights that they can compromise the security of the system. For example if you create
delegated administrators with View/Modify rights to policy containers, be aware that they have
sufficient rights to implement a cross-site scripting attack using the Deny Message in an Access
Gateway Authorization policy.
Delegated administrators are also granted rights to the LDAP server, which means they can access
the configuration datastore with an LDAP browser. Any modifications made with the LDAP
browser are not logged by Access Manager. To log monitor events, you need to turn on eDirectory
auditing. For configuration information, see “Activating eDirectory Auditing for LDAP Events” on
page 22.
novdocx (en) 19 February 2010
By default, all users except the admin user are assigned no rights to the policy containers and the
devices. The admin user has all rights and cannot be configured to have less than all rights. The
admin user is the only user who has the rights to delegate rights to other users, and the only user with
sufficient rights to modify keystores, create certificates, and import certificates.
The configuration pages for delegated administrators control access to the Access Manager pages.
They do not control access to the tasks available for the Roles and Tasks view in iManager. If you
want your delegated administrators to have rights to any of these tasks such as Directory
TM
Administration or Groups, you must use eDirectory
methods to grant the user rights to these tasks
or enable and configure Role-Based Services in iManager.
To create a delegated administrator, you must first create the user accounts, then assign them rights
to the Access Manager components.
1 In the Administration Console, select the Roles and Tasks view from the iManager view bar.
2 (Optional) If you want to create a container for your delegated administrators, click Directory
Administration > Create Object, then create a container for the administrators.
3 To create the users, click Users > Create User and create user accounts for your delegated
administrators.
4 Return to the Access Manager view, then click Administrators in the Access Manager menu.
5 Select the component you want to assign a user to manage.
For more information about the types of rights you might want to assign for each component,
see the following
“Access Gateway Administrators” on page 20
“Policy Container Administrators” on page 21
“Identity Server Administrators” on page 21
Administration Console19
“SSL VPN Administrators” on page 22
“J2EE Agent Administrators” on page 22
6 To assign all delegated administrators the same rights to a component, configure All Users by
using the drop-down menu and selecting None, Vi ew Onl y, or View/ Modi fy.
By default, All Users is configured for None. All Users is a quick way to assign everyone View
Only rights to a component when you want your delegated administrators to have the rights to
view the configuration but not change it.
7 To select one or more users to assign rights, click Add, then fill in the following fields:
Name filter: Specify a string that you want the user’s cn attribute to match. The default value
is an asterisk, which matches all cn values.
Search from context: Specify the context you want used for the search. Click the down-arrow
to select from a list of available contexts.
Include subcontainers: Specifies whether subcontainers should be searched for users.
8 Click Query, and the User section is populated with the users that match the query.
9 In the User section, select one or more users to whom you want to grant the same rights.
10 For the Access option, click the down-arrow and select one of the following values:
View/Modify: Grants full configuration rights to the device. View/Modify rights do not grant
the rights to manage keystores, to create certificates, or to import certificates from other servers
or certificate authorities. View/Modify rights allow the delegated administrator to perform
actions such as stop, start, and update the device.
If the assignment is to a policy container, this option grants the rights to create policies of any
type and to modify any existing policies in the container
View Only: Grants the rights to view all the configuration options of the device or all rules and
conditions of the policies in a container.
novdocx (en) 19 February 2010
None: Prevents the user from seeing the device or the policy container.
11 In the Device or Policy Containers section, select the devices, the clusters, or policy containers
that you want to assign for delegated administration.
12 Click Apply.
The rights are immediately assigned to the selected users. If the user already had a rights
assignment to the device or policy container, this new assignment overwrites any previous
assignments.
13 After assigning a user rights, check the user’s effective rights.
A user’s effective rights and assigned rights do not always match. For example, if Kim is
granted View Only rights but All Users have been granted View/Modify rights, Kim’s effective
rights are View/Modify.
When a user is granted View/Modify rights to a device, the user is automatically assigned View
Only rights to the policy containers. If you explicitly remove the View Only rights from the
policy containers, the user no longer has the rights to view the policies for that device.
Access Gateway Administrators
You can assign a user to be a delegated administrator of an Access Gateway cluster or a single
Access Gateway that does not belong to a cluster. You cannot assign a user to manage a single
member of a cluster.
When a delegated administrator of an Access Gateway cluster is granted View/Modify rights, the
administrator has sufficient rights to change the cluster configuration, to stop and start (or reboot and
shutdown), and to update the Access Gateways in the cluster. However, to configure the Access
Gateway to use SSL, you need to be the admin user, rather than a delegated administrator.
When the user is assigned View/Modify rights to manage a cluster or an Access Gateway, the user is
automatically granted View Only rights to the policy containers. This allows the delegated
administrator to view the policies and assign them to protected resources. It does not allow them to
modify the policies. If you want the delegated administrator to modify or create policies, you need to
grant View/Modify rights to a policy container.
View/Modify rights to an Access Gateway or a cluster also grants View Only rights to the Identity
Server cluster configuration. This allows the delegated administrator to modify which Identity
Server cluster the Access Gateway uses for authentication. It does not allow them to update the
Identity Server configuration, which is required whenever the Access Gateway is configured to trust
an Identity Server. To update the Identity Server, the delegated administrator needs View/Modify
rights to the Identity Server configuration.
Policy Container Administrators
novdocx (en) 19 February 2010
All delegated administrators with View/Modify rights to a device have read rights to the policy
containers. To create or modify policies, a delegated administrator needs View/Modify rights to a
policy container. When a delegated administrator has View/Modify rights to any policy container,
the delegated administrator is also granted enough rights to allow the administrator to select shared
secret values, attributes, LDAP groups, and LDAP OUs to policies.
If you want your delegated administrators to have full control over a device and its policies, you
might want to create a separate policy container for each delegated administrator or for each device
that is managed by a group of delegated administrators.
Identity Server Administrators
You cannot assign a delegated administrator to an individual Identity Server. You can only assign a
delegated administrator to a cluster configuration, which gives the delegated administrator rights to
all the cluster members.
When a delegated administrator of an Identity Server cluster is granted View/Modify rights, the
administrator has sufficient rights to change the cluster configuration and to stop, start, and update
the Identity Servers in the cluster. The administrator is granted view rights to the keystores for each
Identity Server in the cluster. To change any of the certificates, the administrator needs to be the
admin user rather than a delegated administrator.
The delegated administrator of an Identity Server cluster is not granted any rights to the policy
containers. If you want the delegated administrator with View/Modify rights to the cluster to have
policy rights, grant the following rights:
To have sufficient rights to create Role policies, grant View/Modify rights to a policy container.
To have sufficient rights to enable Role policies, grant View Only rights to the policy
containers with Role policies.
Administration Console21
SSL VPN Administrators
If the SSL VPN has an Embedded Service Provider and you grant the delegated administrator View/
Modify rights to the SSL VPN or its cluster, the delegated administrator is automatically granted
View Only rights to the Identity Server cluster configuration. This allows the delegated
administrator to modify which Identity Server the SSL VPN or cluster uses for authentication. It
does not allow them to update the Identity Server configuration, which is required for this type of
modification. To update the Identity Server, the delegated administrator needs View/Modify rights
to the Identity Server configuration.
If the SSL VPN is a protected resource of an Access Gateway and you want the delegated
administrator to have rights to the Access Gateway and the SSL VPN policy, you need to also grant
the user View/Modify rights to the Access Gateway and the SSL VPN policy container.
When a delegated administrator of an SSL VPN is granted View/Modify rights, the administrator
has sufficient rights to change the configuration, to stop and start the service, and to update the
server’s configuration.
To set up the secure tunnel certificate, the SSL VPN administrator also needs to be a certificate
administrator with View/Modify rights.
novdocx (en) 19 February 2010
J2EE Agent Administrators
You can assign a user to be a delegated administrator of a J2EE Agent cluster or a single J2EE Agent
that does not belong to a cluster. When a user is assigned View/Modify rights to manage an agent,
the user is automatically assigned View Only rights to the policy containers. If you want the
delegated administrator to create or modify J2EE Agent Authorization policies, you need to grant
the delegated administrator View/Modify rights to a policy container.
View/Modify rights to an agent also grants View Only rights to the Identity Server cluster
configuration. This allows the delegated administrator to modify which Identity Server the agent
uses for authentication. It does not allow them to update the Identity Server configuration, which is
required for this configuration change. To update the Identity Server, the delegated administrator
needs View/Modify rights to the Identity Server configuration.
View/Modify rights allows the administrator rights to change the configuration, to stop and start the
agent, and to update the agent’s configuration.
To configure certificates for the agent, the J2EE agent administrator also needs to be a certificate
administrator with View/Modify rights.
Activating eDirectory Auditing for LDAP Events
If you are concerned that your delegated administrators might use an LDAP browser to access the
configuration datastore, you can configure eDirectory to audit events that come from LDAP
connections to the LDAP server.
1 In the Administration Console, click Auditing > Auditing.
2 Make sure you have configured the IP address and port to use for your Secure Logging Server.
The server can be a Novell Audit server or a Sentinel server. For more information about this
process, see Section 1.7, “Enabling Auditing,” on page 23.
WARNING: Whenever you change the port or address of the Secure Logging Server, all
Access Gateways must be updated, then every Access Manager device (Identity Server,
Administration Console, Access Gateways, SSL VPN servers, and J2EE Agents) must be
rebooted (not just the module stopped and started) before the configuration change takes affect.
3 From the iManager view bar, select the Roles and Tasks view.
4 Click Directory Administration > Modify Object.
5 Click the Object Selector icon, expand the novell container, then select the eDirectory server.
The eDirectory server uses the tree name, without the _TREE suffix, for its name. The tree
name is displayed in the iManager view bar.
6 Click OK > Novell Audit > eDirectory.
7 From the Meta, Objects, and Attributes sections, select the events that you want to monitor for
potential security problems.
In the Meta section, you would probably want to monitor changes made to groups and
ACLs.
In the Objects section, you would probably want to monitor who is logging in and out and
if objects are being created or deleted.
In the Attributes section, you would probably want to monitor when attribute values are
added or deleted.
novdocx (en) 19 February 2010
8 Click Apply.
9 (Linux) Restart eDirectory and the Audit Server. Enter the following commands:
/etc/init.d/ndsd restart
/etc/init.d/novell-naudit restart
10 (Windows) Restart eDirectory and the Audit Server:
10a Click Control Panel > Administrative Tools > Services.
10b Right click NDS Server, then select Stop.
10c Answer Yes to the prompt to stop the Novell Audit Log Server.
10d Right click NDS Server, then select Start.
10e Right click Novell Audit Log Server, then select Start.
1.7 Enabling Auditing
Access Manager includes a licensed version of Novell® Audit to provide compliance assurance
logging and to maintain audit log entries that can be subsequently included in reports. In addition to
selectable events, device generated alerts are automatically sent to the audit server.
Audit logs record events that have occurred in the identity and access management system and are
primarily intended for auditing and compliance purposes. The types of events that are logged
include the following:
Starting, stopping, and configuring a component
Success or failure of user authentication
Role assignment
Allowed or denied access to a protected resource
Administration Console23
Error events
Denial of service attacks
Security violations and other events necessary for verifying the correct and expected operation
of the identity and access management system.
Audit logging does not track the operational processing of the Access Manager components; that is,
the processing and interactions between the Access Manager components required to fulfill a user
request. (For this type of logging, see “Configuring Component Logging” in the Novell Access
Manager 3.1 SP1 Identity Server Guide.) Audit logs record the results of user and administrator
requests and other system events. Although the primary purpose for audit logging is for auditing and
compliance, the types of events logged can also be useful for detecting abnormal and error
conditions and can be used as a first alert mechanism for system support. You can configure the
audit log entries to generate alerts by leveraging the Novell Audit Notification feature. You can
select to generate e-mail, syslog, and SNMP notifications.
Access Manager has been assigned the Novell Audit server-alert event code 0x002E0605. The
Novell Audit Platform Agent is responsible for packaging and forwarding the audit log entries to the
configured Novell Audit server. If the Novell Audit server is not available, the Platform Agent
caches log entries until the server is operational and can accept audit log data. The Platform Agent
can be configured to forward events to Sentinel rather than Novell Audit. For information on how to
do this, see “Specifying the Logging Server and the Console Events” on page 25.
novdocx (en) 19 February 2010
Section 1.7.1, “Configuring Access Manager for Novell Auditing,” on page 24
Section 1.7.2, “Querying Data and Generating Reports in Novell Audit,” on page 27
1.7.1 Configuring Access Manager for Novell Auditing
By default, Access Manager is preconfigured to use the Novell Audit server it installs on the first
instance of the Administration Console. If you install more than one instance of the Administration
Console for failover, Novell Audit is installed with each instance. However, if you already use
Novell Audit, you can continue using your existing installation with Access Manager. You need to
configure Access Manager to use your audit server. You’ll also need to register the Access Manager
with your audit servers by importing the
nids_en.lsc
Novell Access Manager allows you to specify only one Novell Audit server. You still have failover
if the audit server goes down. The auditing clients on the Novell Access Manager components go
into caching mode when the audit server is not available. They save all events until the entries can
be sent to the audit server.
This section includes the following topics:
“Specifying the Logging Server and the Console Events” on page 25
“Configuring the Platform Agent” on page 26
“Configuring the Devices for Auditing” on page 27
Specifying the Logging Server and the Console Events
The Secure Logging Server manages the flow of information to and from the Novell auditing
system. It receives incoming events and requests from the Platform Agents, logs information to the
data store, monitors designated events, and provides filtering and notification services. It can also be
configured to automatically reset critical system attributes according to a specified policy.
1 To specify the logging server, click Auditing > Novell Auditing.
2 Fill in the following fields:
Server: Specify the IP address or DNS name of the audit logging server you want to use. By
default, the system uses the primary Administration Console IP address. If you want to use a
different Secure Logging Server, specify that server here.
Access Manager does not currently support the use of custom application certificates. For
information on this Novell Audit feature, see “Authenticating Logging Applications” (http://
www.novell.com/documentation/novellaudit20/novellaudit20/data/am8ewv2.html) in the Novell Audit Administration Guide (http://www.novell.com/documentation/novellaudit20/
novellaudit20/data/bookinfo.html).
TM
To use Novell Sentinel
instead of Novell Audit, specify the IP address or DNS name of your
Collector. For more information on Sentinel, see Sentinel 6 (http://www.novell.com/
documentation/sentinel6/index.html).
Port: Specify the port that the Platform Agents use to connect to the Secure Logging Server.
To use Novell Sentinel instead of Novell Audit, specify the port of your Collector.
novdocx (en) 19 February 2010
IMPORTANT: Whenever you change the port or address of the Secure Logging Server, all
Access Gateways must be updated, then every Access Manager device (Identity Server,
Administration Console, Access Gateways, SSL VPN servers, and J2EE Agents) must be
rebooted (not just stopping and starting the module) before the configuration change takes
affect.
3 Under Management Console Audit Events, specify the system-wide events you want to audit:
Select All: Selects all of the audit events.
Health Changes: Generated whenever the health of a server changes.
Server Imports: Generated whenever a server is imported into the Administration Console.
Server Deletes: Generated whenever a server is deleted from the Administration Console.
Configuration Changes: Generated whenever you change a server configuration.
4 Click OK.
If you did not change the address or port of the Secure Logging Server, this completes the
process. It may take up to fifteen minutes for the events you selected to start appearing in the
audit files.
If you changed the address or the port of the Secure Logging Server, complete the following
steps:
5 If the Administration Console is the only Access Manager component installed on the machine,
edit the Novell Audit Configuration file.
For security reasons, this file cannot be edited from the Administration Console when it is the
only Access Manager component on the machine.
Administration Console25
novdocx (en) 19 February 2010
Edit the
logevent.conf
file and specify the new address and port of the Secure Logging
Server.
Linux: Located in the
Windows: Located in the
etc
directory
Windows
directory.
6 Restart the Administration Console. Open a terminal window, then enter the command for your
platform:
Linux:
Windows:
/etc/init.d/novell-tomcat5 restart
net stop Tomcat5
net start Tomcat5
7 Restart every device imported into the Administration Console.
The devices (Identity Server, Access Gateway, SSL VPN, J2EE Agents) do not start reporting
events until they have been restarted.
Configuring the Platform Agent
The Platform Agents installed with the Access Manager components use an embedded certificate.
Access Manager does not currently support the use of custom application certificates. For
information on this Novell Audit feature, see “Authenticating Logging Applications” (http://
www.novell.com/documentation/novellaudit20/novellaudit20/data/am8ewv2.html) in the Novell Audit Administration Guide (http://www.novell.com/documentation/novellaudit20/novellaudit20/
data/bookinfo.html).
The Platform Agents that are installed on each Access Manager component can be configured by
modifying the
logevent
file. For the location of this file and its parameters, see “Logevent” (http://
www.novell.com/documentation/novellaudit20/novellaudit20/data/al36zjk.html#alibmyw) in the Novell Audit Administration Guide (http://www.novell.com/documentation/novellaudit20/
novellaudit20/data/bookinfo.html).
IMPORTANT: Do not use this file to modify the IP address of the Secure Audit Server. Use the
Administration Console for this task (see “Specifying the Logging Server and the Console Events”
on page 25).
If you are using Sentinel, most of the parameters in this file should be set on the collector.
When the Platform Agent loses its connection to the audit server, it enters caching mode. The default
size of the audit cache file is unlimited. This means that if the connection is broken for long and
traffic is high, the cache file can become quite large. When the connection to the audit server is reestablished, the Platform Agent becomes very busy while it tries to upload the cached events to the
audit server and still process new events. When coming out of caching mode, the Platform Agent
appears unresponsive because it is so busy and because it holds application threads that are logging
new events for a long period of time. If it holds too many threads, the whole system can appear to be
hung. You can minimize the effects of this scenario by configuring the following two parameters in
logevent
the
ParameterDescription
file.
LogMaxCacheSizeSets a limit to the amount of cache the Platform Agent can consume to log
events when the audit server is unreachable. The default is unlimited.
LogCacheLimitActionSpecifies what the Platform Agent should do with incoming events when the
maximum cache size limit is reached. You can select one of the following
actions:
Delete the current cache file and start logging events in a new cache file.
Stop logging, which preserves all entries in cache and stops collecting new
events.
When you set a finite cache file size, it limits the number of events that must be uploaded to the
audit server when caching mode is terminated and keeps the Platform Agent responsive to new audit
events that are registered. If you have many users and are logging many events, you might need to
configure these parameters.
For more information about these parameters, see “Logevent” (http://www.novell.com/
documentation/novellaudit20/novellaudit20/data/al36zjk.html#alibmyw) in the Novell Audit Administration Guide (http://www.novell.com/documentation/novellaudit20/novellaudit20/data/
bookinfo.html).
novdocx (en) 19 February 2010
Configuring the Devices for Auditing
Each device defines the events that can be enabled for auditing. For information on enabling these
events, see the following:
“Enabling Access Gateway Audit Events” in the Novell Access Manager 3.1 SP1 Access
Gateway Guide
“Enabling Identity Server Audit Events” in the Novell Access Manager 3.1 SP1 Identity Server
Guide
“Enabling SSL VPN Audit Events” in the Novell Access Manager 3.1 SP1 SSL VPN Server
Guide
“Enabling Tracing and Auditing of Events” in the Novell Access Manager 3.1 SP1 Agent Guide
For a listing of all Novell Audit events logged by Access Manager, see Appendix D, “Access
Manager Audit Events and Data,” on page 121.
1.7.2 Querying Data and Generating Reports in Novell Audit
Queries let you create, run, edit, and delete queries and event verifications. You can create two kinds
of queries in Access Manager: manual queries and saved queries. Manual queries are simply queries
that are not saved; they only run one time. All verification queries are saved. Saved queries and
verifications are listed in the Queries list and can be run again and again against different databases.
Access Manager uses queries to request information from MySQL* and Oracle* databases. All
queries are defined in SQL. Although you must be familiar with the SQL language to create SQL
query statements, this is the most powerful and flexible query method.
Novell Audit provides two tools to query events and generate reports: the Novell Audit iManager
plug-in and Novell Audit Report (
LReport
).
Administration Console27
The following sections provide more information on these tools:
“The Novell Audit iManager Plug-in” on page 28
“Novell Audit Report” on page 28
The Novell Audit iManager Plug-in
The Novell Audit iManager plug-in is a Web-based JDBC* application that enables you to query
MySQL and Oracle databases. All queries are defined in SQL.
iManager includes several predefined queries and it includes a Query Builder to help you define
basic query statements. Of course, you can also build your own SQL query statements.
For complete information on defining and running queries in iManager, see the following sections in
the Novell Audit 2.0 Administration Guide (http://www.novell.com/documentation/novellaudit20/
novellaudit20/data/bookinfo.html).
“Defining Your Query Databases in iManager” (http://www.novell.com/documentation/
“Exporting Query Results in iManager” (http://www.novell.com/documentation/novellaudit20/
novellaudit20/data/alorpq2.html#alqvrze)
“Printing Query Results in iManager” (http://www.novell.com/documentation/novellaudit20/
novellaudit20/data/alorpq2.html#alqvzva)
Novell Audit Report
Novell Audit Report is a Windows-based, ODBC-compliant application that can use SQL query
statements or Crystal Decisions* Reports to query Oracle and MySQL data stores (or any other
database that has ODBC driver support). You can define your own SQL query statements or import
existing query statements and reports. Query results are returned in simple data tables; rows
represent individual records and columns represent fields within those records.
For complete information on defining and running queries in Novell Audit Report, see the following
sections in the Novell Audit 2.0 Administration Guide (http://www.novell.com/documentation/