Novell ACCESS MANAGER 3.1 SP1 - ADMINISTRATION User Manual

Administration Console Guide

Novell®

Access Manager

novdocx (en) 19 February 2010

AUTHORIZED DOCUMENTATION

3.1 SP1

March 17, 2010

www.novell.com

Novell Access Manager 3.1 SP1 Administration Console Guide

Legal Notices

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.

novdocx (en) 19 February 2010

Copyright © 2006-2010 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the express written consent of the publisher.

Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com

Online Documentation: To access the latest online documentation for this and other Novell products, see

the Novell Documentation Web page (http://www.novell.com/documentation).

Novell Trademarks

For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/

trademarks/tmlist.html).

Third-Party Materials

All third-party trademarks are the property of their respective owners.

novdocx (en) 19 February 2010

novdocx (en) 19 February 2010

4 Novell Access Manager 3.1 SP1 Administration Console Guide

Contents

About This Guide 9

1 Administration Console 11

1.1 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.1 Access Manager Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1.2 Configuration Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.3 Auditing and Event Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Administration Console Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 Configuring the Default View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Changing the Administration Console Session Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.5 Changing the Password for the Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.6 Multiple Administrators, Multiple Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6.1 Multiple Admin Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6.2 Managing Delegated Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.7 Enabling Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.7.1 Configuring Access Manager for Novell Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.7.2 Querying Data and Generating Reports in Novell Audit . . . . . . . . . . . . . . . . . . . . . . 27

novdocx (en) 19 February 2010

2 Backing Up and Restoring Components 31

2.1 How The Backup and Restore Process Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.1 Default Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.2 The Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2 Backing Up the Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3 Restoring an Administration Console Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1 Restoring the Configuration on a Standalone Administration Console or with a

Traditional SSL VPN Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3.2 Restoring the Configuration with an Identity Server on the Same Machine . . . . . . . 35

2.3.3 Restoring the Configuration with an ESP-Enabled SSL VPN Server . . . . . . . . . . . . 36

2.4 Restoring an Identity Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.5 Restoring an Access Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.5.1 Clustered Access Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.5.2 Single Access Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6 Running the Diagnostic Configuration Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 Security and Certificate Management 41

3.1 Understanding How Access Manager Uses Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.1 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.2 Access Manager Trust Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.3 Access Manager Keystores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.2 Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.1 Creating Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.2 Managing Certificates and Keystores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2.3 Managing Trusted Roots and Trust Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2.4 Security Considerations for Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.3 Assigning Certificates to Access Manager Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.3.1 Importing a Trusted Root to the LDAP User Store . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.3.2 Replacing Identity Server SSL Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Contents 5

3.3.3 Assigning Certificates to an Access Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3.4 Assigning Certificates to J2EE Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.3.5 Configuring SSL for Authentication between the Identity Server and Access

Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.3.6 Changing a Non-Secure (HTTP) Environment to a Secure (HTTPS) Environment. . 69

3.3.7 Creating Keystores and Trust Stores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.3.8 Reviewing the Command Status for Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 Access Manager Logging 73

4.1 Understanding the Types of Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.1.1 Component Logging for Troubleshooting Configuration or Network Problems . . . . . 73

4.1.2 HTTP Transaction Logging for Proxy Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2 Downloading the Log Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.3 Using the Log Files for Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Logging79

4.3.2 Understanding Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.3.3 Sample Authentication Traces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5 Changing the IP Address of Access Manager Devices 87

novdocx (en) 19 February 2010

5.1 Changing the IP Address of the Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.2 Changing the IP Address of an Identity Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.3 Changing the IP Address of the Access Gateway Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.4 Changing the IP Address of an Audit Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6 Troubleshooting the Administration Console 91

6.1 Stopping Tomcat on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.2 Checking for Potential Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.4 Event Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.5 Restoring a Failed Secondary Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.6 Moving the Primary Administration Console to New Hardware . . . . . . . . . . . . . . . . . . . . . . . . 94

6.7 Converting a Secondary Console into a Primary Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.7.1 Shutting Down the Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.7.2 Changing the Master Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.7.3 Restoring CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.7.4 Deleting Objects from the eDirectory Configuration Store . . . . . . . . . . . . . . . . . . . . . 97

6.7.5 Performing Component-Specific Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.7.6 Enabling Backup on the New Primary Administration Console . . . . . . . . . . . . . . . . 103

6.8 Orphaned Objects in the Trust/Configuration Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.9 Repairing the Configuration Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.10 Session Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.11 Unable to Log In to the Administration Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.12 (Linux) Exception Processing IdentityService_ServerPage.JSP . . . . . . . . . . . . . . . . . . . . . . 106

6.13 Backup/Restore Failure Because of Special Characters in Passwords . . . . . . . . . . . . . . . . . 106

A Certificates Terminology 109

B Troubleshooting Certificate Issues 111

B.1 Resolving Certificate Import Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B.1.1 Importing an External Certificate Key Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6 Novell Access Manager 3.1 SP1 Administration Console Guide

B.1.2 When the Full Certificate Chain Is Not Returned During an Automatic Import of the

Trusted Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

B.1.3 Using Internet Explorer to Add a Trusted Root Chain . . . . . . . . . . . . . . . . . . . . . . . 112

B.2 Mutual SSL with X.509 Produces Untrusted Chain Messages . . . . . . . . . . . . . . . . . . . . . . . 113

B.3 Certificate Command Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

B.4 Can’t Log In with Certificate Error Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

B.5 When a User Accesses a Resource, the Browser Displays Certificate Errors. . . . . . . . . . . . 114

B.6 Access Gateway Canceled Certificate Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

B.7 A Device Reports Certificate Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

C Troubleshooting XML Validation Errors 115

C.1 Modifying a Configuration That References a Removed Object . . . . . . . . . . . . . . . . . . . . . . 115

C.2 Configuration UI Writes Incorrect Information to the Local Configuration Store. . . . . . . . . . . 117

D Access Manager Audit Events and Data 121

D.1 NIDS: Sent a Federate Request (002e0001) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

D.2 NIDS: Received a Federate Request (002e0002) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

D.3 NIDS: Sent a Defederate Request (002e0003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

D.4 NIDS: Received a Defederate Request (002e0004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

D.5 NIDS: Sent a Register Name Request (002e0005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

D.6 NIDS: Received a Register Name Request (002e0006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

D.7 NIDS: Logged Out an Authentication that Was Provided to a Remote Consumer

(002e0007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

D.8 NIDS: Logged out a Local Authentication (002e0008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

D.9 NIDS: Provided an Authentication to a Remote Consumer (002e0009) . . . . . . . . . . . . . . . . 127

D.10 NIDS: User Session Was Authenticated (002e000a). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

D.11 NIDS: Failed to Provide an Authentication to a Remote Consumer (002e000b) . . . . . . . . . . 129

D.12 NIDS: User Session Authentication Failed (002e000c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

D.13 NIDS: Received an Attribute Query Request (002e000d) . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

D.14 NIDS: User Account Provisioned (002e000e) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

D.15 NIDS: Failed to Provision a User Account (002e000f). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

D.16 NIDS: Web Service Query (002e0010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

D.17 NIDS: Web Service Modify (002e0011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

D.18 NIDS: Connection to User Store Replica Lost (002e0012) . . . . . . . . . . . . . . . . . . . . . . . . . . 133

D.19 NIDS: Connection to User Store Replica Reestablished (002e0013) . . . . . . . . . . . . . . . . . . 134

D.20 NIDS: Server Started (002e0014) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

D.21 NIDS: Server Stopped (002e0015) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

D.22 NIDS: Server Refreshed (002e0016). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

D.23 NIDS: Intruder Lockout (002e0017) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

D.24 NIDS: Severe Component Log Entry (002e0018) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

D.25 NIDS: Warning Component Log Entry (002e0019) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

D.26 NIDS: Roles PEP Configured (002e0300) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

D.27 Access Gateway: PEP Configured (002e0301) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

D.28 J2EE Agent: Web Service Authorization PEP Configured (002e0305) . . . . . . . . . . . . . . . . . 138

D.29 J2EE Agent: JACC Authorization PEP Configured (002e0306). . . . . . . . . . . . . . . . . . . . . . . 139

D.30 Roles Assignment Policy Evaluation (002e0320) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

D.31 Access Gateway: Authorization Policy Evaluation (002e0321) . . . . . . . . . . . . . . . . . . . . . . . 140

D.32 Access Gateway: Form Fill Policy Evaluation (002e0322). . . . . . . . . . . . . . . . . . . . . . . . . . . 141

D.33 Access Gateway: Identity Injection Policy Evaluation (002e0323) . . . . . . . . . . . . . . . . . . . . . 141

D.34 J2EE Agent: Web Service Authorization Policy Evaluation (002e0324) . . . . . . . . . . . . . . . . 142

novdocx (en) 19 February 2010

Contents 7

D.35 J2EE Agent: Web Service SSL Required Policy Evaluation (002e0325). . . . . . . . . . . . . . . . 142

D.36 J2EE Agent: Startup (002e0401) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

D.37 J2EE Agent: Shutdown (002e0402) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

D.38 J2EE Agent: Reconfigure (002e0403) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

D.39 J2EE Agent: Authentication Successful (002e0404) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

D.40 J2EE Agent: Authentication Failed (002e0405) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

D.41 J2EE Agent: Web Resource Access Allowed (002e0406). . . . . . . . . . . . . . . . . . . . . . . . . . . 146

D.42 J2EE Agent: Clear Text Access Allowed (002e0407) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

D.43 J2EE Agent: Clear Text Access Denied (002e0408) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

D.44 J2EE Agent: Web Resource Access Denied (002e0409) . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

D.45 J2EE Agent: EJB Access Allowed (002e040a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

D.46 J2EE Agent: EJB Access Denied (002e040b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

D.47 Access Gateway: Access Denied (0x002e0505) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

D.48 Access Gateway: URL Not Found (0x002e0508) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

D.49 Access Gateway: System Started (0x002e0509). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

D.50 Access Gateway: System Shutdown (0x002e050a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

D.51 Access Gateway: Identity Injection Parameters (0x002e050c) . . . . . . . . . . . . . . . . . . . . . . . 152

D.52 Access Gateway: Identity Injection Failed (0x002e050d) . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

D.53 Access Gateway: Form Fill Authentication (0x002e050e) . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

D.54 Access Gateway: Form Fill Authentication Failed (0x002e050f) . . . . . . . . . . . . . . . . . . . . . . 154

D.55 Access Gateway: URL Accessed (0x002e0512) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

D.56 Access Gateway: IP Access Attempted (0x002e0513) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

D.57 Access Gateway: Webserver Down (0x002e0515) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

D.58 Access Gateway: All WebServers for a Service is Down (0x002e0516) . . . . . . . . . . . . . . . . 157

D.59 Management Communication Channel: Health Change (0x002e0601). . . . . . . . . . . . . . . . . 158

D.60 Management Communication Channel: Device Imported (0x002e0602). . . . . . . . . . . . . . . . 158

D.61 Management Communication Channel: Device Deleted (0x002e0603) . . . . . . . . . . . . . . . . 159

D.62 Management Communication Channel: Device Configuration Changed (0x002e0604) . . . . 160

D.63 Management Communication Channel: Device Alert (0x002e0605) . . . . . . . . . . . . . . . . . . . 160

novdocx (en) 19 February 2010

8 Novell Access Manager 3.1 SP1 Administration Console Guide

About This Guide

This guide describes the following features of Novell® Access Manager Administration Console:

 Chapter 1, “Administration Console,” on page 11

 Chapter 2, “Backing Up and Restoring Components,” on page 31

 Chapter 3, “Security and Certificate Management,” on page 41

 Chapter 4, “Access Manager Logging,” on page 73

 Chapter 5, “Changing the IP Address of Access Manager Devices,” on page 87

 Chapter 6, “Troubleshooting the Administration Console,” on page 91

 Appendix A, “Certificates Terminology,” on page 109

 Appendix B, “Troubleshooting Certificate Issues,” on page 111

 Appendix C, “Troubleshooting XML Validation Errors,” on page 115

 Appendix D, “Access Manager Audit Events and Data,” on page 121

novdocx (en) 19 February 2010

It is recommended that you first become familiar with the information in the Novell Access Manager

3.1 SP1 Setup Guide, which helps you understand how to perform a basic Identity Server

configuration, set up a resource protected by an Access Gateway, and configure SSL.

Audience

This guide is intended for Access Manager administrators. It is assumed that you have knowledge of
evolving Internet protocols, such as:

 Extensible Markup Language (XML)

 Simple Object Access Protocol (SOAP)

 Security Assertion Markup Language (SAML)

 Public Key Infrastructure (PKI) digital signature concepts and Internet security

 Secure Socket Layer/Transport Layer Security (SSL/TSL)

 Hypertext Transfer Protocol (HTTP and HTTPS)

 Uniform Resource Identifiers (URIs)

 Domain Name System (DNS)

 Web Services Description Language (WSDL)

Feedback

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 Guide 9

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 Access Gateway Guide

 Novell Access Manager 3.1 SP1 Policy Management Guide

 Novell Access Manager 3.1 SP1 Agent 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.

10 Novell Access Manager 3.1 SP1 Administration Console Guide

1

Administration Console

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:

test-signing
test-encryption
test-connector
test-provider
test-consumer
test-stunnel

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.

12 Novell Access Manager 3.1 SP1 Administration Console Guide

1.1.2 Configuration Store

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 Console 13

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:

14 Novell Access Manager 3.1 SP1 Administration Console Guide

Figure 1-1 Access Manager Roles and Tasks View

novdocx (en) 19 February 2010

This view has the following advantages:

 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 Console 15

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.

To change the view:

1 Locate the Header frame.

16 Novell Access Manager 3.1 SP1 Administration Console Guide

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

user.

18 Novell Access Manager 3.1 SP1 Administration Console Guide

1.6.2 Managing Delegated Administrators

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 Console 19

 “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.

20 Novell Access Manager 3.1 SP1 Administration Console Guide

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 Console 21

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.

22 Novell Access Manager 3.1 SP1 Administration Console Guide

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 Console 23

 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

and

sslvpn_en.lsc

files.

24 Novell Access Manager 3.1 SP1 Administration Console Guide

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 Console 25

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 re­established, 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

Parameter Description

file.

LogMaxCacheSize Sets 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.

26 Novell Access Manager 3.1 SP1 Administration Console Guide

Parameter Description

LogCacheLimitAction Specifies 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 Console 27

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/

novellaudit20/novellaudit20/data/alorpq2.html#alost1z)

 “Defining Queries in iManager” (http://www.novell.com/documentation/novellaudit20/

novellaudit20/data/alorpq2.html#alpvc0a)

novdocx (en) 19 February 2010

 “Running Queries in iManager” (http://www.novell.com/documentation/novellaudit20/

novellaudit20/data/alorpq2.html#alpv7ft)

 “Verifying Event Authenticity in iManager” (http://www.novell.com/documentation/

novellaudit20/novellaudit20/data/alorpq2.html#b34tzvi)

 “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/

novellaudit20/novellaudit20/data/bookinfo.html).

 “Novell Audit Report Interface” (http://www.novell.com/documentation/novellaudit20/

novellaudit20/data/alorpgw.html#als9vcm)

 “Defining Your Databases in Novell Audit Report” (http://www.novell.com/documentation/

novellaudit20/novellaudit20/data/alorpgw.html#als94w4)

 “Verifying Event Authenticity in Novell Audit Report” (http://www.novell.com/

documentation/novellaudit20/novellaudit20/data/alorpgw.html#am9dbll)

28 Novell Access Manager 3.1 SP1 Administration Console Guide

 “Working with Reports in Novell Audit Report” (http://www.novell.com/documentation/

novellaudit20/novellaudit20/data/alorpgw.html#alsn2fj)

 “Working with Queries in Novell Audit Report” (http://www.novell.com/documentation/

novellaudit20/novellaudit20/data/alorpgw.html#alshpuw)

novdocx (en) 19 February 2010

Administration Console 29

novdocx (en) 19 February 2010

30 Novell Access Manager 3.1 SP1 Administration Console Guide

2

Backing Up and Restoring

novdocx (en) 19 February 2010

Components

Backup and restore utilities are scripts that are run from the command line, and they allow you to
back up and restore your Administration Console. An additional script allows you to export your
configuration so Novell

IMPORTANT: You cannot restore data from a previous version of Access Manager to a new
version. It is recommended that you create a new configuration backup whenever you upgrade to a
newer version of Access Manager.

The following sections describe how to back up and restore your Access Manager components and
how to export your configuration for Novell Support:

 Section 2.1, “How The Backup and Restore Process Works,” on page 31

 Section 2.2, “Backing Up the Administration Console,” on page 32

 Section 2.3, “Restoring an Administration Console Configuration,” on page 33

 Section 2.4, “Restoring an Identity Server,” on page 37

 Section 2.5, “Restoring an Access Gateway,” on page 37

 Section 2.6, “Running the Diagnostic Configuration Export,” on page 39

®

Support can help diagnose possible configuration problems.

2

2.1 How The Backup and Restore Process Works

 Section 2.1.1, “Default Parameters,” on page 31

 Section 2.1.2, “The Process,” on page 31

2.1.1 Default Parameters

On Linux, all of the scripts call the

defbkparm.sh

The
parameters for several of options required by the underlying backup and restore utilities. If the
entries in this file are commented out, the user is prompted for the additional parameters.

On Windows, the default parameters are specified in the
the default parameters for several of options required by the underlying backup and restore utilities.
If the entries in this file are commented out, the user is prompted for the additional parameters.

script is created by the Access Manager installation. It contains the default

2.1.2 The Process

The backup script must be run on the primary Administration Console. It creates a ZIP file that
contains all the certificates that the various devices are using and an encrypted LDIF file that
contains the configuration parameters for all imported devices. This means that you do not need to
back up the configuration of individual devices. By backing up the primary Administration Console,
you back up the configuration of all Access Manager devices.

getparams.sh

script to request the parameters from the user.

defbkparm.properties

file. It contains

Backing Up and Restoring Components

31

The backup script backs up the objects in the ou=accessManagerContainer.o=novell container. It
does not back up the following:

 Admin user account and password

 Delegated administrator accounts, their passwords, or rights

 Role Based Services (RBS) configuration

novdocx (en) 19 February 2010

 Modified configuration files on the devices such as the

 Local files installed on devices such as touch files or log files

 Custom login pages, custom error pages, or custom messages

web.xml

file

You need to perform you own back up of custom or modified configuration files. For information on
how to perform a configuration backup, see Section 2.2, “Backing Up the Administration Console,”

on page 32.

The only time you need to restore the backup is when the Administration Console fails. If another
device fails, you simply replace the hardware, reinstall the device using the same IP address as the
failed device, and the device imports into the Administration Console and acquires the configuration
of the failed device. For the details of this process, see Section 2.4, “Restoring an Identity Server,”

on page 37.

It is only when the Administration Console fails that you need to restore the files you backed up. In
this case, you replace the hardware and reinstall the Administration Console using the same DNS
name and IP address as the failed console. You then use the restore utility to restore the certificates
and the device configuration. The Administration Console notifies all the devices that it is online,
and they resume communicating with it rather than a secondary console. For details of this process,
see Section 2.3.1, “Restoring the Configuration on a Standalone Administration Console or with a

Traditional SSL VPN Server,” on page 34.

If the Identity Server was installed with the Administration Console, you need to be aware that the
backup file only contains the Tomcat configuration information for the Administration Console.
After you have restored the Administration Console, you then need to install the Identity Server
software and it will acquire its configuration parameters from the Administration Console. For
details of this process, see Section 2.3.2, “Restoring the Configuration with an Identity Server on the

Same Machine,” on page 35.

2.2 Backing Up the Administration Console

1 On the primary Administration Console, change to the utility directory.

Linux:

Windows:

2 Run the following command:

Linux: .

Windows:

3 Enter the Access Manager administration password.

4 Re-enter the password for verification.

5 Specify a path for where you want the backup files stored. Press Enter to use the default

location.

6 (Windows) Specify the name for the ZIP file.

32 Novell Access Manager 3.1 SP1 Administration Console Guide

/opt/novell/devman/bin

\Program Files\Novell\bin

/ambkup.sh

ambkup.bat

7 Enter a password for encrypting and decrypting private keys, then re-enter for verification.

You must use the same password for both backup and restore.

8 Press Enter.

The backup script creates a ZIP file containing several files, including the certificate information.
This file contains the following:

 The configurations store’s CA key.

 The certificates contained in the configuration store.

 The trusted roots in the trustedRoots container of the accessManagerContainer object.

 An encrypted LDIF file, containing everything found in the

OU=accessManagerContainer,O=novell container.

 A

server.xml

Console.

The trusted roots are backed up in both the LDIF file and the ZIP file. They are added to the ZIP file
so that the ZIP file has the complete certificate-related configuration.

file containing the Tomcat configuration information for the Administration

novdocx (en) 19 February 2010

IMPORTANT: The backup utility prompts you for a location to store the backup file, so that it is
not erased if you uninstall the product. The default location is the logged-in user’s home directory.

2.3 Restoring an Administration Console
Configuration

The restore script replaces the configuration records in the configuration database with the records
in the backup of the configuration store. It should be used to restore configuration data for one of the
following scenarios:

 An upgrade failed and you need to return to the configuration before the upgrade.

 You want to return to the backed up configuration because the current modified configuration

does not meet your needs.

The restoration steps are dependent upon whether the Administration Console is installed on its own
machine or with other Access Manager components:

 Section 2.3.1, “Restoring the Configuration on a Standalone Administration Console or with a

Traditional SSL VPN Server,” on page 34

 Section 2.3.2, “Restoring the Configuration with an Identity Server on the Same Machine,” on

page 35

 Section 2.3.3, “Restoring the Configuration with an ESP-Enabled SSL VPN Server,” on

page 36

If the primary Administration Console machine has failed, you have lost both the configuration and
the configuration database. For this scenario, see Section 6.6, “Moving the Primary Administration

Console to New Hardware,” on page 94.

The restore script cannot be used to move the Administration Console to a different platform, even if
the new machine is configured to use the same IP address and DNS name. The backup files contains
path information which is specific to the operating system. To move the Administration Console
from Linux to Windows or Windows to Linux, you need to install a Secondary Administration

Backing Up and Restoring Components 33

Console on the desired platform, then promote it to being the primary Administration Console. For
instructions on this process, see Section 6.7, “Converting a Secondary Console into a Primary

Console,” on page 95.

2.3.1 Restoring the Configuration on a Standalone
Administration Console or with a Traditional SSL VPN Server

novdocx (en) 19 February 2010

1 Ensure that the

2 (Conditional) If you have modified the Tomcat password in the

.zip

file created during the backup process is accessible.

server.xml

file on a Linux

Administration Console, back up this file. This file is located in the following directory:

/etc/opt/novell/tomcat5

The feature to modify this password was removed in Access Manager 3.0 SP3.

3 Change to the utility directory.

Linux:

Windows:

/opt/novell/devman/bin

C:\Program Files\Novell\bin

4 Run the following command:

Linux: .

Windows:

/amrestore.sh

amrestore.bat

5 Enter and re-enter the Access Manager administration password.

6 (Windows) Enter the path to where the backup file is stored.

7 Enter the name of the backup file. Do not include the

.zip

extension.

8 Enter the private key encryption password, then press Enter.

9 Re-enter the private key encryption password, then press Enter.

10 (Conditional) If you modified the Tomcat password on the Linux machine:

10a Restore the backup you made of the

server.xml

file to the Tomcat directory.

/etc/opt/novell/tomcat5

10b Restart Tomcat with the following command:

/etc/init.d/novell-tomcat5 restart

11 (Windows) Reboot the machine.

12 (Conditional) If you have a secondary Administration Console installed, reboot the machines.

13 (Conditional) If any devices report certificate errors, you need to re-push the certificates.

13a Click Auditing > Troubleshooting > Certificates.

13b Select the store that is reporting errors, then click Re-push certificates.

You can select multiple stores at the same time.

13c (Optional) To verify that the re-push of the certificates was successful, click Security >

Command Status.

If you are restoring only the Administration Console, other components should still function
properly after the restore.

34 Novell Access Manager 3.1 SP1 Administration Console Guide

2.3.2 Restoring the Configuration with an Identity Server on the
Same Machine

Select the type of machine the Administration Console is installed on:

 “Linux” on page 35

 “Windows” on page 36

Linux

novdocx (en) 19 February 2010

Whenever you run the

amrestore.sh

script, the Administration Console is restored as a standalone
Administration Console. You must perform the steps described in Step 9 to restore your Identity
Server into the configuration.

.zip

1 Ensure that the

2 Change to the

3 Run the following command from

file created during the backup process is accessible.

/opt/novell/devman/bin

root: ./amrestore.sh

directory.

.

4 Enter the Access Manager administration user ID.

5 Enter the Access Manager administration password.

6 Enter the name of the backup file. Do not include the

.zip

extension.

7 Enter the private key encryption password, then press Enter.

8 Re-enter the private key encryption password, then press Enter.

9 For the Identity Server, complete the following steps after the restore has finished:

9a Remove the Identity Server from the cluster configuration. (See “Removing a Server from

a Cluster Configuration” in the Novell Access Manager 3.1 SP1 Identity Server Guide.)

9b Delete the Identity Server from the Administration Console. (See “Managing an Identity

Server” in the Novell Access Manager 3.1 SP1 Identity Server Guide.)

9c Uninstall the Identity Server. (See “Uninstalling the Identity Server” in the Novell Access

Manager 3.1 SP1 Installation Guide.)

This is required if the Identity Server is installed on the machine. If you installed the
Identity Server before running the

amrestore.sh

script, you need to uninstall the Identity

Server.

9d Install the Identity Server. (See “Installing the Novell Identity Server” in the Novell Access

Manager 3.1 SP1 Installation Guide.

9e If you have customized login pages, error pages, messages, or configuration files, copy

these files to the Identity Server.

9f Reassign the Identity Server to the cluster configuration that it was removed from. (See

“Assigning an Identity Server to a Cluster Configuration” in the Novell Access Manager

3.1 SP1 Identity Server Guide.)

10 (Conditional) If any devices report certificate errors, you need to re-push the certificates.

10a Click Auditing > Troubleshooting > Certificates.

10b Select the store that is reporting errors, then click Re-push certificates.

Backing Up and Restoring Components 35

You can select multiple stores at the same time.

10c (Optional) To verify that the re-push of the certificates was successful, click Security >

Command Status.

Windows

To perform a restore when a Windows Administration Console and an Identity Server are installed
on the same machine:

1 Run the Access Manager Restore utility.

1a From a command line, change to the

1b Specify

amrestore.bat

.

C:\Program Files\Novell\bin

directory.

1c Answer the prompts.

2 Remove the Identity Server from the cluster configuration. (See “Removing a Server from a

Cluster Configuration” in the Novell Access Manager 3.1 SP1 Identity Server Guide.)

3 Delete the Identity Server from the Administration Console. (See “Managing an Identity

Server” in the Novell Access Manager 3.1 SP1 Identity Server Guide.)

4 Install the Identity Server on the Administration Console. (See “Installing the Novell Identity

Server” in the Novell Access Manager 3.1 SP1 Installation Guide.

5 If you have customized login pages, error pages, messages, or configuration files, copy these

files to the Identity Server.

novdocx (en) 19 February 2010

6 Reassign the Identity Server to the cluster configuration that it was removed from. (See

“Assigning an Identity Server to a Cluster Configuration” in the Novell Access Manager 3.1

SP1 Identity Server Guide.)

2.3.3 Restoring the Configuration with an ESP-Enabled SSL
VPN Server

Whenever you run the
Administration Console. You must perform the steps described in Step 9 to restore your ESP­enabled SSL VPN server into the configuration.

1 Ensure that the

2 Change to the

3 Run the following command from

4 Enter the Access Manager administration user ID.

5 Enter the Access Manager administration password.

6 Enter the name of the backup file. Do not include the

7 Enter the private key encryption password, then press Enter.

8 Re-enter the private key encryption password, then press Enter.

9 For the SSL VPN Server, complete the following steps after the restore has finished:

amrestore.sh

.zip

file created during the backup process is accessible.

/opt/novell/devman/bin

script, the Administration Console is restored as a standalone

directory.

root: ./amrestore.sh

.zip

.

extension.

9a Remove the SSL VPN Server from the cluster configuration.

9b Delete the SSL VPN Server from the Administration Console.

9c Uninstall the SSL VPN server.

36 Novell Access Manager 3.1 SP1 Administration Console Guide

9d Install the SSL VPN server.

9e Reassign the SSL VPN server to the cluster configuration that it was removed from.

10 (Conditional) If any devices report certificate errors, you need to re-push the certificates.

10a Click Auditing > Troubleshooting > Certificates.

10b Select the store that is reporting errors, then click Re-push certificates.

You can select multiple stores at the same time.

10c (Optional) To verify that the re-push of the certificates was successful, click Security >

Command Status.

2.4 Restoring an Identity Server

1 Remove the Identity Server from the Identity Server cluster configuration. (See “Removing a

Server from a Cluster Configuration” in the Novell Access Manager 3.1 SP1 Identity Server
Guide.)

2 Delete the Identity Server from the Administration Console. (See “Managing an Identity

Server” in the Novell Access Manager 3.1 SP1 Identity Server Guide.)

novdocx (en) 19 February 2010

3 Uninstall the Identity Server. (See “Uninstalling the Identity Server” in the Novell Access

Manager 3.1 SP1 Installation Guide.

This might not be necessary, if you used a new machine for the restoring the configuration.

4 Install the new Identity Server, which imports it into the Administration Console. (See

“Installing the Novell Identity Server” in the Novell Access Manager 3.1 SP1 Installation

Guide.

5 If you have customized login pages, error pages, messages, or configuration files, copy these

files to the Identity Server.

6 Assign the new server to the Identity Server cluster configuration. (See “Assigning an Identity

Server to a Cluster Configuration” in the Novell Access Manager 3.1 SP1 Identity Server

Guide.)

2.5 Restoring an Access Gateway

If an Access Gateway machine experiences a hardware failure, such as a failed hard disk, you can
preserve its configuration and have it applied to the replacement machine.

 Section 2.5.1, “Clustered Access Gateway,” on page 37

 Section 2.5.2, “Single Access Gateway,” on page 38

2.5.1 Clustered Access Gateway

If the hardware fails on an Access Gateway machine that belongs to a cluster:

1 In the Administration Console, view the configuration of the cluster. Click Devices > Access

Gateways.

2 (Conditional) If the failed Access Gateway is the primary server, assign another server to be the

primary server:

2a On the Access Gateways page, click [Name of Cluster] > Edit.

Backing Up and Restoring Components 37

2b For the Primary Server field, select another server to be the primary server, then click OK

> Close.

2c Click Identity Servers > Update.

3 Delete the failed Access Gateway from the cluster. Click Access Gateways, select the failed

Access Gateway, then click Actions > Remove from Cluster.

IMPORTANT: Do not delete the Access Gateway from the Administration Console.

4 On the new machine, install the Access Gateway, specifying the same Administration Console,

IP address, host name, and domain name as the failed machine.

5 (Conditional) If you have customized error messages, copy the message files to the Access

Gateway. For information on this process, see “Customizing Error Pages on the Gateway

Appliance” in the Novell Access Manager 3.1 SP1 Access Gateway Guide.

6 (Conditional) If you have configured the Access Gateway to use touch files, recreate the touch

files on the Access Gateway. For a list of touch files, see “Using Touch Files” in the Novell

Access Manager 3.1 SP1 Access Gateway Guide.

7 When the machine imports into the Administration Console, add the machine to the Access

Gateway cluster:

7a In the Administration Console, click Devices > Access Gateways.

7b Select the name of the Access Gateway, then click Actions > Assign to Cluster > [Name of

Cluster].

novdocx (en) 19 February 2010

2.5.2 Single Access Gateway

If the failed Access Gateway is a single machine and you want to preserve its configuration:

1 Do not delete the Access Gateway from the Administration Console.

If you delete the Access Gateway from the Administration Console, the configuration
information is deleted.

2 On the new machine, install the Access Gateway software, using the same IP address, host

name, and domain name as the failed device and specifying the same Administration Console.

3 (Conditional) If you have customized error messages, copy the message files to the Access

Gateway. For information on this process, see “Customizing Error Pages on the Gateway

Appliance” in the Novell Access Manager 3.1 SP1 Access Gateway Guide.

4 (Conditional) If you have configured the Access Gateway to use touch files, recreate the touch

files on the Access Gateway. For a list of touch files, see “Using Touch Files” in the Novell

Access Manager 3.1 SP1 Access Gateway Guide.

5 When the installation has completed and the device has been imported in the Administration

Console, verify the following:

5a Check its trusted relationship with the Identity Server. Click Devices > Access Gateways >

Edit > Reverse Proxy / Authentication.

5b If you have configured the Access Gateway to use SSL, reconfigure the certificates for the

listener. Click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

5c Save and apply any changes.

38 Novell Access Manager 3.1 SP1 Administration Console Guide

2.6 Running the Diagnostic Configuration Export

novdocx (en) 19 February 2010

On a Linux Administration Console, you can create an .
purposes:

1 Change to the

2 Run the following command from

3 Enter the Access Manager administration user ID.

4 Enter the Access Manager password.

5 Re-enter the password for verification.

6 Press Enter.

The diagnostic configuration export utility is almost identical to the backup utility with two
differences: the ZIP file is not created, and the final LDIF file is scanned to have passwords
removed. Passwords are blanked out by a program called Strippasswd.

Strippasswd removes occurrences of passwords in the LDIF file, replacing them with empty strings.
If you look at the LDIF file, you will see that password strings are blank. You might see occurrences
within the file or text that looks similar to password=“String”. These are not instances of passwords,
but rather definitions that describe passwords as string types.

The LDIF file can then be sent to Novell Support for help in diagnosing configuration problems.

/opt/novell/devman/bin

root: ./amdiagcfg.sh

directory.

ldif

file that you can export for diagnostic

.

Backing Up and Restoring Components 39

novdocx (en) 19 February 2010

40 Novell Access Manager 3.1 SP1 Administration Console Guide

3

Security and Certificate

novdocx (en) 19 February 2010

Management

 Section 3.1, “Understanding How Access Manager Uses Certificates,” on page 41

 Section 3.2, “Managing Certificates,” on page 47

 Section 3.3, “Assigning Certificates to Access Manager Devices,” on page 64

3.1 Understanding How Access Manager Uses
Certificates

Access Manager allows you to manage centrally stored certificates used for digital signatures and
data encryption. eDirectory
for all of the Access Manager components. If you use Novell
certificates there and import them into Access Manager.

By default, all Access Manager components (Identity Server, Access Gateway, SSL VPN, and J2EE
agents) trust the local Access Manager certificate authority (CA). However, if the Identity Server is
configured to use an SSL certificate signed externally, the trust store of the Embedded Service
Provider for each component must be configured to trust this new CA.

TM

resides on the Administration Console and is the main certificate store

®

Certificate ServerTM, you can create

3

Certificate management commands issued from a secondary Administration Console can work only
if the primary console is also running properly. Other commands can work independently of the
primary console.

You can create and distribute certificates to the following components:

 Identity Server: Uses certificates and trust stores to provide secure authentication to the

Identity Server and enable encrypted content from the Identity Server portal, via HTTPS. They
also provide secure communications between trusted Identity Servers and user stores.

Liberty and SAML 2.0 protocol messages that are exchanged between identity and service
providers often need to be digitally signed. The Identity Server uses the signing certificate
included with the metadata of a trusted provider to validate signed messages from the trusted
provider. For protocol messages to be exchanged between providers through SSL, each
provider must trust the CA of the other provider. You must import the public key of the CA
used by the other provider.

The Identity Server also has a trust store for OCSP (Online Certificate Status Protocol)
certificates, which is used to check the revocation status of a certificate.

 Access Gateway: Uses server certificates and trusted roots to protect Web servers, provide

single sign-on, and enable the product’s data confidentiality features, such as encryption. They
are used for background communication with the Identity Server and policy engine and to
establish trust between the Identity Server and the Access Gateway.

 SSL VPN: Uses server certificates and trusted roots to secure access to non-HTTP

applications.

Security and Certificate Management

41

 J2EE Agent: Uses certificates and trust stores to establish trust between the J2EE Agent and

the Identity Server, and for SSL between the J2EE server and the Identity Server.

To ensure the validity of X.509 certificates, Access Manager supports both Certificate Revocation
Lists (CRLs) and Online Certificate Status Protocol (OCSP) methods of verification.

Access Manager stores the certificates that a device has been configured to use in trust stores and
keystores. This section describes the following certificate features:

 Section 3.1.1, “Process Flow,” on page 42

 Section 3.1.2, “Access Manager Trust Stores,” on page 43

 Section 3.1.3, “Access Manager Keystores,” on page 44

3.1.1 Process Flow

You can install and distribute certificates to the Access Manager product components and configure
how the components use certificates. This includes central storage, distribution, and expired
certificate renewal. Figure 3-1 illustrates the primary administrative actions for certificate
management in Access Manager:

novdocx (en) 19 February 2010

Figure 3-1 Certificate Management

Certificate

Authority

4

2

Certificate

4

Access Gateway

Identity Server

1

3

Administrator

Administration

Console

4

4

SSL VPN

Java Agents

1. Create the certificate and generate a certificate signing request (CSR). See Section 3.2.1,

“Creating Certificates,” on page 47.

2. Send the CSR to the external CA for signing.

A CA is a third-party or network authority that issues and manages security credentials and
public keys for message encryption. The CA’s certificate is held in the configuration store of
the computers that trust the CA.

42 Novell Access Manager 3.1 SP1 Administration Console Guide

3. Import the signed certificate and CA chain into the configuration store. See “Importing Public

Key Certificates (Trusted Roots)” on page 61.

4. Assign certificates to devices. See Chapter 3.3, “Assigning Certificates to Access Manager

Devices,” on page 64.

If you are unfamiliar with public key cryptography concepts, see “Public Key Cryptography Basics”

(http://www.novell.com/documentation/crt311/crtadmin/data/a2uqrry.html#a2uqrry) in the Novell
Certificate Server 3.1.1 Guide (http://www.novell.com/documentation/crt311/treetitl.html).

See Appendix A, “Certificates Terminology,” on page 109 for information about certificate
terminology.

3.1.2 Access Manager Trust Stores

A trust store contains trusted roots, which are public certificates of known, trusted certificate
authorities. Access Manager defines the trust stores listed below for the devices that it manages. The
trust stores are created when you import a device into the Administration Console. If you have not
imported a particular device type, the trust store for that device type does not exist. If you have
imported multiple devices of the same type, the Administration Console creates an instance of the
trust store for each device.

novdocx (en) 19 February 2010

When a certificate has been created by a root CA, the trust store needs to contain only the public
certificate of the CA. However, some certificates are created by an intermediate CA, which has been
issued by a root CA. When intermediate CAs are involved, all the public certificates of the CAs in
the chain need to be included in the trust store.

The Administration Console creates a trust store in the file system of the device that is assigned to
the trust store.

 Linux Device:

 Windows Device:

/opt/novell/devman/jcc/certs/<device>

C:\Program Files\novell\devman\jcc\certs/<device>

The <device> can be idp (for the Identity Server), esp (for the Embedded Service Providers,
including Access Gateways, J2EE agents, and SSL VPN servers), or sslvpn (for the SSL VPN
server).

Trust Store: This Identity Server trust store contains the trusted root certificates of all the providers
that it trusts. Liberty and SAML 2.0 protocol messages that are exchanged between identity and
service providers often need to be digitally signed. A provider uses the signing certificate included
with the metadata of a trusted provider to validate signed messages from the trusted provider. The
trusted root of the CA that created the signing certificate for the service provider needs to be in this
trust store.

To use SSL for protocol messages to be exchanged between providers, each provider must trust the
SSL certificate authority (CA) of the other provider. You must import the root certificate chain for
the other provider. Failure to do so causes numerous system errors.

This trust store is also used to store the trusted root certificates of the user stores that is has been
configured to use.

OCSP Trust Store: The Identity Server uses this trust store for OCSP (Online Certificate Status
Protocol) certificates. OCSP is a method used for checking the revocation status of a certificate. To
use this feature, you must set up an OCSP server. The Identity Server sends an OCSP request to the
OCSP server to determine if a certain certificate has been revoked. The OCSP server replies with the

Security and Certificate Management 43

revocation status. If this revocation checking protocol is used, the Identity Server does not cache or
store the information in the reply, but sends a request every time it needs to check the revocation
status of a certificate. The OCSP reply is signed by the OCSP server. To verify that it was signed by
the correct OCSP server, the OCSP server certificate needs to be added to this trust store. The OCSP
server certificate is added to the trust store.

Trust Store (SSL VPN): This trust store is used by the traditional SSL VPN server that is
configured as a protected resource of the Access Gateway. The trust store contains the trusted root
certificate of the Identity Server that the Access Gateway has been configured to trust.

novdocx (en) 19 February 2010

This trust store does not use the default location; it is located in the

directory.

certs

/etc/opt/novell/sslvpn/

ESP Trust Store (SSL VPN): This trust store is used by an SSL VPN server that is ESP-enabled. It
contains the trusted root certificate of the Identity Server that it has been configured to trust. It
usually contains one certificate. If you configure the SSL VPN server to trust one Identity Server,
then modify it so the SSL VPN server trusts a different Identity Server, the trust store might contain
more than one certificate. If you are using certificates generated by the Access Manager CA, the root
certificate of this CA is automatically added to this trust store. If the Identity Server is using a
certificate generated by an external CA, you need to add the trusted root certificate of that CA to this
trust store.

ESP Trust Store (Access Gateway): The Access Gateway EPS trust store contains the trusted root
certificate of the Identity Server that it has been configured to trust. It usually contains one
certificate. If you configure the Access Gateway to trust one Identity Server, then modify it so the
Access Gateway trusts a different Identity Server, the trust store might contain more than one
certificate. If you are using certificates generated by the Access Manager CA, the root certificate of
this CA is automatically added to this trust store. If the Identity Server is using a certificate
generated by an external CA, you need to add the trusted root certificate of that CA to this trust
store.

Proxy Trust Store: When SSL is set up between the Access Gateway and its Web servers, the
Access Gateway uses this trust store for the trusted root certificates of the Web servers.

This trust store does not use the default location; it is located in the

/opt/novell/conf/keys

directory.

ESP Trust Store (J2EE Agent): The agent ESP trust store contains the trusted root certificate of
the Identity Server that it has been configured to trust. It usually contains one certificate. If you
configure the agent to trust one Identity Server, then modify it so the agent trusts a different Identity
Server, the trust store might contain more than one certificate. If you are using certificates generated
by the Access Manager CA, the root certificate of this CA is automatically added to this trust store.
If the Identity Server is using a certificate generated by an external CA, you need to add the trusted
root certificate of that CA to this trust store.

3.1.3 Access Manager Keystores

A keystore is a store, such as a file, containing keys and certificates. Access Manager components
and agents can access the keystore to retrieve certificates and keys as needed. Keystores for Access
Manager are already defined for the components.

44 Novell Access Manager 3.1 SP1 Administration Console Guide

The Administration Console creates a keystore in the file system of the device that is assigned to the
keystore.

novdocx (en) 19 February 2010

 Linux Device:

 Windows Device:

/opt/novell/devman/jcc/certs/<device>

C:\Program Files\novell\devman\jcc\certs/<device>

The <device> can be idp (for the Identity Server), esp (for the Embedded Service Providers,
including Access Gateways, J2EE agents, and SSL VPN servers), or sslvpn (for the SSL VPN
server).

Access Manager creates keystores for the following devices:

 “Identity Server Keystores” on page 45

 “Access Gateway Keystores” on page 45

 “J2EE Agent Keystores” on page 46

 “SSL VPN Keystores” on page 46

 “Keystores When Multiple Devices Are Installed on the Administration Console” on page 47

Identity Server Keystores

Access Manager creates the following keystores for each Identity Server cluster configuration:

Signing: This keystore contains the certificate that is used for signing the assertion or specific parts
of the assertion.

Encryption: This keystore contains the certificate that is used to encrypt specific fields or data in
assertions.

SSL Connector: This keystore contains the certificate that the Identity Server uses for SSL
connections. If multiple devices are installed on the same machine, the Identity Server uses the
COMMON_TOMCAT_CLUSTER keystore.

Provider Introductions SSL Connector: This keystore contains the certificate that you configure
when you set up the Identity Server to provide introductions to service providers that are trusted
members of a service domain. The subject name of this certificate needs to match the DNS name of
the service domain.

Consumer Introductions SSL Connector: This keystore contains the certificate that you configure
when you set up the Identity Server to consume authentications provided by other identity providers
that are trusted members of a service domain. The subject name of this certificate needs to match the
DNS name of the service domain.

Access Gateway Keystores

Access Manager creates the following keystores for each Access Gateway or cluster:

Signing: This keystore contains the certificate that is used for signing the assertion or specific parts
of the assertion.

Encryption: This keystore contains the certificate that is used to encrypt specific fields or data in
assertions.

Security and Certificate Management 45

ESP Mutual SSL: This keystore contains the certificate that is used for SSL when you have
established SSL communication between the Access Gateway and the Identity Server. The public
key (trusted root) of the certificate authority that created the certificate needs to be in the Identity
Server’s trust store.

Proxy Key Store: This keystore contains the certificate that is used for SSL when you have enabled
SSL between a reverse proxy and the browsers. The public key (trusted root) of the certificate
authority that created the certificate needs to be in browser’s trust store for the SSL connection to
work without warnings. If you create multiple reverse proxies and enable them for SSL, each
reverse proxy needs a certificate, and the subject name of the certificate needs to match the DNS
name of the reverse proxy.

novdocx (en) 19 February 2010

This keystore does not use the default location; it is located in the

/opt/novell/conf/keys

directory.

J2EE Agent Keystores

Access Manager creates the following keystores for each J2EE Agent:

Signing: This keystore contains the certificate that is used for signing the assertion or specific parts
of the assertion.

Encryption: This keystore contains the certificate that is used to encrypt specific fields or data in
assertions.

ESP Mutual SSL: This keystore contains the certificate that is used for SSL, when you have
established SSL communication between the J2EE agent and the Identity Server. The public key
(trusted root) of the certificate authority that created the certificate needs to be in the Identity
Server’s trust store.

SSL VPN Keystores

Access Manager creates the following keystores for each SSL VPN server or cluster:

Signing: This keystore contains the certificate that is used for signing the assertion or specific parts
of the assertion.

Encryption: This keystore contains the certificate that is used to encrypt specific fields or data in
assertions.

ESP Mutual SSL: This keystore contains the certificate that is used for SSL when you have
established SSL communication between the ESP-enabled SSL VPN server and the Identity Server.
The public key (trusted root) of the certificate authority that created the certificate needs to be in the
Identity Server’s trust store.

SSLVPN Secure Tunnel: This keystore contains the certificate that encrypts the data exchanged
between SSL VPN client and the SSL VPN server, after the SSL VPN connection is made.

This keystore does not use the default location; it is located in the

directory.

certs

SSL Connector: This keystore contains the certificate that encrypts authentication information
between the SSL VPN client browser and the SSL VPN server.

46 Novell Access Manager 3.1 SP1 Administration Console Guide

/etc/opt/novell/sslvpn/

Keystores When Multiple Devices Are Installed on the Administration Console

Access Manager creates the following keystore when the Identity Server and the SSL VPN server
are installed on the Administration Console.

COMMON_TOMCAT_CLUSTER: This keystore contains the certificate that is used for SSL
connections.

The location of this keystore depends upon which device was installed last: the Identity Server or the

idp

SSL VPN server. If the Identity Server was installed last, it is in the
server was installed last, it is in the

sslvpn

directory.

directory. If the SSL VPN

3.2 Managing Certificates

Access Manager comes with certificates for testing purposes. The test certificates are called test­signing, test-encryption, test-provider, test-consumer, and test-connector. At a minimum you must
create two SSL certificates: one for Identity Server test-connector and one for the Access Gateway
reverse proxy. Then you replace the predefined certificates with the new ones.

novdocx (en) 19 February 2010

If you install a secondary Administration Console, the certificate authority (CA) is installed with the

TM

first instance of eDirectory

, and the secondary consoles have eDirectory replicas, and therefore no
CA software. All certificate management must be done from the primary Administration Console.
Certificate management commands issued from a secondary Administration Console can work only
if the primary console is also running properly. Other commands can work independently of the
primary console.

IMPORTANT: Before generating any certificates with the Administration Console CA, make sure
time is synchronized within one minute among all of your Access Manager devices. If the time of
the Administration Console has a time that is before the device for which you are creating the
certificate, the device rejects the certificate.

The following sections contain detailed information about creating and managing certificates for
Access Manager:

 Section 3.2.1, “Creating Certificates,” on page 47

 Section 3.2.2, “Managing Certificates and Keystores,” on page 56

 Section 3.2.3, “Managing Trusted Roots and Trust Stores,” on page 61

 Section 3.2.4, “Security Considerations for Certificates,” on page 64

3.2.1 Creating Certificates

This task involves creating a certificate to be signed locally, or creating one that generates the CSR
to be signed externally, which you later import after signing.

 “Creating a Locally Signed Certificate” on page 48

 “Generating a Certificate Signing Request” on page 54

 “Importing a Signed Certificate” on page 55

Security and Certificate Management 47

Creating a Locally Signed Certificate

By default, the Access Manager installation process creates the local CA for you. eDirectory
contains a CA that can issue and sign certificates, and a certificate server that generates or imports
certificates and keys, and generate CSRs

1 In the Administration Console, click Security > Certificates.

novdocx (en) 19 February 2010

2 Click New.

48 Novell Access Manager 3.1 SP1 Administration Console Guide

novdocx (en) 19 February 2010

3 Select the following option:

Use local certificate authority: Creates a certificate signed by the local CA (or Organizational
CA), and creates the private key. For information about creating a CSR, see “Generating a

Certificate Signing Request” on page 54.

4 Provide a certificate name:

Certificate name: The name of the certificate. Pick a unique, system-wide name for the
certificate that you can easily associate with the certificate’s purpose. The name must contain
only alphanumeric characters and no spaces.

5 For Subject, click the Edit button to display a dialog box that lets you add the appropriate

attributes for the subject name.

Security and Certificate Management 49

The subject is an X.500 formatted distinguished name that identifies the entity that is bound to
the public key in an X.509 certificate. Choose the subject name that the browser expects to find
in the certificate. The name you enter must be fully distinguished. Completing all the fields
creates a fully distinguished name that includes the appropriate types (such as C for country, ST
for state, L for location, O for organization, OU for organizational unit, and CN for common
name). For example, cn=AcmeWebServer.ou=Sales.o=Acme.c=US.

The following attributes are the most common ones used in certificate subjects:

Common name: The name or IP of the server.

Enter the value, for example AcmeWebServer. Do not include the type (cn=). The UI adds that
for you.

For the Identity Server, this is the domain name of the base URL of the Identity Server
configuration. This value cannot be an IP address or begin with a number, in order to ensure
that trust does not fail between providers.

Organizational unit: Describes departments or divisions.

Organization: Differentiates between organizational divisions.

City or town: Commonly referred to as the Locality.

State or province: Commonly referred to as the State.

Country: The country, such as US.

novdocx (en) 19 February 2010

Use the Additional Attributes drop-down menus to add additional attributes. For more
information about these attributes, see “Additional Attributes” on page 52.

6 Click OK, then fill in the following fields:

Signature algorithm: The algorithm you want to use (SHA-1, MD-2, or MD-5). SHA-1 is
currently recommended.

Valid from: The date from which the certificate is valid. For externally signed certificates, the
external certificate authority sets the validity period.

Months valid: The number of months that the certificate is valid.

Key size: The size of the key. Select 512, 1024, 2048, or 4096.

7 (Optional) To configure advanced options, click Advanced Options.

8 Configure the following options as necessary for your organization:

Critical: Specifies that an application should reject the certificate if the application does not
understand the key usage extensions.

50 Novell Access Manager 3.1 SP1 Administration Console Guide

Encrypt other keys: Specifies that the certificate is used to encrypt keys.

Encrypt data directly: Encrypts data for private transmission to the key pair owner. Only the

intended receiver can read the data.

Create digital signatures: Specifies that the certificate is used to create digital signatures.

Non-repudiation: Links a digital signature to the signer and the data. This prevents others

from duplicating the signature because no one else has the signer’s private key. Additionally,
the signer cannot deny having signed the data.

9 If you are creating a key for a certificate authority, configure the following options:

This key is for a Certificate Authority: Specifies that this certificate is for the local
configuration (eDirectory) certificate authority.

If you create a new CA, all the keys signed by the CA being replaced no longer have a trusted
CA. You might also need to reassign the new CA to all the trust stores that contained the old
CA.

Critical: Enforces the basic constraints you specify. Select one of the following:

 Unlimited: Specifies no restriction on the number of subordinate certificates that the CA

can verify.

 Do not allow intermediate signing certificates in certificate chain: Prevents the CA

from creating other CAs, but it can create server or user certificates.

novdocx (en) 19 February 2010

 Number of allowable intermediate signing certificates in signing chain: Specifies

how many subordinate certificates are allowed in the certificate chain. Values must be 1 or
more. Entering 0 creates only entity objects.

10 (Optional) To create subject alternative names used by the certificate, click the Edit Subject

Alternate Names button.

Alternate names can represent the entity identified by the certificate. The certificate can
identify the subject CN=www.OU=novell.O=com, but the subject can also be known by an IP
address, such as 222.111.100.101, or a URI, such as www.novell.com, for example.

Critical: Specifies that if an application does not understand the alternate name extensions, it
should reject the certificate.

11 Click New.

Name Type: Names as specified by RFC 2459. Use the drop-down list to specify a name type,
such as:

 Directory name: An X.500 directory name. The required format for the name is

.<attribute name>=<attribute value>

.O=novell.C=US

Access Manager supports the following attributes:

. For example:

Security and Certificate Management 51

Country (C)
Organization (O)
Organizational Unit (OU)
State or Province (S or ST)
Locality (L)
Common Name (CN)

 IP Address: An IP address such as 222.123.123.123

 URI: A URI such as www.novell.com.

 Registered ID: An ASN.1 object identifier.

 DNS Name: A domain name such as novell.com.

 Email Address (RFC 822 name): An e-mail address such as [e-mail].

 X400 Name: The messaging and e-mail standard specified by the ITU-TS (International

Telecommunications Union - Telecommunication Standard Sector). It is an alternative to
the more prevalent Simple Mail Transfer Protocol (SMTP) e-mail protocol. X.400 is
common in Europe and Canada.

 EDI Party: EDI (Electronic Data Interchange) is a standard format for exchanging

business data.

 Other: A user-defined name.

Name: The display alternative name.

novdocx (en) 19 February 2010

12 Click OK.

See Also

 “Importing a Private/Public Key Pair” on page 56

 “Exporting a Private/Public Key Pair” on page 58

 “Importing Public Key Certificates (Trusted Roots)” on page 61

Additional Attributes

Use the drop-down menus to add additional attributes. These values allow you to specify additional
fields that are supported by eDirectory, and you can include them as part of the subject to further
identify the entity represented by the certificate.

CN: The Common name attribute in the list of Commonly used attributes (OID: 2.5.4.3)

C: The Country attribute in the list of Commonly used attributes (OID: 2.5.4.6)

SN: The surname attribute (OID: 2.5.4.4)

L: The locality attribute, which is the City or town attribute in the list of Commonly used attributes

(OID: 2.5.4.7)

ST: The State or province attribute in the list of Commonly used attributes (OID: 2.5.4.8)

S: The State or province attribute in the list of Commonly used attributes (OID: 2.5.4.8)

O: The Organization attribute in the list of Commonly used attributes (OID: 2.5.4.10)

OU: The Organizational unit attribute in the list of Commonly used attributes (OID: 2.5.4.11)

52 Novell Access Manager 3.1 SP1 Administration Console Guide

street: Describes the street address (OID: 2.5.4.9)

serialNumber: Specifies the serial number of a device (OID: 2.5.4.5)

title: Describes the position or function of an object (OID: 2.5.4.12)

description: Describes the associated object (OID: 2.5.4.13)

searchGuide: Specifies a search filter (OID: 2.5.4.14)

businessCategory: Describes the kind of business performed by an organization (OID: 2.5.4.15)

postalAddress: Specifies address information required for the physical delivery of postal messages

(OID: 2.5.4.16)

postalCode: Specifies the postal code of an object (OID: 2.5.4.17)

postOfficeBox: Specifies the post office box for the physical delivery of mail (OID: 2.5.4.18)

physicalDeliveryOfficeName: Specifies the name of the city or place where a physical delivery

office is located (OID: 2.5.4.19)

novdocx (en) 19 February 2010

telephoneNumber: Specifies a telephone number (OID: 2.5.4.20)

telexNumber: Specifies a telex number (OID: 2.5.4.21)

teletexTerminalIdentifier: Specifies an identifier for a telex terminal (OID: 2.5.4.22)

facsimileTelephoneNumber: Specifies the telephone number for a facsimile terminal (OID:

2.5.4.23)

x121Address: Specifies the address used in electronic data exchange (OID: 2.5.4.24)

internationalISDNNumber: Specifies an international ISDN number used in voice, video, and data

transmission (OID: 2.5.4.25)

registeredAddress: Specifies the postal address for the delivery of telegrams or expedited
documents (OID: 2.5.4.26)

destinationIndicator: Specifies an attribute used in telegram services (OID: 2.5.4.27)

preferredDeliveryMethod: Specifies the preferred delivery method for a message (OID: 2.5.4.28)

presentationAddress: Specifies an OSI presentation layer address (OID: 2.5.4.29)

supportedApplicationContext: Specifies the identifiers for the OSI application contexts in the

application layer (OID: 2.5.4.30)

member: Specifies the distinguished name of an object associated with a group or a list (OID:

2.5.4.31)

owner: Specifies the name of an object that has responsibility for another object (OID: 2.5.4.32)

roleOccupant: Specifies the distinguished name of an object that fulfills an organizational role

(OID: 2.5.4.33)

seeAlso: Specifies the distinguished name of an object that contains additional information about
the same real world object (OID: 2.5.4.34)

userPassword: Specifies the object's password (OID: 2.5.4.35)

Security and Certificate Management 53

name: Specifies a name that is in the UTF-8 form of the ISO 10646 character set (OID: 2.5.4.41)

givenName: Specifies the given or first name of an object (OID: 2.5.4.42)

initials: Specifies the initials of an object (OID: 2.5.4.43)

generationQualifier: Specifies the generation of an object, which is usually a suffix (OID:

2.5.4.44)

x500UniqueIdentifier: Specifies an identifier which distinguishes between objects when a DN has
been reused (OID: 2.5.4.45)

dnQualifier: Specifies information which makes an object unique when information is being
merged from multiple sources and objects could have the same RDNs (OID: 2.5.4.46)

enhancedSearchGuide: Specifies a search filter used by X.500 users (OID: 2.5.4.47)

protocolInformation: Specifies information which is used with the presentationAddress attribute

(OID: 2.5.4.48)

distinguishedName: Specifies the distinguished name of an object (OID: 2.5.4.49)

novdocx (en) 19 February 2010

uniqueMember: Specifies the distinguished name of an object associated with a group or a list
(OID: 2.5.4.50)

houseIdentifier: Identifies a building within a location (OID: 2.5.4.51)

dmdName: Specifies a directory management domain (OID: 2.5.4.54)

E: Specifies an email address.

EM: Specifies an e-mail address.

DC: Specifies the domain name for an object (OID: 0.9.2342.19200300.100.1.25)

uniqueID: Contains an RDN-type name that can be used to create a unique name in the tree (OID:

0.9.2342.19200300.100.1.1)

T: Specifies the name of the tree root object (OID: 2.16.840.1.113719.1.1.4.1.181)

OID: Specifies an object identifier in dot notation.

Generating a Certificate Signing Request

1 In the Administration Console, click Security > Certificates, then click New.

2 Select the following option:

Use external certificate authority: Generates a Certificate Signing Request (CSR) for you to
send to the CA for signing. A third-party CA is managed by a third party outside of the
eDirectory tree. An example of a third party CA is VeriSign*. After the signed certificate is
received, you need to import the certificate. See “Importing a Signed Certificate” on page 55.

3 Fill in the following fields:

Certificate name: The name of the certificate. Pick a unique, system-wide name for the
certificate that you can easily associate with the certificate’s purpose. The name must contain
only alphanumeric characters and no spaces.

54 Novell Access Manager 3.1 SP1 Administration Console Guide

Subject: An X.500 formatted distinguished name that identifies the entity that is bound to the
public key in an X.509 certificate. Choose the subject name that the browser expects to find in
the certificate. The name you enter must be fully distinguished. Completing all the fields
creates a fully distinguished name that includes the appropriate types (such as C for country, ST
for state, L for location, O for organization, OU for organizational unit, and CN for common
name). For example, cn=AcmeWebServer.ou=Sales.o=Acme.c=US

4 Click the Edit button to display a dialog box that lets you add appropriate locality information

types for the subject name.

The following attributes are the most common ones used in certificate subjects:

Common name: The name or IP of the Web server. Enter only the value. Do not enter the type
(cn=). The UI adds it for you.

Organizational unit: Describes departments or divisions.

Organization: Differentiates between organizational divisions.

City or town: Commonly referred to as the Locality.

State or province: Commonly referred to as the State.

Country: The country, such as US.

Use the Additional Attributes drop-down lists to add additional attributes. These values allow
you to specify additional fields that are supported by eDirectory, and you can include them as
part of the subject to further identify the entity represented by the certificate.

5 Click OK, then fill in the following fields:

Signature algorithm: The algorithm you want to use (SHA-1, MD-2, or MD-5). SHA-1 is
currently recommended.

Valid from: The date from which the certificate is valid. For externally signed certificates, the
external certificate authority sets the validity period.

novdocx (en) 19 February 2010

Months valid: The number of months that the certificate is valid.

Key size: The size of the key. Select 512, 1024, 2048, or 4096.

6 If necessary, fill in the certificate fields, which are described in “Creating a Locally Signed

Certificate” on page 48.

7 Click OK.

8 On the Certificate Details page, copy the CSR data and send the information to the external

CA.

The certificate status is CSR Pending until you import the signed certificate.

9 Click Close.

Continue with “Importing a Signed Certificate” on page 55 after you receive the signed certificate
and the trusted root (CA chain).

Importing a Signed Certificate

After you receive the signed certificate and the CA chain, you must import it. There are several ways
in which the CA can return the certificate. Typically, the CA either returns one or more files each
containing one certificate, or returns a file with multiple certificates in it.

1 In the Administration Console, click Security > Certificates, then click the certificate name.

2 Click Import Signed Certificate.

Security and Certificate Management 55

3 In the Import Signed Certificate dialog box, browse to locate the certificate data file, or paste

the certificate data text into the Certificate data text field.

4 To import the CA chain, click Add trusted root, then locate the certificate data.

5 Click Add intermediate certificate if you need to continue adding certificates to the chain.

6 Click OK, then click Close on the Certificate Details page.

The certificate is now available for use by Access Manager devices.

If you receive an error when attempting to import the certificate, see Chapter B, “Troubleshooting

Certificate Issues,” on page 111.

3.2.2 Managing Certificates and Keystores

You can import certificates created by an external certificate authority. These certificates then need
to be assigned to a device by adding the certificate to the device’s keystore. The subject name of the
certificate needs to match the DNS name of the device, or if you are using wildcard certificates, the
main domain name needs to match. You can perform the following certificate tasks:

 “Importing a Private/Public Key Pair” on page 56

novdocx (en) 19 February 2010

 “Adding a Certificate to a Keystore” on page 57

 “Renewing a Certificate” on page 57

 “Exporting a Private/Public Key Pair” on page 58

 “Exporting a Public Certificate” on page 59

 “Viewing Certificate Details” on page 60

Importing a Private/Public Key Pair

If you created a key pair that was exported from another certificate management system, you can
import the key pair and then assign it to an Access Manager device. The file needs to be in PKCS12

pfx

) or (*.

p12

(*.

) format.

1 In the Administration Console, click Security > Certificates.

2 Choose Actions > Import Private/Public Keypair.

3 Fill in the following fields:

Certificate name: The name of the certificate. This is a system-wide, unique name used by
Access Manager. The name must contain only alphanumeric characters and no spaces. If the
name starts with a number, an underline (_) prefix is added to the name so that the name
conforms to XML requirements. If the name contains invalid characters, it is automatically
renamed.

Keystore password: Type the encryption/decryption password established when exporting the
certificate.

Certificate data file (PFX/PKCS12): The certificate file to import. You can browse to locate

PFX

or

the

PKCS12

file.

Certificate data file (JKS): To locate a JKS file, select this option, then click the Browse
button.

4 Click OK.

56 Novell Access Manager 3.1 SP1 Administration Console Guide

novdocx (en) 19 February 2010

If you receive an error when importing the certificate, the error comes from either NICI or PKI.

®

For a description of these error codes, see Novell

Certificate Server Error Codes and Novell
International Cryptographic Infrastructure (http://www.novell.com/documentation/nwec/
index.html). For general certificate import issues, see Section B.1.1, “Importing an External
Certificate Key Pair,” on page 111.

5 Continue with “Adding a Certificate to a Keystore” on page 57.

Adding a Certificate to a Keystore

After importing a certificate, you need to assign the certificate to keystore before it is used by
Access Manager.

1 In the Administration Console, click Security > Certificates.

2 Select a certificate.

3 Click Actions > Add Certificate to Keystores.

4 Specify the keystore to which you are adding the certificate. To locate a keystore:

4a Click the Select Keystore button.

For a description of the Access Manager created keystores, see Section 3.1.3, “Access

Manager Keystores,” on page 44.

4b On the Keystore Details page, select the keystore, then click OK.

5 Fill in the following fields:

Alias: Specify the certificate alias.

Overwrite keys with same alias: Select whether to overwrite certificates with the same alias,

if the alias you specify is already in use in that keystore.

6 Click OK.

7 Update the device or devices that are using this keystore.

Renewing a Certificate

The Certificate Details page lists the properties of a certificate, such as certificate type, name,
subject, and assigned keystores. This page also includes the original CSR when the certificate is still
in a pending state (for example, you have generated the CSR, but you have not yet received and
imported the signed certificate). If the certificate has expired, you can cut and paste its text to send it
to the CA to get a renewed certificate, then import the newly signed certificate.

1 In the Administration Console, click Security > Certificates.

2 Click the certificate name.

3 Click Renew.

Security and Certificate Management 57

novdocx (en) 19 February 2010

4 On the Renew page, either browse to locate and select the certificate or select the Certificate

data text (PCM/Base64) option and paste the certificate data into the text box.

5 Click OK.

6 Update the device using the certificate.

Exporting a Private/Public Key Pair

When you create a certificate, you can specify whether it is exportable. If a key is exportable, it can
be extracted and put in a file along with the associated certificate. The file is written in an industry
standard format, PKCS#12, which allows it to be transported to other platforms. It is encrypted with
a user-specified password to protect the private key.You can export private certificates to obtain a
backup copy of the key, to move the key to a different server, or to share the key between servers.

You cannot export a certificate if you enabled the Do not allow private key to be exportable option
while creating the certificate.

1 In the Administration Console, click Security > Certificates.

2 On the Certificates page, click the certificate.

3 On the Certificate Details page, click Export Private/Public Keypair.

58 Novell Access Manager 3.1 SP1 Administration Console Guide

4 Select the format for the key:

PFX/PKCS12: Public Key Cryptography Standards #12 (PKCS#12) format, which is also
called PFX format. This format can be used to create JKS or PEM files.

novdocx (en) 19 February 2010

JKS: Java keystore format.

5 Specify the password in the Encryption/decryption password field, then click OK.

IMPORTANT: Remember this password because you need it to re-import the key.

6 Click OK.

Exporting a Public Certificate

You can export a trusted root or a public key certificate to a file so that a client can use it to verify
the certificate chain sent by a cryptography-enabled application, or to have a backup copy of the file.

You can export the certificate in the following formats:

 DER-encoded (.

 PEM-encoded to a file. This is a Base64-encoded DER certificate that is enclosed between

der

) to a file.

BEGIN CERTIFICATE and END CERTIFICATE tags.

 PEM CUT/Paste Buffer. This displays the certificate data so you can copy it to the system

Clipboard. You can then pasted it directly into a cryptography-enabled application.

To export the public certificate:

1 In the Administration Console, click Security > Certificates.

2 Click the certificate name.

3 On the Certificate Details page, click Export Public Certificate, then click the file type.

4 Save the output file to the location of your choosing.

Security and Certificate Management 59

Viewing Certificate Details

The Certificate Details page lists the properties of a certificate, such as certificate type, name,
subject, and assigned keystores. The fields are not editable.

1 In the Administration Console, click Security > Certificates.

2 Click the name of a certificate.

The Certificate Details page contains the following information about the certificate:

Issuer: Displays the name of the CA that created the certificate.

Serial number: Displays the serial number of the certificate.

Subject: Displays the subject name of the certificate.

Valid from: Displays the first date and time that the certificate is valid.

Valid to: Displays the date and time that the certificate expires.

Devices: Indicates the devices that are configured to hold this certificate on their file system.

Key size: Indicates the key size that was used to create the certificate.

Signature algorithm: Indicates the signature algorithm that was used to create the certificate.

novdocx (en) 19 February 2010

Finger print (MD5): Displays the certificate's message digest that was calculated with the
MD5 algorithm. It is embedded into the certificate at creation time. It can be used to uniquely
identify a certificate. For example, a user can verify that a certificate is the one they think it is
by matching this published MD5 fingerprint with the MD5 fingerprint on the local certificate.

Finger print (SHA1): Displays the certificate's message digest that was calculated with the
SHA1 algorithm. It is embedded into the certificate at creation time. It can be used to uniquely
identify a certificate. For example, a user can verify that a certificate is the one they think it is
by matching a published SHA1 fingerprint with the SHA1 fingerprint on the local certificate.

Subject Alternate Names: Critical: Indicates whether an application should reject the
certificate if the application does not understand the alternate name extensions. Any configured
alternate names are displayed in the list.

Key Usage: Critical: Indicates whether an application should reject the certificate if the
application does not understand the key usage extensions.

Sign CRLs: Indicates whether the certificate is used to sign CRLs (Certificate Revocation
Lists).

Sign certificates: Indicates that the certificate is used to sign other certificates.

Encrypt other keys: Indicates that the certificate is used to encrypt keys.

Encrypt data directly: Indicates that the certificate encrypts data for private transmission to

the key pair owner. Only the intended receiver can read the data.

Create digital signatures: Indicates that the certificate is used to create digital signatures.

Non-repudiation: Indicates that the certificate links a digital signature to the signer and the

data. This prevents others from duplicating the signature because no one else has the signer’s
private key. Additionally, the signer cannot deny having signed the data.

CRL Distribution Points: Displays a list of Certificate Revocation List (CRL) distribution
points that are embedded into the certificate as an extension at certificate creation time.
Implementations search the CRL from each distribution point (the distribution point is usually
a URI that points to a store of revoked certificates) to see whether a certificate has been
revoked.

60 Novell Access Manager 3.1 SP1 Administration Console Guide

Authority Info Access (OCSP): Displays a list of Online Certificate Status Protocol (OCSP)
responders that are embedded into the certificate as an extension at certificate creation time.
Implementations query the OCSP responder to see whether a certificate has been revoked.

3.2.3 Managing Trusted Roots and Trust Stores

When an external certificate authority creates certificates, you need to import the trusted root of the
certificate authority and assign the trusted root to the trust store of the device that needs to trust the
certificate. You can perform the following tasks

 “Importing Public Key Certificates (Trusted Roots)” on page 61

 “Adding Trusted Roots to Trust Stores” on page 61

 “Auto-Importing Certificates from Servers” on page 62

 “Exporting the Public Certificate of a Trusted Root” on page 62

 “Viewing Trust Store Details” on page 62

 “Viewing Trusted Root Details” on page 63

novdocx (en) 19 February 2010

Importing Public Key Certificates (Trusted Roots)

You import trusted roots so that the specific device can trust the certificate sent by other computers
at runtime. After you import a trusted root, you can assign it to the proper trust store associated with
a device, which allows the device to trust certificates signed by the trusted root.

1 In the Administration Console, click Security > Trusted Roots.

2 Click Import, then specify a name for the certificate.

This is a system-wide, unique name used by Access Manager.

3 Select one of the following methods for importing the public key:

 Certificate data file (DER/PEM/PKCS7): Select this method to browse to a file. Click

Browse to locate the file on your file system.

 Certificate data text (PEM/Base64): Select this method to paste Base64-encoded

certificate data text.

4 Click OK.

5 Continue with “Adding Trusted Roots to Trust Stores” on page 61

Adding Trusted Roots to Trust Stores

After importing a trusted root, you need to assign it to a device before it is used by Access Manager.

To add a trusted root to an existing trust store:

1 In the Administration Console, click Security > Trusted Roots.

2 Select the trusted root, then click Add Trusted Roots to Trust Stores.

3 Fill in the following fields:

Truste d roots: Select the trusted root store. To locate the trusted root store, click the Select
Keystore icon. When you browse, the system displays the Select Trusted Roots page. Select the
trusted root store, then click OK.

Alias(es): Specify an alias for the trusted root.

Security and Certificate Management 61

4 Click OK.

5 Update the device that is using this trust store.

Auto-Importing Certificates from Servers

You can import certificates from other servers (such as an LDAP server, an identity provider, or
service provider) and make them available for use in Access Manager. You must provide the IP
address, port, and certificate name.

1 In the Administration Console, click Security > Trusted Roots > Auto-Import from Server.

2 Fill in the following fields:

Server IP Address: Specify the server IP address. You can use a DNS name.

Server Port: Specify the server port.

Certificate Name: Specify a unique name of the certificate to store in Access Manager.

3 Click OK.

Exporting the Public Certificate of a Trusted Root

novdocx (en) 19 February 2010

You can export a trusted root or a public key certificate to a file so that a client can use it to verify
the certificate chain sent by a cryptography-enabled application, or to have a backup copy of the file.

You can export the certificate in the following formats:

 DER-encoded (.

 PEM-encoded to a file. This is a Base64-encoded DER certificate that is enclosed between

der

) to a file.

BEGIN CERTIFICATE and END CERTIFICATE tags.

 PEM CUT/Paste Buffer. This displays the certificate data so you can copy it to the system

Clipboard. You can then pasted it directly into a cryptography-enabled application.

To export the public certificate:

1 In the Administration Console, click Security > Trusted Roots.

2 Click the name of the trusted root.

3 On the Certificate Details page, click Export Public Certificate, then click the file type.

4 Save the output file to the location of your choosing.

Viewing Trust Store Details

To view the details of a trust store:

1 In the Administration Console, click Security > Trusted Roots.

2 Under the Devices column, click the name of a trust store.

3 View the following information.

Trust store name: The name of the selected trust store

Trust store type: The type of trust store such as Java, PEM, or DER.

Cluster or Device name: The name of the cluster using this trust store or the single device that

is using the trust store.

62 Novell Access Manager 3.1 SP1 Administration Console Guide

Cluster members’ Trust Stores: The trust stores assigned to a cluster. If a device does not
belong to a cluster, this section does not appear.

Viewing Trusted Root Details

1 In the Administration Console, click Security > Trusted Roots.

2 Click the name of a trusted root.

3 View the following information:

Field Description

Issuer The name of the CA that created the certificate.

Serial number The serial number of the certificate.

Subject The subject name of the certificate.

Valid from The first date and time that the certificate is valid.

Valid to The date and time that the certificate expires.

novdocx (en) 19 February 2010

Devices The devices that are configured to hold this certificate on their

file system.

Key size The key size that was used to create the certificate.

Signature algorithm The signature algorithm that was used to create the certificate.

Finger print (MD5) The certificate's message digest that was calculated with the

MD5 algorithm. It is embedded into the certificate at creation
time. It can be used to uniquely identify a certificate. For
example, a user can verify that a certificate is the one they
think it is by matching this published MD5 fingerprint with the
MD5 fingerprint on the local certificate.

Finger print (SHA1) The certificate's message digest that was calculated with the

SHA1 algorithm. It is embedded into the certificate at creation
time. It can be used to uniquely identify a certificate. For
example, a user can verify that a certificate is the one they
think it is by matching a published SHA1 fingerprint with the
SHA1 fingerprint on the local certificate.

The Subject Alternate Names section indicates whether an application should reject the
certificate if the application does not understand the alternate name extensions. Any configured
alternate names are displayed in the list.

The Key Usage section indicates whether an application should reject the certificate if the
application does not understand the key usage extensions. The following are possible:

Sign CRLs: Indicates whether the certificate is used to sign CRLs (Certificate Revocation
Lists).

Sign certificates: Indicates that the certificate is used to sign other certificates.

Encrypt other keys: Indicates that the certificate is used to encrypt keys.

Encrypt data directly: Indicates that the certificate encrypts data for private transmission to

the key pair owner. Only the intended receiver can read the data.

Create digital signatures: Indicates that the certificate is used to create digital signatures.

Security and Certificate Management 63

Non-repudiation: Indicates that the certificate links a digital signature to the signer and the
data. This prevents others from duplicating the signature because no one else has the signer’s
private key. Additionally, the signer cannot deny having signed the data.

CRL Distribution Points: Displays a list of Certificate Revocation List (CRL) distribution
points that are embedded into the certificate as an extension at certificate creation time.
Implementations search the CRL from each distribution point (the distribution point is usually
a URI that points to a store of revoked certificates) to see whether a certificate has been
revoked.

Authority Info Access (OCSP): Displays a list of Online Certificate Status Protocol (OCSP)
responders that are embedded into the certificate as an extension at certificate creation time.
Implementations query the OCSP responder to see whether a certificate has been revoked.

3.2.4 Security Considerations for Certificates

Your security deployment plan should contain policies for the following:

 Key size for certificates: The Access Manager product ships with a CA that can create

certificates with a key size of 512, 1024, 2048 or 4096. Select the maximum size supported by
the applications that you are protecting with Access Manager.

 Certificate renewal dates: We recommend that certificates should be renewed every two

years. Your security needs might allow for a longer or shorter period.

novdocx (en) 19 February 2010

 Trusted certificate authorities: The Access Manager ships with a CA, and during installation

of the various components, it creates and distributes certificates. For added security, you might
want to replace these certificates with certificates from a well-known CA.

3.3 Assigning Certificates to Access Manager
Devices

After you assign certificates to devices, the certificates are placed in keystores. Ensure that you
update the device so that the certificates are pushed into active use.

This section discusses how you update, renew, and assign certificates to Access Manager devices.

 Section 3.3.1, “Importing a Trusted Root to the LDAP User Store,” on page 65

 Section 3.3.2, “Replacing Identity Server SSL Certificates,” on page 66

 Section 3.3.3, “Assigning Certificates to an Access Gateway,” on page 67

 Section 3.3.4, “Assigning Certificates to J2EE Agents,” on page 68

 Section 3.3.5, “Configuring SSL for Authentication between the Identity Server and Access

Gateway,” on page 68

 Section 3.3.6, “Changing a Non-Secure (HTTP) Environment to a Secure (HTTPS)

Environment,” on page 69

 Section 3.3.7, “Creating Keystores and Trust Stores,” on page 69

 Section 3.3.8, “Reviewing the Command Status for Certificates,” on page 71

64 Novell Access Manager 3.1 SP1 Administration Console Guide

3.3.1 Importing a Trusted Root to the LDAP User Store

When you specify the settings of a user store for an Identity Server configuration, or add a user
store, you can import the trusted root certificate to the LDAP user store device.

1 In the Administration Console, click Devices > Identity Servers > Edit > Local > [User Store].

2 Under Server Replicas, click the name of the server replica.

novdocx (en) 19 February 2010

3 Enable the Use secure LDAP connections option.

This option allows SSL communication to occur between the Identity Server and the user store.

4 Click Auto import trusted root.

5 Click OK to confirm the import.

Ensure that you have pop-ups enabled, or the browser cannot display the Confirm dialog box.

Security and Certificate Management 65

novdocx (en) 19 February 2010

6 Select one of the certificates in the list.

You are prompted to choose either a server certificate or a root CA certificate. To trust one
certificate, choose Server Certificate. Choose Root CA Certificate to trust any certificate signed
by that certificate authority.

7 Specify an alias, then click OK.

You use the alias to identify the certificate in Access Manager.

8 On the User Store page, click OK.

9 Restart the Identity Server.

3.3.2 Replacing Identity Server SSL Certificates

This procedure allows you to replace a trusted root certificate that is stored in the trust store assigned
to the Identity Server. You must create an SSL certificate for the Identity Server and then replace the
predefined test-connector certificate that comes with Access Manager. You can also replace the test­provider and test-consumer certificates in the NIDP-provider and NIDP-consumer keystores. The
steps for replacing the signing, encryption, provider, and consumer certificates are similar.

You can also add the trusted roots to the trust stores used by the Identity Server, or auto-import them
from a server. The NIDP trust store is the certificate container for CA certificates associated with the
Identity Server.

You can also access the OCSP trust store to add OCSP server certificates. Online Certificate Status
Protocol is a method used for checking the revocation status of a certificate. For this feature, you
must set up an OCSP server. The Identity Server sends an OCSP request to the OCSP server to
determine if a certain certificate has been revoked. The OCSP server replies with the revocation
status. If this revocation checking protocol is used, the Identity Server does not cache or store the
information in the reply, but sends a request every time it needs to check the revocation status of a

66 Novell Access Manager 3.1 SP1 Administration Console Guide

certificate. The OCSP reply is signed by the OCSP server. To verify that it was signed by the correct
OCSP server, the OCSP server certificate needs to be added to this trust store. The OCSP server
certificate itself is added to the trust store, not the CA certificate

1 In the Administration Console, click Devices > Identity Servers > Edit > Security.

2 Click the certificate link that you want to replace:

Encryption: Displays the encryption certificate keystore. The encryption certificate is used to
encrypt specific fields or data in the assertions.

Signing: Displays the signing certificate keystore. Click this option to access the keystore and
replace the signing certificate as necessary. The signing certificate is used to sign the assertion
or specific parts of the assertion.

SSL: Displays the SSL connector keystore. Click this option to access the keystore and replace
the SSL certificate as necessary. This certificate is used for SSL connections.

Provider: Displays the identity provider keystore. Click this option to access the keystore and
replace the identity provider certificate.

Consumer: Displays the identity consumer keystore. Click this option to access the keystore
and replace the identity consumer certificate as necessary.

novdocx (en) 19 February 2010

3 Click Replace.

A keystore stores only one certificate at a time. When you replace a certificate, you overwrite
the existing one.

4 In the Replace dialog box, click the Select Certificate icon and browse to select the certificate

you created in Section 3.2.1, “Creating Certificates,” on page 47.

5 Click OK.

6 Click OK in the Replace dialog box.

7 Restart Tomcat, as prompted by the system.

The system restarts Tomcat for you if you click Restart Now at the prompt. If you want to
restart at your convenience, select Restart Later and then manually restart Tomcat.

Linux: Enter the following command:

/etc/init.d/novell-tomcat5 restart

Windows: Enter the following commands:

net stop Tomcat5

net start Tomcat5

8 Update the Identity Server configuration on the Servers page, as prompted.

3.3.3 Assigning Certificates to an Access Gateway

The Access Gateway can be configured to use certificates for SSL communication with three types
of entities:

 Identity Server: The Access Gateway uses the Embedded Service Provider to communicate

with the Identity Server. The Access Manager CA automatically generates the required
certificates for secure communication when you set up a trusted relationship with the Identity
Server. To manage these certificates in the Administration Console, click Access Gateways >

Security and Certificate Management 67

[Configuration Link] > Service Provider Certificates. For more information, see “Managing

Embedded Service Provider Certificates” in the Novell Access Manager 3.1 SP1 Access

Gateway Guide.

 Client browsers: You can enable SSL communication between the client browsers and the

Access Gateway. When setting up this feature, you can either have the Access Manager CA
automatically generate a certificate key or you can select a certificate key you have already
imported (or created) for the reverse proxy. To manage this certificate in the administration
console, click Access Gateways > [Configuration Link] > [Name of Reverse Proxy]. For more
information, see “Creating a Reverse Proxy and Proxy Service” in the Novell Access Manager

3.1 SP1 Access Gateway Guide.

 Protected Web servers: You can enable SSL communication between the Access Gateway

and the Web servers it is protecting. This option is only available if you have enabled SSL
communication between the browsers and the Access Gateway. You can enable SSL or mutual
SSL. To manage these certificates in the Administration Console, click Access Gateways >
[Configuration Link] > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Ser v ers .
For more information, see “Configuring the Web Servers of a Proxy Service” in the Novell

Access Manager 3.1 SP1 Access Gateway Guide.

novdocx (en) 19 February 2010

3.3.4 Assigning Certificates to J2EE Agents

To enable the J2EE agent for SSL, you must set up the following trust relationships:

 The J2EE server with the Identity Server

 The J2EE agent with the Identity Server

For instructions on setting up these certificates, see “Configuring SSL Certificate Trust” in the

Novell Access Manager 3.1 SP1 Agent Guide.

3.3.5 Configuring SSL for Authentication between the Identity
Server and Access Gateway

By default, all Access Manager components (Identity Server, Access Gateway, SSL VPN, and J2EE
agents) trust the certificates signed by the local CA. However, if the Identity Server is configured to
use an SSL certificate signed externally, the trusted store of the service provider for each component
must be configured to trust this new CA. Import the public certificate of the CA into the following
trust stores:

 For an Access Gateway, click Devices > Access Gateways > Edit > Service Provider

Certificates > Trusted Roots.

 For a J2EE agent, click Devices > J2EE Agents > Edit > Trusted Roots.

 For an SSL VPN server, click Devices > SSL VPNs > Edit > SSL VPN Certificates > Trusted

Root.

If an Access Gateway, a J2EE agent, or an SSL VPN server is configured to use an SSL certificate
signed externally, the trusted store of the Identity Server must be configured to trust this new CA.
Import the public certificate of the CA into the Identity Server configuration that the component is
using for authentication.

In the Administration Console, click Devices >Identity Servers > Edit > Security > NIDP Trust
Store and add the certificate to the Trusted Roots list.

68 Novell Access Manager 3.1 SP1 Administration Console Guide

NOTE: Whenever you replace certificates on a device, you must update the Identity Server
configuration (by clicking Update Servers on the Servers page), or restart the Access Gateway ESP
application.

3.3.6 Changing a Non-Secure (HTTP) Environment to a Secure
(HTTPS) Environment

If you are running in a non-secure staging environment, and you’re ready to move to production,
you must perform the following steps to enable security.

1 Change the Identity Server configuration protocol to HTTPS. (See “Configuring Secure

Communication on the Identity Server” in the Novell Access Manager 3.1 SP1 Setup Guide)

2 Replace the test certificates with your own. (See “Using Access Manager Certificates” or

“Using Externally Signed Certificates” in the Novell Access Manager 3.1 SP1 Setup Guide.)

3 Update all devices that are trusting this Identity Server configuration.

This causes the Embedded Service Provider to reimport the metadata of the Identity Server.

4 (Conditional) If you have set up federation, reimport metadata for trusted service and identity

providers. (See “Managing Metadata” in the Novell Access Manager 3.1 SP1 Identity Server

Guide.)

5 Change the Access Gateway configuration to HTTPS. (See “Configuring the Access Gateway

for SSL” in the Novell Access Manager 3.1 SP1 Setup Guide.)

novdocx (en) 19 February 2010

3.3.7 Creating Keystores and Trust Stores

A keystore is storage file containing keys, certificates, and trusted roots. Access Manager agents can
access them to retrieve certificates, keys, and trusted roots as needed. A trust store is a keystore
containing only trusted roots. Intermediate CAs and end entity public certificates can be part of a
trust store.

Access Manager comes with predefined stores for certificate management. However, in certain
situations you might need to create a keystore or trust store. For example, if you are using JBoss
keystore certificates that you need to import into Access Manager, you must create a keystore and
assign it to the JBoss agent. It is probable that the keystore already exists on the JBoss file system, as
created and configured by JBoss. Creating it again through Access Manager does not delete the
existing keystore. This does allow Access Manager to recognize the existing keystore and add or
remove the certificates. Access Manager cannot manage certificates that were created before the
keystore is created in Access Manager.

The easiest way to create a keystore is to do so when you are adding the certificate to the keystore. If
you want to create a trust store, the steps are identical, except you select trusted roots from the
Trusted Roots page, rather than the certificates from the Certificates page.

A keystore stores only one certificate at a time. When you replace a certificate, you overwrite the
existing one.

1 In the Administration Console, click Security > Certificates.

2 Import the certificate, if you have not done so already. See “Importing a Private/Public Key

Pair” on page 56.

3 Click the certificate name.

Security and Certificate Management 69

4 In the Certificate Details page, click Add Certificate to Keystores.

5 On the Add Certificate to Keystores dialog box, click the Select Keystore button to browse for

key stores.

6 On the Keystore page, click New.

novdocx (en) 19 February 2010

7 Fill in the following fields:

Keystore name: Specifies the name of the keystore. This maps to a name that the server
communication recognizes to identify the keystore on the device.

Keystore type: Specifies whether to use Java, PEM, or PKCS12.

Keystore password: Specifies the password to revise the keystore settings.

Device: Specifies the device (by IP) to which you assign the keystore. The device can be an

Identity Server or SSL VPN. You cannot assign one keystore to multiple devices.

Directory: Specifies the directory where PKCS12 or PEM files are stored.

For example,

/var/opt/novell/keystores/

.

File: Specifies the path and filename of the Java keystore (JKS).

For example,

/var/opt/novell/keystores/myKeystore.keystore

.

Description: Describes the keystore.

8 Click OK.

This creates the keystore.

9 (Optional) On the Keystore page, assign a certificate to the new keystore by selecting the

store’s check box.

10 Click OK in the Add Certificate to Keystores dialog box.

70 Novell Access Manager 3.1 SP1 Administration Console Guide

3.3.8 Reviewing the Command Status for Certificates

You can view the status of the commands that have been sent to the certificate server for execution.

1 In the Administration Console, click Security > Certificates, then click Command Status.

2 Use the following options to review or change a server’s certificate command status:

 Delete: To delete a command, select the check box for the command, then click Delete.

The selected command is cleared.

 Refresh: Click Refresh to update the current cache of recently executed commands.

 Name: Click this box to select all the commands in the list, then click Refresh or Delete.

The following table describes the features on this page:

Column Name Description

Name Contains the display name of the command. Click the link to view additional

details about the command.

Status Specifies the status of the command. Some of the possible states of the

command include

Pending, Incomplete, Executing

, and

Succeeded

.

novdocx (en) 19 February 2010

Type Specifies the type of server, such as Identity Server or Access Gateway.

Commands Specifies the command given, such as

trusted root

Admin Specifies if the system or a user issued the command. If a user issued the

command, the DN of the user is displayed.

Date & Time Specifies the local date and time the command was issued.

.

Import certificate

, or

3 To review command information, click the link under a Name.

Import

This page displays status information about the command and allows you to perform the
following tasks:

Refresh: Select this option to update the current cache of recently executed commands.

Delete: Select this option to clear the current cache of recently executed commands.

Security and Certificate Management 71

The following command information is listed:

Name: Specifies the display name that has been given to the command.

Type: Specifies the type of command.

Admin: Specifies whether the system or a user issued the command. If a user issued the

command, the field contains the DN of the user.

Status: Specifies the status of the command, and includes such states as Pending, Incomplete,
Executing, and Succeeded.

Last Executed On: Specifies when the command was issued. The date and time are displayed
in local time. If the command failed, additional information is available.

For a command that the Administration Console can successfully process, the page displays a
Command Execution Details section with the name of the command and the command results.

4 Click Close.

novdocx (en) 19 February 2010

72 Novell Access Manager 3.1 SP1 Administration Console Guide

4

Access Manager Logging

 Section 4.1, “Understanding the Types of Logging,” on page 73

 Section 4.2, “Downloading the Log Files,” on page 74

 Section 4.3, “Using the Log Files for Troubleshooting,” on page 79

4.1 Understanding the Types of Logging

Access Manager supports three types of logging:

 Section 4.1.1, “Component Logging for Troubleshooting Configuration or Network Problems,”

on page 73

 Section 4.1.2, “HTTP Transaction Logging for Proxy Services,” on page 74

4.1.1 Component Logging for Troubleshooting Configuration

novdocx (en) 19 February 2010

4

or Network Problems

Each Access Manager component maintains log files that contain entries documenting the operation
of the component. Component file logging records the processing and interactions between the
Access Manager components that occur while satisfying user and administrative requests and during
general system processing. By enabling the correct levels of logging for the various Access Manager
components, an administrator can monitor how the Access Manager processes user and
administrative requests. Transaction flows have been defined to help the administrator identify the
processing steps that occur during the execution of specific types of user or administrative requests.
All component file logs include tags and values that allow the administrator to identify and correlate
which component file log entries pertain to a given transaction and user.

Component file logs are not primarily intended for debugging the software itself, although they can
be used to detect software that is not behaving properly. Rather, the intent of component file logging
is to document the operational processing of the Access Manager components so that system
administrators and support personnel can identify and isolate problems caused by configuration
errors, invalid user data, or network problems such as broken connection. However, component file
logging is typically the first step in identifying software bugs.

Component file logging is more verbose than audit logging. It increases processing load, and on a
day-to-day basis, it should be enabled only to log error conditions and system warnings. If a specific
problem occurs, component file logging can be set to info or config to gather the information needed
to isolate and repair the detected problem. When the problem is resolved, component file logging
should be reconfigured to log only error conditions and system warnings.

Log files can be configured to include entries for the following events:

 Initialization and shutdown

 Configuration

 Events processed by the component, such as authentication, role assignment, resource access,

and policy evaluation

 Error conditions

Access Manager Logging

73

See “Configuring Component Logging” in the Novell Access Manager 3.1 SP1 Identity Server

Guide.

4.1.2 HTTP Transaction Logging for Proxy Services

The Access Gateway allows you to log HTTP transactions. You can log what happens with an HTTP
request and response during certain times:

 Between the browser and the Access Gateway

 Between the Access Gateway and the back-end Web server

You select fields from the HTTP header of a request and these fields are logged. You can then use
these logged transactions to bill customers for Web services or to troubleshoot whether a request is
refused because the browser didn’t send the required information or because the Access Gateway
didn’t send the Web server the required information. This type of logging conforms to the W3C
specification for proxy server logging in the common and extended log formats. This type of
logging provides no information about the exchanges between the Access Gateway and the Identity
Server. If you need to discover whether the Access Gateway is obtaining the correct information
from the Identity Server for an Identity Injection or Form Fill policy, you need to turn on Component
logging. See “Configuring Component Logging” in the Novell Access Manager 3.1 SP1 Identity

Server Guide.

novdocx (en) 19 February 2010

For HTTP transaction logging, see “Configuring Proxy Service Logging” in the Novell Access

Manager 3.1 SP1 Access Gateway Guide.

4.2 Downloading the Log Files

The General Logging page displays the location of the files that the Access Manager components
use for logging system messages. There are two exceptions:

 J2EE Agent: The J2EE Agent uses the J2EE global logger, and the location of this file is

customizable. For information about J2EE agent log files, see “Viewing Log Files” in the

Novell Access Manager 3.1 SP1 Agent Guide.

 Default Auditing File: If you have configured Novell Audit to send events to the default audit

file (on Linux, this is

/var/opt/novell/naudit/logs/auditlog

in the list. (On a Windows machine that has different security restraints, the file appears in the
list.)

If you want this file to appear in this list on a Linux machine, you must make this file readable
by the novlwww user. It is a breach of Novell Audit security for Access Manager code to
change the permissions on this file. You must decide whether changing its permissions and
displaying the file in this list compromises your security.

To have it appear in the list of files for the Administration Console, configure the following:

 Use commands similar to the following to grant the

novlwww

to the naudit directories:

chmod o+x /var/opt/novell/naudit
chmod o+x /var/opt/novell/naudit/logs

 Use a command similar to the following to grant the

auditlog

chmod o+r /var/opt/novell/naudit/logs/auditlog

file:

novlwww

), this file does not appear

user executable permissions

user read access to the

74 Novell Access Manager 3.1 SP1 Administration Console Guide

To view or download the log file:

1 In the Administration Console, click Auditing > General Logging.

2 Select one or more log files, click Download, then open it or save it to disk.

You can use any text editor to view the file.

Each Access Manager Component generates multiple log files. Table 4- 1 lists these files and the
types of messages they contain.

Table 4-1 Access Manager Log Files

Component Filename Description

Linux Administration Console

novdocx (en) 19 February 2010

/var/opt/novell/tomcat5/logs/
catalina.out

/opt/novell/devman/share/logs/
app_sc.0.log

/opt/novell/devman/share/logs/
app_cc.0.log

/opt/novell/devman/share/logs/
platform.0.log

Windows Administration Console

/Program Files/Novell/Tomcat/logs/
stderr.log

/Program Files/Novell/Tomcat/logs/
stdout.log

/Program Files/Novell/log/
app_sc.0.log

Contains Tomcat errors.

Contains events related to importing
devices, device configuration changes,
health status changes, statistics
reporting, and communication problems.

Contains events related to policy
configuration.

Contains XML events for configuration
changes. This log file contains very little
useful information for system
administrators.

Contains Tomcat error messages
directed to stderr.

Contains Tomcat error messages
directed to stdout.

Contains events related to importing
devices, device configuration changes,
health status changes, statistics
reporting, and communication problems.

/Program Files/Novell/log/
app_cc.0.log

/Program Files/Novell/log/
platform.0.log

/Program Files/Novell/Nsure Audit/
logs/auditlog

Linux Identity Server

Contains events related to policy
configuration.

Contains XML events for configuration
changes. This log file contains very little
useful information for system
administrators.

Contains the log entries for Novell
auditing.

Access Manager Logging 75

Component Filename Description

novdocx (en) 19 February 2010

/var/opt/novell/tomcat5/logs/
catalina.out

/opt/novell/devman/jcc/logs/jcc-

0.log.0

Windows Identity Server

/Program Files/Novell/Tomcat/logs/
stderr.log

/Program Files/Novell/Tomcat/logs/
stdout.log

Logging to this file only occurs if you
have selected the Echo to Console
option from the Identity Servers >
Servers > Edit > Logging page.

When component logging has been set
to info for Applications, it contains entries
tracing user authentication and role
assignments.

Contains the log entries for the server
communications module related to
interaction of the Identity Server with the
Administration Console, such as imports,
certificates, health checks, and
configuration.

Contains Tomcat error messages
directed to stderr.

Logging to this file only occurs if you
have selected the Echo to Console
option from the Identity Servers >
Servers > Edit > Logging page.

When component logging has been set
to info for Applications, it contains entries
tracing user authentication and role
assignments.

/Program Files/Novell/devman/jcc/
logs/jcc-0.log.0

Linux Access Gateway Appliance

/var/opt/novell/tomcat5/logs/
catalina.out

Contains the log entries for the server
communications module related to
interaction of the Identity Server with the
Administration Console, such as imports,
certificates, health checks, and
configuration.

Logging to this file only occurs if you
have selected the Echo to Console
option from the Identity Servers >
Servers > Edit > Logging page.

Check this file for entries tracing the
evaluation of authorization, identity
injection, and form fill policies.

76 Novell Access Manager 3.1 SP1 Administration Console Guide

Component Filename Description

novdocx (en) 19 February 2010

/var/log/novell/reverse/<name>

/var/log/ics_dyn.log

Contains all log entries generated by the

/opt/novell/devman/jcc/logs/jcc-

0.log.0

/var/log/lagsoapmessages

If logging is enabled on one or more
reverse proxies, this directory contains
the log files. (To enable this type of
logging, see “Configuring Proxy Service

Logging” in the Novell Access Manager

3.1 SP1 Access Gateway Guide.)

A directory is listed for each reverse
proxy on which you have enabled
logging.

Linux Access Gateway. Use syslog to
control file rolling and log file distribution.

Contains the log entries for the server
communications module related to
interaction of the Access Gateway with
the Administration Console, such as
imports, certificates, health checks, and
configuration.

Logs all the SOAP messages between
the Linux Access Gateway and the
Embedded Service Provider.

/var/log/laghttpheaders

Linux Access Gateway Service

/var/opt/novell/amlogging/logs/
ags.log

/var/log/novell/reverse/<name>

Contains a log of the HTTP headers to
and from the Linux Access Gateway.

Contains the messages generated for
configuration, device imports, health, and
statistics. It also contains entries for the
policy evaluation processes done by the
Gateway Service Manager module.

If logging is enabled on one or more
reverse proxies, this directory contains
the log files. (To enable this type of
logging, see “Configuring Proxy Service

Logging” in the Novell Access Manager

3.1 SP1 Access Gateway Guide.)

A directory is listed for each reverse
proxy on which you have enabled
logging.

Access Manager Logging 77

Component Filename Description

novdocx (en) 19 February 2010

/var/opt/novell/tomcat5/logs/
catalina.out

Windows Access Gateway Service

/Program Files/Novell/amlogging/
logs/ags.log

/Program Files/Novell/Apache/logs/

<name>

Contains the log messages generated by
the embedded service provider. Logging
to this file only occurs if you have
selected the Echo to Console option from
the Identity Servers > Servers > Edit >
Logging page.

Check this file for entries tracing the
evaluation of authorization, identity
injection, and form fill policies.

Contains the messages generated for
configuration, device imports, health, and
statistics. It also contains entries for the
policy evaluation processes done by the
Gateway Service Manager module.

If logging is enabled on one or more
reverse proxies, this directory contains
the log files. (To enable this type of
logging, see “Configuring Proxy Service

Logging” in the Novell Access Manager

3.1 SP1 Access Gateway Guide.)

A directory is listed for each reverse
proxy on which you have enabled
logging.

/Program Files/Novell/Tomcat/logs/
stdout.log

SSL VPN Server

/var/opt/novell/tomcat5/logs/
catalina.out

/opt/novell/devman/jcc/logs/jcc-

0.log.0

/var/log/messages

Contains the log messages generated by
the embedded service provider. Logging
to this file only occurs if you have
selected the Echo to Console option from
the Identity Servers > Servers > Edit >
Logging page.

When component logging has been set
to info for Applications, it contains entries
tracing user authentication and role
assignments.

Logging to this file only occurs if you
have selected the Echo to Console
option from the Identity Servers >
Servers > Edit > Logging page.

Contains the log entries for the server
communications module related to
interaction of the SSL VPN with the
Administration Console, such as imports,
certificates, and configuration.

Contains the log entries for the
connection manager and socks servers.

78 Novell Access Manager 3.1 SP1 Administration Console Guide

Component Filename Description

novdocx (en) 19 February 2010

/var/log.novell-openvpn.log

/var/log/stunnel.log

Contains log entries for the OpenVPN
server or the Enterprise mode server.

Contains log entries for Stunnel or the
Kiosk mode server.

4.3 Using the Log Files for Troubleshooting

The following sections describe the logging features available in Access Manager and provide
information on how you can use them for troubleshooting problems:

 Section 4.3.1, “Enabling Logging,” on page 79

 Section 4.3.2, “Understanding Log Format,” on page 79

 Section 4.3.3, “Sample Authentication Traces,” on page 82

For information about policy tracing, see “Understanding Policy Evaluation Traces” in the Novell

Access Manager 3.1 SP1 Policy Management Guide.

4.3.1 Enabling Logging

Each Access Manager device has configuration options for logging:

Identity Server: Logging is turned off and must be enabled. When you enable Identity Server
logging, you also enable logging for the Embedded Service Providers that are configured to use the
Identity Server for authentication. For configuration information, see “Configuring Component

Logging” in the Novell Access Manager 3.1 SP1 Identity Server Guide.

Embedded Service Providers: Each Access Manager device has an Embedded Service Provider
that communicates with the Identity Server. Its log level is controlled by configuring Identity Server
logging.

Linux Access Gateway Appliance: A log notice level of logging is enabled by default. You can
change the level from the command line interface. For information, see “Gateway Appliance Logs”
in the Novell Access Manager 3.1 SP1 Access Gateway Guide.

4.3.2 Understanding Log Format

Access Manager does not have a fixed format for file log entries. However, to facilitate the use of
non-interactive stream-oriented editors such as sgrep, sed, awk, and grep and to improve log entry
readability, the log entries in the

catalina.out

the beginning and ending log entry tags and the log entry correlation tags. The data portion of log
entries is the most flexible part. A log entry has the following fields:

<amLogEntry> [\n]
time-date-stamp
[log preamble]:
AM#event-code:
AMDEVICE#device-id:

files use some standard elements. These entries use

Access Manager Logging 79

AMAUTHID#auth-id:
AMEVENTID#event-id:
[..additional correlating information][\n]
[supplementary log entry data and text ... \n]
</amLogEntry> [\n]

novdocx (en) 19 February 2010

Most log entries do not use the optional line breaks (

[\n]

). Notice that the time-date-stamp, the log
preamble, the correlation tags, and optional additional correlating information are on the same line
so that stream-oriented editors that use only one line (such as grep) can be used to locate log entries
that are related. The following entry is a typical entry that is logged when a user has initiated a login
sequence.

<amLogEntry> 2007-06-08T21:06:25Z INFO NIDS Application: AM#500105014:
AMDEVICEID#9921459858EAAC29: AMAUTHID#BB11C254B7521B5E836D8703826287 AF:
Attempting to authenticate user cn=jwilson,o=novell with provided credentials.
</amLogEntry>

Table 4-2 Fields in a Log Entry

Field Description

Beginning, ending tags The

Time-date-stamp tag The date and time is specified in the W3C profile format of ISO 8061. It

Log preamble This information is optional, and usually consists of a string indicating the

<amLogEntry>

the end of a log entry. These tags allow stream-oriented editors to extract
log entries for processing.

has the following fields: year-month-day-T-hour-minutes-seconds-time
zone. The Z value for the time zone indicates that the time is specified in
UTC.

logging level (such as warning, informational, or debug) and a string
identifying the type of module making the entry.

and

</amLogEntry>

tags mark the beginning and

In the example log entry, the preamble has a log level and a module
identifier and contains the following strings:

Correlation tags The correlation tags uniquely identify the event, the device that produced

the event, and the user who requested the action. The example log entry
contains the following correlation tags:

INFO NIDS Application

AM#500105014: AMDEVICEID#9921459858EAAC29:
AMAUTHID#BB11C254B7521B5E836D8703826287AF:

For more information, see “Understanding the Correlation Tags in the Log

Files” on page 81.

Additional correlation
information

This information is optional, and contains correlation tags and data unique
to a specific type of trace. For example, a policy evaluation trace created
by the Embedded Service Provider contains the following additional tags:

 NXPESID#value

 POLICYID#value

The example log entry does not contain any additional correlation
information. For a log entry that does, see “Identity Injection Traces” in the

Novell Access Manager 3.1 SP1 Policy Management Guide.

:

80 Novell Access Manager 3.1 SP1 Administration Console Guide

Field Description

Supplementary information This information is optional, and contains information that is specific to the

log entry. It can be as simple as an informational string, such as the string
in the example log entry:

Attempting to authenticate user cn=jwilson,o=novell
with provided credentials.

The supplementary information can have a very specific format. For an
example and explanation of the policy trace information, see
“Understanding Policy Evaluation Traces” in the Novell Access Manager

3.1 SP1 Policy Management Guide.

Understanding the Correlation Tags in the Log Files

There is no fixed field format for log file entries. However, because most requests handled by
Access Manager are processed by multiple Access Manager components, there is a mechanism
defined that facilitates the correlation of log entries for a single Access Manager request in the
various component log files. A correlation tag has the following general format:

novdocx (en) 19 February 2010

<tag name>#<tag value>:

The

<tag name>

by the # character. The
terminated by the : character. The

is a fixed value, defined in the Format column of Table 4-3. It is always terminated

<tag value>

begins immediately following the # character and is always

<tag value>

is not a fixed value, but a uniquely assigned value

to identify an event, a user, or a transaction. Tab le 4-3 lists the defined correlation tags:

Table 4-3 Correlation Tags

Type Format Description

Event code

User ID

AM#<Event-Code>:

AMAUTHID#<ID>:

An event number defined in Event Codes (http://

www.novell.com/documentation/novellaccessmanager/
eventcodes/data/bookinfo.html). This tag is included in all

log entries that record an event and in all events that are
presented to the user as an informational or error page.

An authentication identifier that the Identity Server or the
Embedded Service Provider assigns to each authenticated
user. This tag is included in all entries that pertain to a
request made by an authenticated user.

Currently the Identity Server and the Embedded Service
Provider (ESP) assign different authentication IDs. When
correlating the flow of events between the Identity Server
and the ESP for an authentication sequence, you can use
the event code of the authentication events and find the
artifact that the ESP and the Identity Server exchange.

catalina.out

In the

AM#500105018

artifact to the ESP. Search for a corresponding artifact in
the Access Gateway log. Events

AM#500105021

file of the Identity Server, search for

events. This is the event that sends the

AM#500105020

contain the artifact value.

and

Access Manager Logging 81

Type Format Description

novdocx (en) 19 February 2010

Device ID

Transaction ID

AMDEVICE#<ID>

AMEVENTID#<ID>:

An identifier that uniquely identifies the Access Manager
device that is generating the log entry.

You can view the identifier that is assigned to each device
on the General Logging page in the Administration Console
(click Access Gateways > Auditing > General Logging).
The ID begins with a prefix that identifies the type of device
such as idp for Identity Server, ag for an Access Gateway,
and idp-esp for the Embedded Service Provider of the
device. The prefix is followed by a 16-digit hexadecimal
number.

In log entries, the idp prefix is not recorded. For example,
the General Logging page displays

AA257DA77ED48DB0

catalina.out

in the

AMDEVICE#AA257DA77ED48DB0

An identifier assigned to each Access Manager or system
administration transaction. Access Manager transactions
are such actions as authenticating a user, processing a
request for access to a resource, and federating an identity.

If a user requests access to multiple resources, each
request is given a separate transaction ID. When the
Access Gateway evaluates a policy for a protected
resource page and the page contains links, the policy is
evaluated for each link, and each of these evaluations
generates a new transaction ID.

for the ID of the Identity Server, but

file, the value is

idp-

.

System administration transactions are such actions as
importing a device, deleting a device, stopping or starting a
device, and configuring or modifying the configuration of a
device.

Sample Scenario

The following scenario illustrates how these tags can be used. A user receives an error page
indicating that he or she has been refused access to a protected resource. The error page contains an
event code. The user contacts the system administrator and reports the event code contained in the
message. The code displayed to the user includes both an event number and an identifier indicating
the device detecting the error, for example,
event number and

92E1B234

is the device identifier. The device identifier is the number assigned to

300101023-92E1B234

. The

300101023

value is the

the Access Manager device reporting the error. You can make a textual search of log entries using
the tags and values

AM#300101023:

the target Access Manager transaction flow. When the desired log entry is found, the
tag and value and the

AMAUTHID# tag

and

AMDEVICEID#92E1B234:

to locate candidate log entries of

AMEVENTID#

(assuming the user has been authenticated) from the log entry

can be used to locate all other log entries pertaining to the user in the context of the transaction.

4.3.3 Sample Authentication Traces

An authentication trace is logged to the
the user. If the Access Gateway initiates the authentication because of a user request to a protected
resource, the Embedded Service Provider log file of the Access Gateway also contains entries for the

catalina.out

file of the Identity Server that authenticates

82 Novell Access Manager 3.1 SP1 Administration Console Guide

authentication sequence. Identity Server logging must be enabled to produce authentication traces
(see “Configuring Component Logging” in the Novell Access Manager 3.1 SP1 Identity Server

Guide).

This section describes the following types of authentication traces:

 “Direct Authentication Request to the Identity Server” on page 83

 “Protected Resource Authentication Trace” on page 85

Direct Authentication Request to the Identity Server

The following trace is an example of a user logging directly into the Identity Server to access the
End User Portal. The log entries are numbered, so that they can be described.

1. <amLogEntry> 2007-06-14T17:14:30Z INFO NIDS Application: AM#500105015:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
Processing login request with TARGET = http://10.10.15.19:8080/nidp/app, saved
TARGET = . </amLogEntry>

2. <amLogEntry> 2007-06-14T17:14:30Z INFO NIDS Application: AM#500105009:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
Executing contract Name/Password - Form. </amLogEntry>

novdocx (en) 19 February 2010

3. <amLogEntry> 2007-06-14T17:14:30Z INFO NIDS Application: AM#500105010:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
Contract Name/Password - Form requires additional interaction. </amLogEntry>

4. <amLogEntry> 2007-06-14T17:14:39Z INFO NIDS Application: AM#500105015:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
Processing login request with TARGET = http://10.10.15.19:8080/nidp/app, saved
TARGET = http://10.10.15.19:8080/nidp/app. </amLogEntry>

5. <amLogEntry> 2007-06-14T17:14:39Z INFO NIDS Application: AM#500105009:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
Executing contract Name/Password - Form. </amLogEntry>

6. <amLogEntry> 2007-06-14T17:14:39Z INFO NIDS Application: AM#500105014:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
Attempting to authenticate user cn=bcf,o=novell with provided credentials. </
amLogEntry>

7. <amLogEntry> 2007-06-14T17:14:39Z WARNING NIDS Application: Event Id:
3014666, Target: cn=bcf,o=novell, Sub-Target:
F35A3C7AD7F2EEDEB3D17F99EC3F39D1, Note 1: Local, Note 2: This Identity
Provider, Note 3: name/password/uri, Numeric 1: 0 </amLogEntry>

8. <amLogEntry> 2007-06-14T17:14:39Z WARNING NIDS Application: Event Id:
3015456, Note 1: F35A3C7AD7F2EEDEB3D17F99EC3F39D1, Note 2: Manager, Note 3:
Document=(ou=xpemlPEP,ou=mastercdn,ou=Content
PublisherContainer,ou=Partition,ou=PartitionsContainer,ou=VCDN_Root,ou=access
ManagerContainer,o=novell:romaContentCollectionXMLDoc),Policy=(Manager),Rule=
(1::RuleID_1181251958207),Action=(AddRole::ActionID_1181252224665), Numeric
1: 0 </amLogEntry>

9. <amLogEntry> 2007-06-14T17:14:39Z WARNING NIDS Application: Event Id:
3015456, Note 1: F35A3C7AD7F2EEDEB3D17F99EC3F39D1, Note 2: authenticated, Note
3: system-generated-action, Numeric 1: 0 </amLogEntry>

Access Manager Logging 83

10. <amLogEntry> 2007-06-14T17:14:39Z INFO NIDS Application: AM#500199050:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1: IDP
RolesPep.evaluate(), policy trace:
~~RL~1~~~~Rule Count: 1~~Success(67)
~~RU~RuleID_1181251958207~Manager~DNF~~1:1~~Success(67)
~~CS~1~~ANDs~~1~~True(69)
~~CO~1~LdapGroup(6645):no-param:hidden-value:~ldap-group-is-member­of~SelectedLdapGroup(66455):hidden-param:hidden-value:~~~True(69)
~~PA~ActionID_1181252224665~~AddRole~Manager~~~Success(0)
~~PC~ActionID_1181252224665~~Document=(ou=xpemlPEP,ou=mastercdn,
ou=ContentPublisherContainer,ou=Partition,ou=PartitionsContainer,ou=VCDN_Root
,ou=accessManagerContainer,o=novell:romaContentCollectionXMLDoc),Policy=(Mana
ger),Rule=(1::RuleID_1181251958207),Action=(AddRole::ActionID_1181252224665)~
AdditionalRole(6601):unknown():Manager:~~~Success(0)
</amLogEntry>

11. <amLogEntry> 2007-06-14T17:14:39Z INFO NIDS Application: AM#500105013:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
Authenticated user cn=bcf,o=novell in User Store Local Directory with roles
Manager,authenticated. </amLogEntry>

12. <amLogEntry> 2007-06-14T17:14:39Z INFO NIDS Application: AM#500105017:
AMDEVICEID#9921459858EAAC29: AMAUTHID#F35A3C7AD7F2EEDEB3D17F99EC3F39D1:
nLogin succeeded, redirecting to http://10.10.15.19:8080/nidp/app. </
amLogEntry>

novdocx (en) 19 February 2010

Table 4-4 Log Entry Descriptions for an Authentication Trace from an Identity Server

Entry Description

1 Indicates that a login request is in process. This is the first entry for a login request. The

requester, even though login has not been successful, is assigned an authentication ID. You
can use this ID to find the log entries related to this user. The entry also specifies the URL of
the requested resource, in this case the /nidp/app resource called the End User Portal. The
saved TARGET message does not contain a value, so this step will be repeated.

2 Specifies the contract that is being used to perform the login.

3 Indicates that the contract requires interaction with the user.

4 Indicates that the a login request is in process. The saved TARGET message contains a value,

so the required information has been gathered to start the authentication request. The AM#
correlation tag is

5 Indicates that an exchange is occurring between the client and the Identity Server to obtain the

required credentials. Each contract requires a different exchange. The
AM#500105009, which is the same value as the second log entry.

6 Provides the DN of the user attempting the log in and indicates that the user’s credentials are

being sent to the LDAP server for verification.

7 Provides information about an auditing event. If you have not enabled auditing or you have not

selected the login events, this entry does not appear in your log file. This event contains
information about who is logging in and the contract that is being used.

AM#500105015

, which is the same value as the first log entry.

AM#

correlation tag is

8 Provides information about an auditing event. If you have not enabled auditing or you have not

selected the login events, this entry does not appear in your log file. This event contains
information about the Manager policy that is evaluated during login.

84 Novell Access Manager 3.1 SP1 Administration Console Guide

Entry Description

9 Provides information about an auditing event. If you have not enabled auditing or you have not

selected the login events, this entry does not appear in your log file.

10 Contains the entry for processing a Role policy. When a user logs in, all Role policies are

evaluated and the user is assigned any roles that the user has the qualifications for. For more
information, see “Understanding Policy Evaluation Traces” in the Novell Access Manager 3.1

SP1 Policy Management Guide.

11 Contains a summary of who logged in from which user store and the names of the Role

policies that successfully assigned roles to the user.

12 Contains the final results of the login, with the URL that the request is redirected to.

Protected Resource Authentication Trace

When a protected resource is configured to require authentication, both the Identity Server and the
Embedded Service Provider of the Access Gateway (or J2EE Agent) generate log entries for the
process. The following sections explain how to correlate the entries from the logs.

novdocx (en) 19 February 2010

 “Entries from an Identity Server Log” on page 85

 “Entries from an Access Gateway Log” on page 86

 “Correlating the Log Entries between the Identity Server and the Access Gateway” on page 86

Entries from an Identity Server Log

<amLogEntry> 2007-07-31T17:36:39Z INFO NIDS Application: AM#500105016:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Processing login resulting from Service Provider authentication request. </
amLogEntry>

<amLogEntry> 2007-07-31T17:36:39Z INFO NIDS Application: AM#500105009:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Executing contract Name/Password - Form. </amLogEntry>

<amLogEntry> 2007-07-31T17:36:39Z INFO NIDS Application: AM#500105010:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Contract Name/Password - Form requires additional interaction. </amLogEntry>

<amLogEntry> 2007-07-31T17:36:49Z INFO NIDS Application: AM#500105016:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Processing login resulting from Service Provider authentication request. </
amLogEntry>

<amLogEntry> 2007-07-31T17:36:49Z INFO NIDS Application: AM#500105009:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Executing contract Name/Password - Form. </amLogEntry>

<amLogEntry> 2007-07-31T17:36:49Z INFO NIDS Application: AM#500105014:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Attempting to authenticate user cn=admin,o=novell with provided credentials.
</amLogEntry>

<amLogEntry> 2007-07-31T17:36:49Z INFO NIDS Application: AM#500105012:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Authenticated user cn=admin,o=novell in User Store Internal with no roles. </

Access Manager Logging 85

amLogEntry>

<amLogEntry> 2007-07-31T17:36:49Z INFO NIDS Application: AM#500105018:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67:
Responding to AuthnRequest with artifact AAMoz+rm2jQjDSHjea8U9zm3Td/U2ax0YZCo/
qBNool8WkZiTCt7N7Jx </amLogEntry>

<amLogEntry> 2007-07-31T17:36:49Z INFO NIDS Application: AM#500105019:
AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#C2D8D52704918AF2D5D62F6EDC2FFAC6:
Sending AuthnResponse in response to artifact AAMoz+rm2jQjDSHjea8U9zm3Td/
U2ax0YZCo/qBNool8WkZiTCt7N7Jx </amLogEntry>

Entries from an Access Gateway Log

<amLogEntry> 2007-07-31T17:35:05Z INFO NIDS Application: AM#500105005:
AMDEVICEID#esp-2FA73CE1A376FD91: AMAUTHID#C6D119FD93EEBBEBEC50BEB27B9E2832:
Processing proxy request for login using contract name/password/uri and return
url http://jwilson.provo.novell.com/ </amLogEntry>

<amLogEntry> 2007-07-31T17:35:05Z INFO NIDS Application: AM#500105015:
AMDEVICEID#esp-2FA73CE1A376FD91: AMAUTHID#C6D119FD93EEBBEBEC50BEB27B9E2832:
Processing login request with TARGET = http://jwilson.provo.novell.com/, saved
TARGET = . </amLogEntry>

novdocx (en) 19 February 2010

<amLogEntry> 2007-07-31T17:35:05Z INFO NIDS Application: AM#500105009:
AMDEVICEID#esp-2FA73CE1A376FD91: AMAUTHID#C6D119FD93EEBBEBEC50BEB27B9E2832:
Executing contract IDP Select. </amLogEntry>

<amLogEntry> 2007-07-31T17:35:05Z INFO NIDS Application: AM#500105010:
AMDEVICEID#esp-2FA73CE1A376FD91: AMAUTHID#C6D119FD93EEBBEBEC50BEB27B9E2832:
Contract IDP Select requires additional interaction. </amLogEntry>

<amLogEntry> 2007-07-31T17:35:15Z INFO NIDS Application: AM#500105020:
AMDEVICEID#esp-2FA73CE1A376FD91: AMAUTHID#C6D119FD93EEBBEBEC50BEB27B9E2832:
Received and processing artifact from IDP - AAMoz+rm2jQjDSHjea8U9zm3Td/
U2ax0YZCo/qBNool8WkZiTCt7N7Jx </amLogEntry>

<amLogEntry> 2007-07-31T17:35:15Z INFO NIDS Application: AM#500105021:
AMDEVICEID#esp-2FA73CE1A376FD91: AMAUTHID#C6D119FD93EEBBEBEC50BEB27B9E2832:
Sending artifact AAMoz+rm2jQjDSHjea8U9zm3Td/U2ax0YZCo/qBNool8WkZiTCt7N7Jx to
URL http://jwilson1.provo.novell.com:8080/nidp/idff/soap at IDP </amLogEntry>

Correlating the Log Entries between the Identity Server and the Access Gateway

You can see that these two trace sequences are for the same authentication request because the
artifact (

AAMoz+rm2jQjDSHjea8U9zm3Td/U2ax0YZCo/qBNool8WkZiTCt7N7Jx

is the same. You can use the

AMAUTHID

in each file to search for other requests that this user has

) that is exchanged

made.

To associate a distinguished name with the
Server. Event

AM#500105014

contains the DN of the user.

AMAUTHID

, use the

catalina.out

file of the Identity

86 Novell Access Manager 3.1 SP1 Administration Console Guide

5

Changing the IP Address of

novdocx (en) 19 February 2010

Access Manager Devices

The following sections explain how to change the IP address on the following devices:

 Section 5.1, “Changing the IP Address of the Administration Console,” on page 87

 Section 5.2, “Changing the IP Address of an Identity Server,” on page 87

 Section 5.3, “Changing the IP Address of the Access Gateway Appliance,” on page 89

 Section 5.4, “Changing the IP Address of an Audit Server,” on page 90

NOTE: Changing the IP address of an SSL VPN component is not recommended.

5.1 Changing the IP Address of the
Administration Console

We recommend that you install the Administration Console with the IP address that it will always
use because all of the devices that import into the Administration Console use this address to
establish secure communication with the Administration Console.

The only tested method of changing the IP address so that all other devices trust the Administration
Console is to install a secondary console with the new IP address and then promote the secondary
console to be the primary console. Remember to change the IP addresses of all components pointing
to the new Administration Console.

5

See the following sections:

 “Installing Secondary Versions of the Administration Console” in the Novell Access Manager

3.1 SP1 Setup Guide

 “Converting a Secondary Console into a Primary Console” on page 95

Converting a secondary console into a primary console is not a simple task. The task was designed
as a disaster recovery solution when the primary console is no longer available. It is not a simple
configuration change.

5.2 Changing the IP Address of an Identity
Server

These instructions assume that your Identity Server and Administration Console are not on the same
machine. If they are on the same machine, see Section 5.1, “Changing the IP Address of the

Administration Console,” on page 87.

To move a machine or change the IP address for the Identity Server:

1 In the Administration Console, click Devices > Identity Servers.

2 Click the server name.

3 On the General page, click Edit.

Changing the IP Address of Access Manager Devices

87

4 Specify the new IP address in the Management IP Address field and, if necessary, a port.

5 Click OK, then click Close.

6 On the Identity Server, stop the server communication service by using the following

command:

novdocx (en) 19 February 2010

Linux:

Windows:

/etc/init.d/novell-jcc stop

net stop jccserver

7 Change the IP address by using an operating system utility:

Linux: Click YaST > Network Devices > Network Card, select a method, select the card, then
click Edit.

Windows: Click Control Panel > Network Connections > Local Area Connection > Properties
> Internet Protocol (TCP/IP) > Properties.

jcc

8 Change to the

Linux:

/opt/novell/devman/jcc

Windows:

directory:

C:\Program Files\Novell\devman\jcc

9 Run the configure command:

Linux:

Windows:

The command must be run from the

conf/Configure.sh

conf\configure.cmd

conf

directory because it needs access to files that are

available in this directory.

10 When you are prompted for the local listener IP address, enter the new IP.

11 When you are prompted for the administration server IP, enter the IP address of the

Administration Console.

12 Follow the prompts and accept the defaults for ports and admin user.

13 Replace all references to the old IP address in the

server.xml

file with the new IP address.

13a Change to the Tomcat configuration directory:

Linux:

Windows:

13b In a text editor, open the

/var/opt/novell/tomcat5/conf

C:\Program Files\Novell\Tomcat\conf

server.xml

file.

13c Search for the old IP address and replace it with the new IP address.

13d Save your changes.

14 Start the server communication service by using the following command:

Linux:

Windows:

/etc/init.d/novell-jcc start

net start jccserver

15 Restart Tomcat:

Linux: Enter the following command:

/etc/init.d/novell-tomcat5 restart

Windows: Enter the following commands:

net stop Tomcat5

net start Tomcat5

88 Novell Access Manager 3.1 SP1 Administration Console Guide

For information about deleting an Identity Server, see “Maintaining an Identity Server” in the Novell

Access Manager 3.1 SP1 Identity Server Guide.

5.3 Changing the IP Address of the Access
Gateway Appliance

If you need to change the IP address of the Access Gateway machine, you need to configure the
Access Gateway for this change. This is especially significant when the Access Gateway Appliance
has only one IP address.

IMPORTANT: The new IP address must be configured in the Administration Console before you
change it on the Access Gateway. If you change the address on the Access Gateway first, the
Administration Console does not trust the Access Gateway and cannot establish communication.

1 In the Administration Console, click Devices > Access Gateways > Edit > Adapter List.

2 (Conditional) If the machine belongs to a cluster, select the Access Gateway from the Cluster

Member list.

3 From the Adapter List, select the subnet mask that contains the IP address you want to change.

novdocx (en) 19 February 2010

When you select the subnet mask, the Adapter page appears.

4 Select the old IP address, click Change IP Address, specify the new IP address, then click OK.

This option changes all configuration instances of the old IP address to the new IP address. For
example, any reverse proxies that have been assigned the old IP address as a listening address
are modified to use the new IP address as the listening address.

5 To save your changes to browser cache, click OK.

6 To apply your changes, click the Access Gateways link, then click Update > OK.

7 If you are physically moving the machine, move it before completing the rest of these steps.

8 Check the IP address that the Administration Console uses for managing the Access Gateway.

Click Access Gateways > [Name of Access Gateway] > Edit.

Changing the IP Address of Access Manager Devices 89

9 If the old IP address is listed as the Management IP Address, select the new IP address. If your

Access Gateway has multiple IP addresses, select the one that you want the Administration
Console to use for communication with the Access Gateway.

The port should only be modified if there is another device on the Access Gateway that is using
the default port of 1443.

10 If the name of the Access Gateway is the old IP address, modify the Name option.

11 Click OK.

The Administration Console uses the configured IP address to find the Access Gateway.

12 On the Identity Server, restart Tomcat:

Linux: Enter the following command:

/etc/init.d/novell-tomcat5 restart

Windows: Enter the following commands:

net stop Tomcat5

net start Tomcat5

If your Access Gateway stops reporting to the Administration Console after completing these steps,
you need to trigger an auto-import. See “Triggering an Import Retry” in the Novell Access Manager

3.1 SP1 Installation Guide.

novdocx (en) 19 February 2010

5.4 Changing the IP Address of an Audit Server

To move a machine or change the IP address for the audit server:

1 In the Administration Console, click Auditing > Novell Auditing.

2 On the Novell Auditing page, change the IP address for the server and, if necessary, the port.

3 Click OK.

4 Update all Access Gateways.

5 Reboot all servers, including the Access Gateways, to use the new configuration.

90 Novell Access Manager 3.1 SP1 Administration Console Guide

6

Troubleshooting the

novdocx (en) 19 February 2010

Administration Console

This section discusses general troubleshooting issues found in the Administration Console:

 Section 6.1, “Stopping Tomcat on Windows,” on page 91

 Section 6.2, “Checking for Potential Configuration Problems,” on page 91

 Section 6.3, “Logging,” on page 93

 Section 6.4, “Event Codes,” on page 94

 Section 6.5, “Restoring a Failed Secondary Console,” on page 94

 Section 6.6, “Moving the Primary Administration Console to New Hardware,” on page 94

 Section 6.7, “Converting a Secondary Console into a Primary Console,” on page 95

 Section 6.8, “Orphaned Objects in the Trust/Configuration Store,” on page 104

 Section 6.9, “Repairing the Configuration Datastore,” on page 105

 Section 6.10, “Session Conflicts,” on page 105

 Section 6.11, “Unable to Log In to the Administration Console,” on page 105

 Section 6.12, “(Linux) Exception Processing IdentityService_ServerPage.JSP,” on page 106

 Section 6.13, “Backup/Restore Failure Because of Special Characters in Passwords,” on

page 106

6

6.1 Stopping Tomcat on Windows

If you use the Administrative Tools > Services option on Windows to stop Tomcat, Tomcat does not
shut down cleanly and displays an error. To continue, click OK.

The following command sometimes produces an error:

net stop Tomcat5

Whichever method you use to stop Tomcat, Tomcat is stopped. Wait a minute before restarting
Tomcat .

6.2 Checking for Potential Configuration
Problems

If your Access Manager components are not running as you have configured them to run, you might
want to check the system to see if any of the components have configuration or network problems.

1 In the Administration Console, click Auditing > Troubleshooting > Configuration.

2 All of the options should be empty, except the Cached Access Gateway Configurations option

(see Step 4) and the Current Access Gateway Configurations option (see Step 6). If an option
contains an entry, you need to clear it. Select the appropriate action from the following table:

Troubleshooting the Administration Console

91

Option Description and Action

Device Pending with No Commands If you have a device that remains in the pending state, even

when all commands have successfully executed, that device
appears in this list. Before deleting the device from this list,
check its Command Status. If the device has any commands
listed, select them, then delete them. Wait a few minutes. If
the device remains in a pending state, return to this
troubleshooting page. Find the device in the list, then click
Remove. The Administration Console clears the pending
state.

novdocx (en) 19 February 2010

Other Known Device Manager
Servers

Access Gateways with Incomplete
Proxy Configuration

Access Gateways with Corrupt
Protected Resource Data

If a Secondary Administration Console is in a non-reporting
state, perhaps caused by hardware failure, its configuration
needs to be removed from the primary Administration
Console. As long as it is part of the configuration, other
Access Manager devices try to contact it. If you cannot
remove it by running the uninstall script on the Secondary
Administration Console, you can remove it by using this
troubleshooting page. Click the Remove button next to the
console that is in the non-reporting state. All references to the
Secondary Administration Console are removed from the
configuration database.

If you start to configure a reverse proxy, but you fail to
complete the process by configuring a proxy service and
selecting an IP address and port, the file used to update the
Access Gateway contains an invalid configuration. You can
return to the Access Gateway, and either delete the partial
configuration or complete it. These actions create a valid
configuration that can then be used to update the server. Or,
click the Remove button next to the proxy that has an
incomplete configuration. This removes the invalid reverse
proxy configuration.

If you modify the configuration for a protected resource,
update the Access Gateway with the changes, then review
the configuration for the protected resource and the changes
have not been applied, the configuration for the protected
resource is corrupted. Click the Repair button next to the
protected resource that has a corrupted configuration. You
should then be able to modify its configuration, and when you
update the Access Gateway, the changes should be applied
and saved.

Access Gateways with Duplicate
Protected Resource Data

92 Novell Access Manager 3.1 SP1 Administration Console Guide

After an upgrade, if you get errors related to invalid content
for policy enforcement lists, you need to correct them. The
invalid elements that do not have an associated resource
data element are listed in this section. Click the Repair button
to remove them.

Option Description and Action

novdocx (en) 19 February 2010

Access Gateways with Protected
Resources Referencing Nonexistent
Policies

Access Gateways with Invalid Alert
Profile References

Devices with Corrupt Data Store
Entries

Protected resources have problems when policies are
deleted before their references to the protected resources
are removed. If you have protected resources in this
condition, they are listed in this section. Click the Repair
button to remove these references. Then verify that your
protected resources have the correct policies enabled. Click

Access Gateways > Edit > [Name of Reverse Proxy] > [Name
of Proxy Service] > Protected Resources, then change to the
Policy View.

You can create XML validation errors on your Linux Access
Gateway if you start to create an alert profile (click Access
Gateways > Edit > Alerts > New), but you do not finish the
process. The incomplete alert profile does not appear in the
configuration for the Access Gateway, so you cannot delete
it. If such a profile exists, it appears in the Access Gateways
with Invalid Alert Profile References list. Click the Remove
button by the invalid profile. You should then be able to
modify its configuration, and when you update the Access
Gateway, the changes should be applied and saved.

If an empty value is written to an XML attribute, the device
with this invalid configuration appears in this list.

Click the Repair button to rewrite the invalid attribute values.

3 When you have finished repairing or deleting invalid Access Gateway configurations, click the

Access Gateways link, then click Update > OK.

4 (Optional) To verify that all members of an Access Gateway cluster have the same

configuration in cache, click Auditing > Troubleshooting > Configuration.

5 Scroll to the Cached Access Gateway Configuration option, then click View next to the cluster

configuration or next to an individual Access Gateway.

This option allows you to view the Access Gateway configuration that is currently residing in
browser cache. If the Access Gateway belongs to a cluster, you can view the cached
configuration for the cluster as well as the cached configuration for each member. The + and ­buttons allow you to expand and collapse individual configurations. The configuration is
displayed in XML format

To search for particular configuration parameters, you need to copy and paste the text into a
text editor.

6 (Conditional) After viewing the Access Gateway configuration (see Step 5) and discovering

that an Access Gateway does not have the current configuration, select the Access Gateway in
the Current Access Gateway Configurations section, then click Re-push Current
Configuration.

6.3 Logging

You can troubleshoot by configuring component logging. In the Administration Console, click
Devices > Identity Server > Edit > Logging.

See “Configuring Component Logging” in the Novell Access Manager 3.1 SP1 Identity Server

Guide.

Troubleshooting the Administration Console 93

6.4 Event Codes

A description of the Access Manager event codes is available on the Access Manager

documentation site (http://www.novell.com/documentation/novellaccessmanager/index.html).

Scroll to the bottom of page.

6.5 Restoring a Failed Secondary Console

If a secondary console fails, you need to remove its configuration from the primary console before
installing a new secondary console. As long as the fail console is part of the configuration, other
Access Manager devices try to contact it.

1 On the primary console, click Auditing > Troubleshooting.

2 In the Other Known Device Manager Servers section, click the Remove button next to the

secondary console that has failed.

3 Remove traces of the secondary console from the configuration datastore:

3a In the iManager menu bar, select View O bject s.

novdocx (en) 19 February 2010

3b In the Tree view, select novell, and view the objects.

3c Delete all objects that reference the failed secondary console.

You should find the following types of objects:

 SAS Service object with the hostname of the secondary console

 An object that starts with the last octet of the IP address of the secondary console

 DNS AG object with the hostname of the secondary console

 DNS IP object with the hostname of the secondary console

 SSL CertificateDNS with the hostname of the secondary console

 SSL CertificateIP with the hostname of the secondary console

4 Install a new secondary console. For installation instructions, see “Installing Secondary

Versions of the Administration Console” in the Novell Access Manager 3.1 SP1 Setup Guide.

6.6 Moving the Primary Administration Console
to New Hardware

If you do not have any secondary consoles:

1 Perform a backup. For instructions, see Section 2.2, “Backing Up the Administration Console,”

on page 32.

94 Novell Access Manager 3.1 SP1 Administration Console Guide

2 Install the Administration Console on the new hardware, using the same DNS name and IP

address.

3 Restore the configuration. For instructions, see Section 2.3, “Restoring an Administration

Console Configuration,” on page 33.

If you have secondary consoles, you need to re-create the replica ring. When you install secondary
consoles, they are added to the replica ring of the configuration datastore. The Access Manager
backup script does not back up the replica ring information. It backs up only the Access Manager
configuration information. The following instructions explain how you can re-create the replica ring
when you install the primary Administration Console on new hardware.

1 Perform a backup. For instructions, see Section 2.2, “Backing Up the Administration Console,”

on page 32.

2 Down any secondary consoles.

3 Install the Administration Console on the new hardware, using the same DNS name and IP

address.

4 Restore the configuration. For instructions, see Section 2.3, “Restoring an Administration

Console Configuration,” on page 33.

5 Remove any secondary consoles from the configuration:

novdocx (en) 19 February 2010

5a In the Administration Console, click Auditing > Troubleshooting.

5b In the Other Known Device Manager Servers section, use the Remove button to remove

any secondary consoles.

6 Uninstall the secondary consoles. For instructions, see “Uninstalling the Administration

Console” in the Novell Access Manager 3.1 SP1 Installation Guide.

7 Reinstall the secondary consoles as secondary consoles to the new primary console.

6.7 Converting a Secondary Console into a
Primary Console

In order for a Secondary Administration Console to be converted into a primary Administration
Console, a recent backup of the Administration Console must be available. For information on how
to perform a backup, see Section 2.2, “Backing Up the Administration Console,” on page 32. A
backup is necessary in order to restore the certificate authority (CA).

If the failed server holds a master replica of any partition, you must use
new master replica on a different server in the replica list.

WARNING: Perform these steps only if the primary Administration Console cannot be restored.

This conversion includes the following tasks:

ndsrepair

to designate a

 Section 6.7.1, “Shutting Down the Administration Console,” on page 96

 Section 6.7.2, “Changing the Master Replica,” on page 96

 Section 6.7.3, “Restoring CA Certificates,” on page 97

 Section 6.7.4, “Deleting Objects from the eDirectory Configuration Store,” on page 97

 Section 6.7.5, “Performing Component-Specific Procedures,” on page 98

 Section 6.7.6, “Enabling Backup on the New Primary Administration Console,” on page 103

Troubleshooting the Administration Console 95

6.7.1 Shutting Down the Administration Console

If your primary Administration Console is running, you must log in as the administrator and shut
down the service.

 Linux: Start YaST, click System > System Services (Runlevel), then select to stop the ndsd

service.

 Windows: Open the Control Panel, click Administrative Tools > Services, then select to stop

the NDS Server.

6.7.2 Changing the Master Replica

Changing the master replica to reside on the new primary Administration Console makes the this
Administration Console into the certificate authority for Access Manager. You need to first
designate the replica on the new primary Administration Console as the master replica. Then you
need to remove the old primary Administration Console from the replica ring.

 “Linux Secondary Administration Console” on page 96

 “Windows Secondary Administration Console” on page 96

novdocx (en) 19 February 2010

Linux Secondary Administration Console

1 At the secondary Administration Console, log in as root.

2 Change to the

/opt/novell/eDirectory/bin

directory.

3 Run DSRepair with the following options:

./ndsrepair -P -Ad

4 Select the one available replica.

5 Select Designate this server as the new master replica.

6 Run

ndsrepair -P -Ad

again.

7 Select the one available replica.

8 Select View replica ring.

9 Select the name of the failed primary server.

10 Select Remove this server from replica ring.

11 Enter the DN of the admin user in leading dot notation. For example:

.admin.novell

12 Continue with Section 6.7.3, “Restoring CA Certificates,” on page 97.

Windows Secondary Administration Console

1 At the secondary Administration Console, log in as the administrator.

2 Change to the

3 Start the

4 Select

dsrepair.dlm

C:\Novell\NDS

NDSCons.exe

5 In the Parameters box, specify -A, then click Start

6 Click Partitions > Root > Designate This Server As The New Master Replica.

96 Novell Access Manager 3.1 SP1 Administration Console Guide

directory.

program.

.

7 Open Partitions > Root, select the server, and verify that the replica is the master replica.

novdocx (en) 19 February 2010

8 Run

ndsrepair

again with -A in the Parameters box.

9 Click Partitions > Root, then select the name of the failed primary server.

10 From the menu, click Partitions > Replica Rings > Remove Server From Ring.

11 Enter the DN of the admin user in leading dot notation. For example:

.admin.novell

12 Continue with Section 6.7.3, “Restoring CA Certificates,” on page 97.

6.7.3 Restoring CA Certificates

The following steps are performed on the machine that you are promoting to be a primary console.

1 Copy your most recent Administration Console backup files to your new primary

Administration Console.

2 Change to the backup

Linux:

Windows:

/opt/novell/devman/bin

C:\Program Files\Novell\bin

3 Edit the backup properties file.

3a Open the file that on Linux is a script file, and on Windows is a properties file:

Linux:

defbkparm.sh

Windows:

bin

directory:

defbkparm.properties

3b Change the IP_Address parameter from the IP address of the failed primary console to the

IP address of the secondary console.

3c Save the file

4 Run the certificate restore script:

Linux:

Windows:

sh aminst-certs.sh

aminst-certs.bat

5 When prompted, enter the location of the backup files.

6 Continue with Section 6.7.4, “Deleting Objects from the eDirectory Configuration Store,” on

page 97.

6.7.4 Deleting Objects from the eDirectory Configuration Store

Several objects representing the failed primary Administration Console in the configuration store
must be deleted.

1 Log in to the new Administration Console, then click Auditing > Troubleshooting.

2 In the Other Known Device Manager Servers section, select the old primary Administration

Console, then click Remove.

Troubleshooting the Administration Console 97

6.7.5 Performing Component-Specific Procedures

If you have installed the following components, perform the cleanup steps for the component:

 “Third Administration Console” on page 98

 “Linux Access Gateways” on page 98

 “Linux Identity Server” on page 100

 “Windows Identity Server” on page 101

 “Linux J2EE Agents” on page 101

 “Windows J2EE Agents” on page 101

 “SSL VPN” on page 102

 “Old Primary Administration Console” on page 103

Third Administration Console

If you installed a third Administration Console used for failover, you must manually perform the
following steps on that server:

novdocx (en) 19 February 2010

1 Open the

Linux:

Windows:

vcdn.conf

/opt/novell/devman/share/conf

C:\Program Files\Novell\Tomcat\webapps\roma\WEB-INF\conf

file.

2 In the file, look for the line that is similar to the following:

<vcdnPrimaryAddress>10.1.1.1</vcdnPrimaryAddress>

In this line, 10.1.1.1 represents the failed primary Administration Console IP address.

3 Change this IP address to the IP address of the new primary Administration Console.

4 Restart the Administration Console by entering the following command from the command

line interface:

Linux:

Windows:

Then,

/etc/init.d/novell-tomcat5 restart

net stop Tomcat5

net start Tomcat5

Linux Access Gateways

For each Linux Access Gateway imported into the Administration Console, you must edit the

config.xml

file and the

settings.properties

file on the Access Gateway and edit the current
config and working config XML documents in the configuration store on the new primary
Administration Console.

root

1 At the Linux Access Gateway, log in as the

user.

2 Open a terminal window and shut down all services by entering the following commands:

/etc/init.d/novell-jcc stop
/etc/init.d/novell-tomcat5 stop
/etc/init.d/novell-vmc stop

3 If you are running SSL VPN, enter the following command to stop SSL VPN:

/etc/init.d/novell-sslvpn stop

98 Novell Access Manager 3.1 SP1 Administration Console Guide

novdocx (en) 19 February 2010

4 Edit the

vi /var/novell/cfgdb/.current/config.xml

4a Enter

config.xml

/Remote

In the

IPv4Address

file by entering

, then press Enter.

field, change the IP address from the failed Administration Console

to the new primary Administration Console address.

4b (Conditional) If your audit server was on the primary Administration Console, enter

/NsureAuditSetting

In the

IPv4Address

, then press Enter.

field, change the IP address from the failed Administration Console

to the new primary Administration Console address.

:wq!

4c Enter

5 Edit the

vi /opt/novell/devman/jcc/conf/settings.properties

settings.properties

5a Change the IP address in the

to save and exit.

file by entering

remotemgmtip

list from the IP address of the failed

Administration Console to the address of the new primary Administration Console.

5b Enter

:wq!

to save and exit.

6 At the new primary Administration Console, open an LDAP browser and edit the

CurrentConfig object of the Linux Access Gateway.

IMPORTANT: You should use an LDAP browser for the following steps, rather than
iManager. iManager is slow at saving large files, and your iManager connection might time out
before your modifications are saved.

6a Browse to the following container: novell > accessManagerContainer > VCDN_Root >

PartitionsContainer > Partition > AppliancesContainer.

A list of devices appears. Access Gateways have an ag prefix.

6b Expand an Access Gateway container, then select the CurrentConfig object.

6c Select the romaAGConfigurationXMLDoc attribute and open it so you can view its value.

The value is a large XML file.

6d Copy the contents of the attribute to a text editor.

6e (Conditional) To verify which Linux Access Gateway you are changing, search for the

<Local>

element.

The IP address should match the IP address of the Linux Access Gateway that you are
configuring for the new primary Administration Console.

6f Search for the

6g Change the IP address of the

<Remote>

element.

<Remote>

element so that it matches the IP address of the

new primary Administration Console.

6h (Conditional) If your audit server was on the primary Administration Console, search for

the

<NsureAuditSetting>

Change the IP address of the

element.

<NsureAuditSetting>

element so that it matches the IP

address of the new primary Administration Console.

6i Copy the modified document in the text editor to the value field of the

romaAGConfigurationXMLDoc attribute.

6j Save your changes.

Troubleshooting the Administration Console 99

7 At the new primary Administration Console, edit the WorkingConfig object of the Linux

Access Gateway:

Use an LDAP browser for these steps.

7a Browse to the following container: novell > accessManagerContainer > VCDN_Root >

PartitionsContainer > Partition > AppliancesContainer.

A list of devices appears. Expand the Access Gateway container.

7b Select the WorkingConfig object.

7c Select the romaAGConfigurationXMLDoc attribute and open it so you can view its value.

7d Copy the contents of the attribute to a text editor.

novdocx (en) 19 February 2010

7e Search for the

7f Change the IP address of the

<Remote>

element.

<Remote>

element so that it matches the IP address of the

new primary Administration Console.

7g (Conditional) If your audit server was on the primary Administration Console, search for

<NsureAuditSetting>

the

Change the IP address of the

element.

<NsureAuditSetting>

element so that it matches the IP

address of the new primary Administration Console.

7h Copy the modified document in the text editor to the value field of the

romaAGConfigurationXMLDoc attribute.

7i Save your changes.

8 At the Linux Access Gateway, start all services by entering the following commands:

/etc/init.d/novell-jcc start
/etc/init.d/novell-tomcat5 start
/etc/init.d/novell-vmc start
/etc/init.d/novell-sslvpn start

9 (Conditional) Repeat this process for each Linux Access Gateway that has been imported into

the Administration Console.

Linux Identity Server

For each Linux Identity Server imported into the Administration Console, perform the following
steps:

root

1 Log in as the

user.

2 Open a terminal window and shut down all services by entering the following commands:

/etc/init.d/novell-jcc stop
/etc/init.d/novell-tomcat5 stop

3 Edit the

vi /opt/novell/devman/jcc/conf/settings.properties

settings.properties

4 Change the IP address in the

Administration Console to the address of the new primary Administration Console.

5 Enter

:wq!

to save and exit.

6 Start the services by entering the following commands:

/etc/init.d/novell-jcc start
/etc/init.d/novell-tomcat5 start

100 Novell Access Manager 3.1 SP1 Administration Console Guide

file by entering

remotemgmtip

list from the IP address of the failed