Installation and Upgrade Guide: Access Manager Appliance 4.4
Installation and Upgrade Guide: Access Manager Appliance 4.4
Installation and Upgrade Guide: Access Manager Appliance 4.4
For information about NetIQ trademarks, see https://www.netiq.com/company/legal/. All third-party trademarks are the
property of their respective owners.
Contents
Contents 3
Part II Upgrading Access Manager Appliance 51
4 Prerequisites 53
4.1 Maintaining Customized JSP Files for Identity Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.1 Using Customized JSP Pages from Access Manager 4.1 or Prior . . . . . . . . . . . . . . . . . . . 54
4.1.2 Using Customized JSP Pages from Access Manager 4.1 or Prior and Enabling the
New Access Manager Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Maintaining Customized JSP Files for Access Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8 Troubleshooting Installation 71
8.1 Checking the Installation Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.2 Some of the New Hardware Drivers or Network Cards Are Not Detected during Installation . . . . . . 72
8.3 Installation Through Terminal Mode Is Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.4 Device Manager Installation Fails During the Appliance Installation . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.5 Access Manager Appliance Installation Fails Due to an XML Parser Error . . . . . . . . . . . . . . . . . . . . 72
8.6 DN Is Added as Provider ID While Installing the NMAS SAML Method . . . . . . . . . . . . . . . . . . . . . . . 73
8.7 Secondary Access Manager Appliance Installation Fails during Cluster Portion Configuration . . . . . 73
8.8 (RHEL 7.4) Running the sudo Command Gives Fatal Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9 Troubleshooting Upgrade 75
9.1 Access Gateway Throws a 403 Forbidden Page Error for a Resource Protected by a Form
Fill Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.2 Issue in SSL Communication between Access Gateway and Web Applications . . . . . . . . . . . . . . . . 75
9.3 Administration Console Upgrade Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.4 Customized Login Pages Are Missing After Upgrading Access Manager . . . . . . . . . . . . . . . . . . . . . 76
9.5 The Email OTP JSP Page Does Not Render Properly on Internet Explorer 11 . . . . . . . . . . . . . . . . . 76
9.6 Access Manager Upgrade Hangs While Upgrading eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4 Contents
Part IV Appendix 79
Contents 5
6
About this Book and the Library
The Installation and Upgrade Guide provides an introduction to NetIQ Access Manager Appliance
and describes the installation and upgrade procedures.
Intended Audience
This book is intended for Access Manager administrators. It is assumed that you have knowledge of
evolving Internet protocols, such as:
NOTE: Contact [email protected] for any query related to Access Manager SDK.
We are a global, enterprise software company, with a focus on the three persistent challenges in your
environment: Change, complexity and risk—and how we can help you control them.
Our Viewpoint
Adapting to change and managing complexity and risk are nothing new
In fact, of all the challenges you face, these are perhaps the most prominent variables that deny
you the control you need to securely measure, monitor, and manage your physical, virtual, and
cloud computing environments.
Our Philosophy
Selling intelligent solutions, not just software
In order to provide reliable control, we first make sure we understand the real-world scenarios in
which IT organizations like yours operate — day in and day out. That's the only way we can
develop practical, intelligent IT solutions that successfully yield proven, measurable results. And
that's so much more rewarding than simply selling software.
Our Solutions
Identity & Access Governance
Access Management
Security Management
Systems & Application Management
Workload Management
Service Management
Worldwide: www.netiq.com/about_netiq/officelocations.asp
Email: [email protected]
Website: www.netiq.com
Email: [email protected]
Website: www.netiq.com/support
Environment
Some of the key differentiators that Access Manager Appliance offers over Access Manager are:
For details about these differentiators and other features of Access Manager Appliance, see
Section 1.2, “Access Manager Versus Access Manager Appliance,” on page 13.
LDAP
DMZ User Stores Analytics Server
Firewall 1 Firewall 2
Clustered Identity Servers
L4 Switch
Web Servers
Linux, Mac, or
Windows Administration
Consoles
Clustered
Access Gateways
DMZ
Firewall Firewall
LDAP Analytics
Server Server
Browsers
Administration
Console
L4 Switch
Access Browser for
Internet Administration
Manager
Clients
Appliance
Web Servers
The following table provides details to help you determine which solution fits your business:
Virtualization Supported on the virtual servers based on Supported on the virtual servers based on
Support SUSE Linux Enterprise Server (SLES) 11 SLES 11 SP4 or SLES 12 SP3 with 64-bit
SP4 with 64-bit operating system x86-64 operating system x86-64 hardware.
hardware.
Host A soft appliance that includes a pre-installed Operating System choice is more flexible.
Operating and configured SUSE Linux operating Install Administration Console, Identity
System system. Server, and Access Gateway on a supported
operating system (SUSE, Red Hat, or
NetIQ maintains both the operating system Windows).
and Access Manager patches through the
patch update channel. The patch update channel maintains the
patches for Access Manager.
Component Access Manager components such as Each Access Manager component such as
Installation Administration Console, Identity Server, and Administration Console, Identity Server, and
Flexibility Access Gateway cannot be selectively Access Gateway are installed on
installed or uninstalled. independent host servers.
Scalability and Scales vertically on adding CPU and Scales both vertically and horizontally on
Performance memory resources to each node. adding nodes.
For more information, see Performance and For more information, see Performance and
Sizing Guidelines. Sizing Guidelines.
Upgrade You can upgrade from one version of You can upgrade from one version of Access
Access Manager Appliance to another Manager to another version.
version.
However, upgrading from Access Manager
However, upgrading from Access Manager Appliance to Access Manager is not
to Access Manager Appliance is not supported.
supported.
Disaster You can use the backup and restore process You can use the backup and restore process
Recovery to save your Access Manager Appliance to save your Access Manager configuration.
configuration.
Time to Value Automates several configuration steps to Requires more time to install and configure
quickly set up the system. as the components are on different servers.
User Input Access Manager Appliance is a software More flexibility during installation in terms of
required appliance that takes only a few basic selectable parameters.
during parameters as input. Several options
installation assume default values.
Installation The installer takes care of configuration for Separate installation and configuration
and each component. The system is ready for phases for each component.
Configuration use after it is installed.
Phases After installation, each Access Manager
component is separately configured.
Mode of Access Manager Appliance is released as a Access Manager is delivered in the form of
release software appliance. multiple operating system- specific binaries.
NIC Bonding IP address configuration is done through NIC bonding can be done through the
Administration Console. So, NIC bonding is operating system and Access Manager in
not supported. turn uses this configuration.
Networking: Administration Console and Identity Server Multiple ports need to be opened for
Port Details are accelerated and protected by Access deployment.
Gateways. Only HTTPS port 443 is required
to access Access Manager Appliance
through a firewall.
Certificate Certificate management is simplified. All Changes are required at multiple places to
Management certificates and key stores are stored at one replace or renew certificates.
place making replacing or renewing
certificates easier.
SAML Same certificate is used for all As there are multiple key stores, you can
Assertion communication. (signing, encryption, and configure different certificates for the
Signing transport). communication.
Updating Supports installation of latest SLES You are fully responsible for all operating
Kernel with operating system security patches. system maintenance including patching.
Security
Patches
Clustering For additional capacity and for failover, For additional capacity and for failover,
cluster a group of NetIQ Access Manager cluster a group of Identity Servers and
Appliances and configure them to act as a configure them to act as a single server. You
single server. can create a cluster of Access Gateways
and configure them to act as a single server.
You can cluster any number of Identity Fault tolerance can be achieved by installing
Servers and Access Gateways, and up to up to two secondary consoles.
three of Administration Consoles. The first
three nodes of Access Manager Appliance To deploy the existing solution in a cluster
contain Administration Console, Identity mode, at least 6 systems are required.
Server, and Access Gateway. Fourth
installation onwards, the node has all A typical Access Manager deployment in a
components except for Administration cluster is described in Figure 1-4 on
Console. page 17.
Can be clustered.
Cannot be clustered
Identity
Server 1
Access
Gateway 1
Identity
Server 2
Access
Primary Gateway 2
Console
Secondary
Console 1
Secondary
Console 2 Access
Gateway 3
Identity
Server 3
Access
Gateway 4
Identity
Server 4
Can be clustered.
General Guidelines
It is not possible to add an Access Gateway Service or Access Gateway Appliance to an Access
Manager Appliance cluster.
Deploying Administration Console in a DMZ network limits access from a private interface or
network.
It is recommended to not change the primary IP Address of Access Manager. This may result in
corruption of the configuration store. However, you can modify the listening IP address of
reverse proxy or the outbound IP address used to communicate with the web server. For more
information, see Changing the IP Address of Access Manager Appliance in the NetIQ Access
Manager Appliance 4.4 Administration Guide.
You cannot have different certificates for signing and encryption in a federation setup.
You are interested in deploying Access Manager, but need fewer servers.
You are still on iChain because you prefer a single-server solution.
You are new to Access Manager and are interested in providing secure access, but want to
avoid the long process of designing, installing, and configuring a full-fledged web access
management solution.
You do not have a web access management or federation solution and you are considering
moving to a web access management solution.
You represent a division of a large organization (for example, the Marketing division) that wants
secure single sign-on access to a SaaS application such as Salesforce.
You want to reduce server hardware and management cost by consolidating Access Manager
services on fewer servers.
You want to quickly set up a test environment to verify changes.
You want to quickly setup and evaluate Access Manager.
An LDAP directory (eDirectory, Sun ONE, Active Directory, or Azure Active Directory) that
contains your system users. Identity Server uses the LDAP directory to authenticate users to the
system.
NOTE: Azure Active Directory is supported when Access Manager is deployed on Microsoft
Azure.
Web servers with content or applications that need protection and single-sign on.
A domain name server, which resolves DNS names to IP addresses and which has reverse
lookups enabled.
Access Manager Appliance know each other by their IP addresses, and some requests require
them to match an IP address with the device's DNS name. Without reverse lookups enabled,
these requests fail. In particular, Identity Servers perform reverse lookups to their user stores. If
reverse lookups are not available, host table entries can be used.
Time must be synchronized to within one minute among all components of the configuration
using NTP or similar solution.
IMPORTANT: If time is not synchronized, users cannot authenticate and access resources.
(OPTIONAL) An L4 switch or similar solution if you are planning to configure load balancing.
Clients with an Internet browser.
For accessing User Portal and Administration Console, users can login using the following browsers:
Chrome 60.0.3112.101
Firefox 54.0.1
Internet Explorer 11.0.9600.18738 Update Versions 11.0.44 (KB4025252)
Edge 38.14393.0.0/ EdgeHTML 14.14393
Firewall
Analytics Server
LDAP
Server
Browsers
Router
Administration
Console
Web Servers
For more information, see Section 2.2.2, “Installing Access Manager Appliance,” on page 30.
The firewall protects the LDAP server, which contains a permanent store of sensitive data. The Web
servers are also installed behind the firewall for added protection. This is a tested and recommended
configuration. We have also tested this configuration with an L4 switch in place of the router so that
the configuration can support clusters of Access Manager Appliance.
DMZ
Firewall Firewall
LDAP Analytics
Server Server
Browsers
Administration
Console
L4 Switch
Access Browser for
Internet Administration
Manager
Clients
Appliance
Web Servers
The first firewall separates Access Manager Appliance from the Internet, allowing browsers to access
the resources through specific ports.The second firewall separates Access Manager Appliance from
web servers they are protecting.
NTP Server UDP 123 Access Manager Appliance must have time synchronized else the
authentication fails. Configure Access Manager Appliance to use
an NTP (network time protocol) server. Depending on where your
NTP server is located in relationship to your firewalls, you might
need to open UDP 123.
DNS Servers UDP 53 Access Manager Appliance must be able to resolve DNS names.
Depending upon where your DNS servers are located, you might
need to open UDP 53 so that Access Manager Appliance can
resolve DNS names.
Remote Linux TCP 22 To use SSH for remote administration of Access Manager
Administration Appliance.
Workstation
Access Manager TCP 1443 For communication from Administration Console to devices.
Appliance
TCP 8444 For communication from devices to Administration Console.
TCP 524 For NCP certificate management with NPKI. The port needs to be
opened so that both the device and Administration Console can
use the port.
LDAP User Store TCP 524 Required only if the user store is eDirectory. When configuring a
new eDirectory user store, NCP is used to enable Novell
SecretStore by adding a SAML authentication method and storing
a public key for Administration Console. It is not used in day-to-day
operations.
TCP 8028, To use iMonitor or DSTrace from a client to view information about
8030 the configuration store on Administration Console.
TCP 80 For HTTP communication from the client to Access Gateway. This
is configurable.
TCP 443 For HTTPS communication from the client to Access Gateway.
This is configurable.
Web Servers TCP 80 For HTTP communication from Access Gateway to web servers.
This is configurable.
TCP 443 For HTTPS communication from Access Gateway to web servers.
This is configurable.
NOTE: On SLES 11 SP4, you can edit this file or use YaST to configure UDP ports and internal
networks.
Control Center TCP 10013 For communicating from a computer to the control
center on Analytics Server.
High availability configuration TCP 7360 For communication between the servers in an
Analytics Server cluster.
22
111
524
1443
2443
3443
8028
8030
8080
8443
8444
9000
9001
55982
61222
61613
61616
61617
First Firewall
If you place a firewall between browsers and Access Manager Appliance, you need to open ports so
that browsers can communicate with Access Gateway and Identity Server and Identity Server can
communicate with other identity providers.
Port Purpose
TCP 8445 For HTTP Identity Provider introductions. If you do not enable Identity Provider
introductions, you do not need to open this port.
TCP 8446 For HTTPS Identity Provider introductions. If you do not enable Identity Provider
introductions, you do not need to open this port.
Second Firewall
The second firewall separates web servers, LDAP servers, and Administration Console from Identity
Server and Access Gateway. You need the following ports opened in the second firewall:
Port Purpose
TCP 1290 For communication from the devices to the Syslog server installed on Administration
Console. If you do not enable auditing, you do not need to open this port.
TCP 524 For NCP certificate management in NPKI. The port needs to be opened so that both the
device and Administration Console can use the port.
You need to open ports on the second firewall according to the offered services.
test-signing
test-encryption
test-connector
test-provider
test-consumer
test-stunnel
For strong security, it is recommended that you replace these certificates, except the test-stunnel
certificate, with certificates from a well-known certificate authority.
For more information, see “Strengthening Certificates ” in the NetIQ Access Manager Appliance 4.4
Security Guide.
Appliance
This chapter explains how to install Access Manager Appliance. Topics include:
Access Manager Appliance installer installs all components on a single server, so software and
hardware requirements are same for all components. Section 1.2, “Access Manager Versus Access
Manager Appliance,” on page 13 lists differences between previously shipped Access Manager
versus Access Manager Appliance.
Access Manager Appliance is based on the SUSE Linux Enterprise Server (SLES) 11 SP4 64-bit
operating system. The hard disk, RAM, and CPU requirements are same for all components.
For network requirements, see Section 1.3, “Network Requirements,” on page 18.
8 GB RAM
Dual CPU or core (3.0 GHz or comparable chip)
100 GB hard disk
The hard disk should have ample space for logging in a production environment. This disk space
must be local and not remote.
2 to10 GB per reverse proxy that requires caching and for log files. The amount varies with the
rollover options and logging level that you configure.
The static IP address and an assigned DNS name (hostname and domain name) for your
Access Manager Appliance.
For the hard disk, RAM, and CPU requirements, each virtual machine must meet the following
minimum requirements:
You can install Access Manager on virtual machines that support an operating system supported by
your Access Manager version and component. For example, SLES 11 SP4 with 64-bit operating
system x86-64 hardware.
NOTE: SLES 11 SP4 64-bit Access Manager Appliance does not support XEN paravirtualization.
SLES 11 SP4 64-bit does not support the ntpdate command. You can use the sntp command. Add
the following command to the /etc/crontab file of the device:
The configured CPUs must match the hardware CPUs on the machine. Performance is drastically
reduced if you allocate more virtual CPUs than actually exist on the machine.
Another potential bottleneck is IO. For best performance, each virtual machine should have its own
hard disk, or you need a SAN that is capable of handling the IO traffic.
For example, if you have one 16-CPU machine, you get better performance when you configure the
machine to have four Access Gateways with 4 assigned CPUs than you get when you configure the
machine to have eight Access Gateways with 2 assigned CPUs. If the machines are dedicated to
Access Manager Appliance components, you get better performance from two 8-CPU machines than
you get from one 16-CPU machine.The setup depends on your unique environment and hardware
and virtualization configuration for your cluster.
A server configured with an LDAP directory (eDirectory, Sun ONE, or Active Directory) that
contains your system users. Administration uses the LDAP directory to authenticate users to the
system.
Web servers with content or applications that need protection.
Clients with an Internet browser.
Static IP addresses for each Access Manager Appliance. If the IP address of the machine
changes, Access Manager Appliance components cannot start.
Domain name server, which resolves DNS names to IP addresses and that has reverse lookups
enabled.
Access Manager Appliance components know each other by their IP addresses. Some requests
require them to match an IP address with the device's DNS name. Without reverse lookups
enabled, these requests fail. In particular, Identity Servers perform reverse lookups to their user
stores. If the reverse lookups are not available, host table entries can be used.
Network time protocol (NTP) server provides accurate time to the machines on your network.
Time must be synchronized within one minute among the components, or the security features of
the product disrupt the communication processes. You can install your own or use a publicly
available server such as pool.ntp.org.
IMPORTANT: If time is not synchronized, users cannot authenticate and access resources.
Access Manager Appliance can be installed on all supported hardware platforms for SLES 11 SP4
(64-bit).
2.2.1 Prerequisites
Ensure that you have backed up all data and software on the disk to another machine. Access
Manager Appliance installation completely erases all the data on your hard disk.
Ensure that the machine meets the minimum hardware requirements. See Section 2.1, “System
Requirements,” on page 27.
(Optional) If you want to try any advanced installation options such as driver installation or
network installation, see the Deployment Guide (http://www.suse.com/documentation/sles11/
book_sle_deployment/data/book_sle_deployment.html).
boot: The size is automatically calculated and the mount point is /boot.
swap: The size is double the size of the RAM and the mount point is swap.
The remaining disk space after the creation of the /boot and swap partitions is allocated as the
extended drive. The extended drive has the following partitions:
root: The default size is approximately one-third the size of the extended drive and the mount
point is /.
var: The default size is approximately one-third the size of the extended drive and the mount
point is /var.
Access Manager Appliance does not support configuring multiple network interfaces during
installation. The eth0 interface is configured by default, and if you require multiple interfaces, you can
configure them through Administration Console after installation.
Field Description
Host Name The hostname for the Access Manager Appliance machine.
In the Root Password section, specify password for the root user and name of the NTP server.
8 Click Next.
Field Description
Admin Console IP Specify the IP address of the primary Access Manager Appliance if
this is secondary.
9 Click Next.
The Installation Settings page appears. This page displays the options and software you
selected in the previous steps. Use the Overview tab for a list of selected options, or use the
Expert tab for more details.
Do not change the software selections listed on this screen.
10 (Optional) To modify the installation settings for partitions, click Change.
11 Click Install > Install.
This process might take 45 to 90 minutes depending on the configuration and hardware.
The machine reboots after the installation is completed. It runs an auto configure script, and then
Access Gateway and Identity Server components are configured.
12 (Optional) Verify if Access Manager Appliance is installed and configured successfully.
Log in to Administration Console. See Section 2.2.4, “Logging In to Administration Console,” on
page 34), then click Devices > Access Gateways.
If the installation was successful, the IP address of your Access Gateway appears in the Server
list.
The Health status indicates the health state after Access Gateway is imported and registers with
Administration Console.
1 In Administration Console, click Access Gateway > Cluster > Edit > NAM - RP.
2 Select the namportal path based service.
3 Click Delete.
4 Click Protected Resources.
Delete the following protected resources:
portal_employee
portal_manager
portal_public
portal_users
5 Click OK > Update.
6 In Administration Console, click Devices > Identity Servers > Servers > Edit > Roles.
7 Select the role policy check box, select the portal_roles role from the Roles Policy List, and click
Disable.
8 Click OK > Update.
9 To remove the portal web application from the Access Manager Appliance filesystem, perform
the following steps:
9a Log in to Access Manager Appliance by using any SSH client (for example, SSH in Linux
and PuTTY in Windows).
9b Stop Administration Console by using the /etc/init.d/novell-ac stop command.
You cannot use it to log into other eDirectory trees and manage them.
You should not download and add iManager plug-ins to this customized version. If you do, you can
destroy the Access Manager Appliance schema, which can prevent you from managing Access
Manager Appliance components. This can also prevent communication among the modules.
You should not start multiple sessions of Administration Console on the same machine through the
same browser. Because the browser shares session information, this can cause unpredictable results
in Administration Console. You can, however, start different sessions with different brands of
browsers.
To log in to:
IMPORTANT: All of the configuration and management tasks in the Access Manager Appliance
documentation assume that you know how to log in to Administration Console.
To understand the conventions of Administration Console, see Section 2.2.5, “Administration Console
Conventions,” on page 35.
You can install Analytics Server after installing Administration Console. You can install it on any
server without the requirement for any base operating system because Analytics Server is packaged
with SLES operating system. Before you install Analytics Server, review the new functionality and
known issues in the supported SLES Release Notes.
Analytics Server is packaged in the ISO format, which can be deployed to the virtual environments.
If you are installing the ISO on bare metal hardware, download the ISO disk image from the support
site, unpack the file, and make a DVD.
3.1.1.1 System Requirements for Storing 500 Events Per Second (EPS)
CPU: Two lntel(R) Xeon(R) CPU ES-2650 @ 2.00GHz (4 core) CPUs (8 cores total), no hyper-
threading.
Primary storage: 10 x 300 GB SAS 15k RPM (Hardware RAID 10)
Memory: 24 GB RAM
Verify that your hardware and software meet the system requirements listed in Section 3.1.1,
“System Requirements,” on page 37.
No files or system settings from a previous Analytics Server installation, if any, are available on
the machine.
Ports listed in Section 1.6, “Setting Up Firewalls,” on page 20 are opened.
The password used for Administration Console does not include the “&” symbol. If the password
includes “&”, the Analytics Server installation fails. If you have used “&” in the password for
Administration Console, change Administration Console password, then start the Analytics
Server installation.
1 Download the ISO for the Analytics Server image from the NetIQ Download website (https://
dl.netiq.com/index.jsp).
2 (Conditional) If you are using a hypervisor, do one of the following actions:
Set up the virtual machine using the ISO virtual appliance image, and power it on.
Copy the ISO image into a DVD, set up the virtual machine using the DVD, and power it on.
3 (Conditional) If you are installing Analytics Server on bare metal hardware, perform the following
actions:
3a Boot the physical machine from the DVD drive with the DVD.
3b Follow the installation wizard on-screen instructions.
3c Run the Live DVD appliance image by selecting the top entry in the boot menu.
The installation checks for the available memory. If the available memory is less than 6.5
GB, the installation will not proceed further. Enter y if you want to continue with the
installation, or enter n if you do not want to proceed.
4 Select the language of your choice and keyboard Configuration, then click Next.
5 Read and accept the Access Manager Analytics Server End User License Agreement.
6 Click Next.
7 On the Hostname and Domain Name page, specify the hostname and domain name. De-select
Assign Hostname to Loopback IP, then click Next.
8 Choose one of the following connection settings options:
To use the current network connection settings, select Use the following configuration on
the Network Configuration II page.
To change the network connection settings, click Change, then make the desired changes.
9 Click Next.
10 Set the Time and Date, then click Next.
To change the NTP configuration after installation, use YaST from the appliance command line.
rcntp restart
NOTE: The Analytics Server admin password must not contain “$”, “_”, “!”, “<”, “ >”, “;”, “|”, “(”,
“&” or “)”. Also, the password must not begin with “#”.
13 In the Administration console server Information page, specify the following details to import
Analytics server to the specified Administration Console:
IP Address: IP address of Administration Console.
Admin User: The name of the user accessing Administration Console.
Password: Password of Administration Console user.
Confirm the password, then click Next.
NOTE: If the password includes the “&” symbol, the installation fails. You must change the admin
password in Administration Console (without “&”) to continue with Analytics server installation.
14 The Live Installation Settings page displays the selected installation settings. Review the
settings, configure the settings (if necessary), and then select Install.
15 Select Install to confirm the Installation.
Wait until the installation finishes. It might take few minutes for all services to start up after
installation because the system performs a one-time initialization.
16 The Suggested Partitioning screen displays the recommended partition setup. Review the
partition setup, configure the setup (if necessary), and then select Next. Modify these settings
only if you are familiar with configuring partitions in SLES.
You can configure the partition setup by using the various partitioning options on the screen. For
more information about configuring partitions, see Using the YaST Partitioner in the SLES
documentation.
17 Select OK to reboot the system.
18 (Conditional) If you are using a physical machine, eject the DVD.
19 (Conditional) If you are using a hypervisor click Enter.
20 Enter the root username and password at the console to log in to the appliance.
The default value for the username is root and the password is the password you set in Step 11.
21 Proceed with Section 3.2, “Post-Installation Configuration for Analytics Server,” on page 40.
NOTE: For installing Analytics Server in high-availability mode, see Section 3.3.2, “Installing
Analytics Server in High Availability Environment,” on page 41.
1 Specify the following command at the command line to run the configure.sh script:
./configure.sh
1 Install Analytics Server with one NIC that is configured with the IP address that must be used for
communicating with Administration Console. For installation steps, see Section 3.1.3, “Installing
Analytics Server,” on page 38.
2 After the installation completes, configure the other required network interfaces by using YaST.
For more information about implementing high availability and disaster recovery in the Analytics
Server environment, contact NetIQ Technical Support.
High availability refers to a design methodology that is intended to keep a system available for use as
much as is practicable. The intent is to minimize the causes of downtime such as system failures and
maintenance, and to minimize the time it will take to detect and recover from downtime events that do
occur. In practice, automated means of detecting and recovering from downtime events quickly
become necessary as higher levels of availability must be achieved.
For more information about high availability, see the SUSE High Availability Guide.
Ensure that each cluster node that hosts the Analytics Server services meet the requirements
specified in Section 3.1.1, “System Requirements,” on page 37.
Ensure that sufficient shared storage is available for the Analytics Server data and application.
Ensure that you use a virtual IP address for the services that can be migrated from node to node
on failover.
Ensure that your shared storage device meets the performance and size characteristics
requirements. It is recommended to use a standard SUSE Linux VM configured with iSCSI
Targets as shared storage.
Ensure that you have only two cluster nodes that meet the resource requirements for running
Analytics Server in the cluster environment.
Ensure you have a virtual IP that can be migrated from one node to another node in a cluster to
serve as the external IP address for Analytics Server.
Ensure you create a method for the cluster nodes to communicate with the shared storage, such
as FibreChannel for a SAN. NetIQ recommends a dedicated IP address to connect to the iSCSI
Target.
Ensure you have at least one IP address per cluster node for internal cluster communications.
NetIQ recommends a simple unicast IP address, but multicast is preferred for production
environments.
Use the following checklist to guide you through initial setup and configuration:
The CPU, RAM, and disk space characteristics for each cluster node must meet the system
requirements defined in Section 3.1.1, “System Requirements,” on page 37 based on the
expected event rate.
If you want to configure the operating system firewalls to restrict access to Analytics Server and
the cluster, refer to Table 1-3 on page 22, for details of which ports must be available depending
on your local configuration and the sources that will be sending event data.
NOTE: In a production cluster, you can use internal, non-routable IPs on separate NICs (possibly a
couple, for redundancy) for internal cluster communications.
A typical implementation might use a fast SAN attached using FibreChannel to all the cluster nodes,
with a large RAID array to store the local event data. As long as the cluster node can mount the
shared storage as a normal block device, it can be used by the solution.
NOTE: NetIQ recommends that you configure your shared storage and test mounting it on each
cluster node. However, the cluster configuration will handle the actual mount of the storage.
1 Connect to storage03, the VM you created during Initial Setup, and start a console session.
2 Use the dd command to create a blank file of any desired size for Analytics Server shared
storage. For creating a 20 GB file filled with zeros copied from the /dev/zero pseudo-device
file, run the following command:
dd if=/dev/zero of=/localdata count=20480000 bs=1024
1 Run YaST from the command line (or use the Graphical User Interface, if preferred): /sbin/
yast
2 Select Network Devices > Network Settings.
3 Ensure that the Overview tab is selected.
4 Select the secondary NIC from the displayed list, then tab forward to Edit and press Enter.
5 On the Address tab, assign a static IP address of 10.0.0.3. This will be the internal iSCSI
communications IP.
6 Click Next, then click OK.
7 On the main screen, select Network Services > iSCSI Target.
8 If prompted, install the required software (iscsitarget RPM) from the SUSE Linux 11 SP3
media.
9 Click Service, select the When Booting option to ensure that the service starts when the
operating system boots.
10 Click Global, and then select No Authentication because the current OCF Resource Agent for
iSCSI does not support authentication.
11 Click Targets and then click Add to add a new target.
The iSCSI Target will auto-generate an ID and then present an empty list of LUNs (drives) that
are available.
12 Click Add to add a new LUN.
13 Leave the LUN number as 0, then browse in the Path dialog (under Type=fileio) and select the /
localdata file that you created. If you have a dedicated disk for storage, specify a block device,
such as /dev/sdc.
14 Leave the other options at their defaults. Click OK and then click Next.
15 Click Next again to select the default authentication options, then Finish to exit the configuration.
Accept if asked to restart iSCSI.
16 Exit YaST.
NOTE: This procedure exposes two iSCSI Targets on the server at IP address 10.0.0.3. At each
cluster node, ensure that it can mount the local data shared storage device.
First node
To configure Analytics Server for HA, perform the following steps:
1 Connect to one of the cluster nodes (node01) and open a console window.
2 Navigate to the following directory:
cd /opt/novell/sentinel/setup
This step records the configuration in the file install.props,which is required to configure
the cluster resources using the install-resources.sh script.
3b Specify the Standard configuration option for Analytics Server Configuration method.
3c Specify 2 to enter a new password.
Even if you require to use the existing password, choose 2 so that the password is stored
and synchronized with the other node.
If you specify 1, the install.props file does not store the password.
4 Shut down Analytics Server services by using the following commands:
/etc/init.d/novell-offline stop
/etc/init.d/novell-realtime stop
/etc/init.d/novell-jcc stop
rcsentinel stop
insserv -r sentinel
5 Move the Analytics Server data folder to the shared storage using the following commands. This
movement allows the nodes to utilize the Analytics Server data folder through shared storage.
mkdir -p /tmp/new
mv /var/opt/novell/sentinel /tmp/new
umount /tmp/new/
6 Verify the movement of the Analytics Server data folder to the shared storage using the following
commands:
umount /var/opt/novell/
Subsequent node
1 Connect to second cluster node (node02) and open a console window.
2 Execute the following command:
insserv -r sentinel
rcsentinel stop
rm -rf /var/opt/novell/sentinel
At the end of this process, Analytics Server should be installed on all nodes, but it will likely not work
correctly on any but the first node until various keys are synchronized, which will happen when we
configure the cluster resources.
As part of this configuration, you can also set up fencing and Shoot The Other Node In The Head
(STONITH) resources to ensure cluster consistency.
For this solution you must use private IP addresses for internal cluster communications, and use
unicast to minimize the need to request a multicast address from a network administrator. You must
also use an iSCSI Target configured on the same SUSE Linux VM that hosts the shared storage to
serve as a Split Brain Detection (SBD) device for fencing purposes.
SBD Setup
1 Connect to storage03 and start a console session. Use the dd command to create a blank file of
any desired size:
2 Create a 1MB file filled with zeros copied from the /dev/zero pseudo-device.
3 Run YaST from the command line or the Graphical User Interface: /sbin/yast
4 Select Network Services > iSCSI Target.
5 Click Targets and select the existing target.
6 Select Edit. The UI will present a list of LUNs (drives) that are available.
7 Select Add to add a new LUN.
8 Leave the LUN number as 1. Browse in the Path dialog and select the /sbd file that you created.
9 Leave the other options at their defaults, then select OK then Next, then click Next again to
select the default authentication options.
10 Click Finish to exit the configuration. Restart the services if needed. Exit YaST.
NOTE: The following steps require that each cluster node be able to resolve the hostname of all other
cluster nodes (the file sync service csync2 will fail if this is not the case). If DNS is not set up or
available, add entries for each host to the /etc/hosts file that list each IP and its hostname (as
reported by the hostname command). Also, ensure that you do not assign a hostname to a loopback
IP address.
Perform the following steps to expose an iSCSI Target for the SBD device on the server at IP address
10.0.0.3 (storage03).
Node Configuration
1 Run YaST.
2 Open Network Services > iSCSI Initiator.
3 Select Connected Targets, then the iSCSI Target you configured above.
4 Select the Log Out option and log out of the Target.
5 Switch to the Discovered Targets tab, select the Target, and log back in to refresh the list of
devices (leave the automatic startup option and No Authentication).
6 Select OK to exit the iSCSI Initiator tool.
1 Run YaST.
2 Open Network Services > iSCSI Initiator.
3 Select Connected Targets, then the iSCSI Target you configured above.
4 Select the Log Out option and log out of the Target.
5 Switch to the Discovered Targets tab, select the Target, and log back in to refresh the list of
devices (leave the automatic startup option and No Authentication).
6 Select OK to exit the iSCSI Initiator tool.
7 Run the following command: sleha-join
Enter the IP address of the first cluster node.
8 Run crm_mon on each cluster node to verify that the cluster is running properly.
(Conditional) If the cluster does not start correctly, perform the following steps:
1 To ensure that in a single node failure in your two-node cluster does not unexpectedly stop the
entire cluster, set the global cluster option no-quorum-policy to ignore:
crm configure property no-quorum-policy=ignore
2 To ensure that the resource manager allows resources to run in place and move, set the global
cluster option default-resource-stickiness to 1:
crm configure property default-resource-stickiness=1
A filesystem resource corresponding to the shared storage that the software uses.
An IP address resource corresponding to the virtual IP by which the services will be accessed.
The PostgreSQL database software that stores configuration and event metadata.
NetIQ provides a crm script to aid in cluster configuration. The script pulls relevant configuration
variables from the unattended setup file generated as part of the Analytics Server installation. If you
did not generate the setup file, or you wish to change the configuration of the resources, you can use
the following procedure to edit the script accordingly.
The proceeding steps must be performed on the nodes on which Analytics Server is installed.
ln -s /var/log/agg-analytics-var/nam /var/opt/novell/nam
cd /usr/lib/ocf/resource.d/novell
./install-resources.sh
The install-resources.sh script will prompt you for a couple values, namely the virtual IP that
you would like people to use to access Analytics Server and the device name of the shared
storage, and then will auto-create the required cluster resources. Note that the script requires the
shared volume to already be mounted, and also requires the unattended installation file which
was created during Analytics Server install to be present (/tmp/install.props). You do not
need to run this script on any but the first installed node; all relevant config files will be
automatically synced to the other nodes.
crm status
include /etc/opt/novell/sentinel/config/auth.login;
include /etc/opt/novell/nam/sentinelReportAdminConfig;
auto first;
NOTE: The preceeding steps are used for installing and configuring the cluster for high availability.
However, to use this cluster configuration, you must enable clustering from Administration Console.
For more information, refer Section 3.3.3, “Post-Installation Cluster Configuration for Analytics
Server,” on page 50.
Appliance
This section discusses how to upgrade Access Manager Appliance to the newer version. You must
take a backup of the existing configurations before upgrading Access Manager Appliance.
For more information, see “Back Up and Restore” in the NetIQ Access Manager Appliance 4.4
Administration Guide.
NOTE: By default, the Access Manager configuration uses stronger TLS protocols, ciphers, and other
security settings. If you want to revert these settings after upgrading, see “Restoring Previous
Security Level After Upgrading Access Manager Appliance” in the NetIQ Access Manager Appliance
4.4 Security Guide.
To upgrade to Access Manager Appliance 4.4, you need to be on one of the following versions of
Access Manager Appliance:
To upgrade to Access Manager Appliance 4.4 Service Pack 1, you need to be on one of the
following versions of Access Manager Appliance:
For information about the latest supported upgrade paths, see the specific Release Notes on the
Access Manager Appliance Documentation website.
IMPORTANT: If you are using SQL database and you are upgrading to Access Manager Appliance
4.4, you must run a utility to re-factor the database. This is to ensure that Access Manager Appliance
and its associated products use the same naming convention. For more information about this utility
and how to run it, see Appendix B, “Refactoring SQL Database,” on page 83.
Before performing an upgrade, ensure that the following prerequisites are met:
Any option that is configured through the nidpconfig.properties file will be overwritten after
upgrade. Therefore, back up the nidpconfig.properties file before upgrading to Access
Manager 4.4. After the upgrade, replace the new nidpconfig.properties file with the backed
up file.
Access Manager 4.2 onwards, some of the options are supported only through Administration
Console. After the upgrade, configure those options through Administration Console. For the list
of options that must be configured through Administration Console, see Configuring Identity
Server Global Options, Configuring ESP Global Options, Defining Options for SAML 2.0 in the
NetIQ Access Manager Appliance 4.4 Administration Guide.
Access Manager 4.2 and later versions do not support Platform Agent and Novell Audit. If you
are upgrading from an older version of Access Manager where you have configured Platform
Agent, ensure to remove this configuration before upgrading to the latest version. Otherwise,
auditing will fail because the Platform Agent service is not available post upgrade.
Administration Console checks for proper host entry in the FQDN format before upgrading to
Access Manager 4.4. The host entry must be the first entry in the /etc/hosts file. For example,
10.10.10.10 amac.blr.novell.com must be the first entry in the /etc/hosts file, where
10.10.10.10 is the IP address of Administration Console. To find FQDN, use command openssl
s_client -connect <IP address>:636 | grep CN, where <IP address> is the IP address of
Administration Console LDAP server.
This change is made to meet the eDirectory 9.x requirement. If Administration Console upgrade
fails, see Section 9.3, “Administration Console Upgrade Fails,” on page 75.
The upgrade process overwrites all customized JSP files. If you have customized JSP files for
Identity Server or Access Gateway, you must perform manual steps to maintain the customized
JSP files. For more information, see Section 4.1, “Maintaining Customized JSP Files for Identity
Server,” on page 54 or Section 4.2, “Maintaining Customized JSP Files for Access Gateway,” on
page 55.
If you have customized any changes to tomcat.conf or server.xml, back up the files. After the
upgrade, restore the files.
If you have installed the unlimited strength java crypto extensions before upgrade, re-install it
after the upgrade because a new Java version will be used.
If you are using Kerberos, back up the /opt/novell/nids/lib/webapp/WEB-INF/classes/
kerb.properties file. After the upgrade, restore the files.
Similarly, if you are using any customized files, ensure to back it up and copy the customized
content from the backed up file to the upgraded file after the upgrade is successful.
(Linux) Ensure to perform the following procedure for both SLES and Red Hat:
1. Open the nds.conf file available under /etc/opt/novell/eDirectory/conf/.
2. Delete all the duplicate lines from the file. For example the file may contain two lines of
n4u.server.vardir=/var/opt/novell/eDirectory/data. Delete one of them.
3. Restart eDirectory using /etc/init.d/ndsd restart command.
Prerequisites 53
If you have enabled history for risk-based authentication in a prior version of Access Manager,
you must upgrade the database for risk-based authentication after upgrading to 4.4. You can find
the upgrade script here: /opt/novell/nids/lib/webapp/WEB-INF/RiskDBScript.zip.
MySQL: Run netiq_risk_mysql_upgrade.sql
Oracle: Run netiq_risk_oracle_upgrade.sql
Microsoft SQL Server: Run netiq_risk_sql_server_upgrade.sql
In addition to the these prerequisites, ensure that you also meet the hardware requirements. For
more information about hardware requirements, see the component-specific requirements in Part I,
“Installing Access Manager Appliance,” on page 25.
NOTE: If you do not create the legacy folder, Access Manager uses the logic of the default new
login pages.
4 Copy your all backed up JSP files into the /opt/novell/nids/lib/webapp/jsp directory.
5 Refresh the browser to see the changes.
54 Prerequisites
2 Upgrade Access Manager Appliance.
3 Create an empty folder legacy in Identity Server: /opt/novell/nids/lib/webapp/WEB-INF/
legacy.
NOTE: If you do not create the legacy folder, Access Manager uses the logic of the default new
login pages.
4 Copy your all backed up JSP files into the /opt/novell/nids/lib/webapp/jsp directory.
5 Find the customized nidp.jsp and content.jsp files and make the following changes in both
files:
5a In the top Java section of the JSP file, find the ContentHandler object that looks similar to
the following:
boolean bGotoAlternateLandingPageUrl =
handler.gotoAlternateLandingPageUrl();
5c Find the first instance of <script></script> in the JSP file that is not <script src></
script>, then insert the following line in to the JavaScript section between the <script></
script> tags:
This redirects control to the default portal page that contains appmarks.
5d Save the file.
5e Repeat the steps for the second JSP file.
6 Refresh the browser to see the changes.
1 Before upgrade, create a copy of all JSP files inside the /opt/novell/nesp/lib/webapp/jsp
directory and place the copy somewhere else.
NOTE: If you do not create the legacy folder, Access Manager uses the logic of the default new
login pages.
4 Copy your all backed up JSP files into the /opt/novell/nesp/lib/webapp/jsp directory.
5 Refresh the browser to see the changes.
Prerequisites 55
56 Prerequisites
5 Upgrading Access Manager Appliance
5
Section 5.1, “Upgrading from the Evaluation Version to the Purchased Version,” on page 57
Section 5.2, “Upgrading Access Manager Appliance,” on page 57
NOTE: For information about the name of the upgrade file, see the specific Release Notes on
the Access Manager Documentation website.
3 Change to the directory where you extracted the file, then run the following command:
./sb_upgrade.sh
4 The system displays a message regarding restoring customized files.
For more information about how to sanitize jsp pages, see Preventing Cross-site Scripting
Attacks in the NetIQ Access Manager Appliance 4.4 Administration Guide
5 A confirmation message is displayed.
Type Y to continue.
6 Enter the Access Manager Administration Console user ID.
7 Enter the Access Manager Administration Console password.
8 Re-enter the password for verification.
The system displays the following message when the upgrade is complete:
1. If you are upgrading Access Manager, and want to use syslog for auditing, you must first
upgrade the base operating system.
2. If you have customized the tomcat.conf file or the server.xml file, back up these files before
upgrading. These files are overwritten during the upgrade process.
IMPORTANT: If you are using SQL database and you are upgrading to Access Manager 4.4, you
must run a utility to re-factor the database. This is to ensure that Access Manager and its associated
products use the same naming convention. For more information about this utility and how to run it,
see Appendix B, “Refactoring SQL Database,” on page 83.
NOTE: For information about the name of the file, see the specific Release Notes on the Access
Manager Appliance Documentation website.
3 Change to the directory where you extracted the file, then run the following command:
./sb_upgrade.sh
IMPORTANT: httpd.conf file will be overwritten with a new file because Access Manager
Appliance 4.4 upgrades Apache 2.2 to Apache 2.4 to support WebSocket. A backup of the
existing httpd.conf file will be available at /root/nambkup.
Type Y to continue.
5 The system displays a message regarding restoring customized files:
Before you restore your existing custom pages, ensure that you read and
understand the changes in steps from the Installation and Upgrade guide
available online.
# It is recommended that you run XSS checks for restored JSP files as
instructed in the Installation and Upgrade guide available online.
Type Y to confirm.
For more information about how to sanitize JSP pages, see Preventing Cross-site Scripting
Attacks in the NetIQ Access Manager Appliance 4.4 Administration Guide.
6 Type Y and press Enter.
The system displays an information message to upgrade the base operating system and enable
Syslog.
7 Type Y to continue with the upgrade, then press Enter.
The system displays a warning message to back up the existing JSP files.
NOTE
If you have customized the Java settings in the /opt/novell/nam/idp/conf/tomcat.conf
file, then copy the customized setting to the new file after the upgrade.
If OAuth and OpenID Connect protocol is enabled, then after upgrading you must update
Administration cluster to use the JSON Web Token (JWT token). For more information
about JWT token, see Understanding How Access Manager Uses OAuth and OpenID
Connect in the NetIQ Access Manager Appliance 4.4 Administration Guide.
NOTE: If you have enabled history for risk-based authentication in a prior version of Access
Manager, you must upgrade the database for risk-based authentication after upgrading to 4.4.
You can find the upgrade script here: /opt/novell/nids/lib/webapp/WEB-INF/
RiskDBScripts.zip.
MySQL: Run netiq_risk_mysql_upgrade.sql
Oracle: Run netiq_risk_oracle_upgrade.sql
Microsoft SQL Server: Run netiq_risk_sql_server_upgrade.sql
NOTE: To use Syslog for auditing, you need to upgrade the base operating system. After the
upgrade, install the Syslog RPMs manually. To install the RPMs, execute the following
command: zypper in -t pattern NetIQ-Access-Manager.
For security considerations, see “Securing Analytics Server” in the NetIQ Access Manager Appliance
4.4 Security Guide.
NOTE: For the name of the upgrade file, see the specific Release Notes on the Access Manager
Documentation website.
3 Change to the directory where you extracted the file, then enter the following command in a
terminal window:
./ar_upgrade.sh
The upgrade completes with the following options. Choose one of the following options:
By default, the data is migrated. The migration of data may take longer time. If it fails, you must run
the upgrade script again. Even when the data from the elasticsearch is deleted, the audit data is not
deleted from the server.
The upgrade logs are saved in the /tmp/novell_access_manager/ directory. The logs include time
stamping.
NOTE: After upgrading Analytics Server, you must clear the browser cache before accessing
Analytics dashboard.
The maintenance mode prevents any disturbance to the running cluster resources when you
update Analytics Server. You can run this command from any cluster node.
2 Verify if the maintenance mode is active.
crm status
rcopenais stop
Stopping the cluster stack ensures that the cluster resources remain accessible and avoids
fencing of nodes.
3b Upgrade Analytics Server in the passive node. See “Upgrading Analytics Server” on
page 61.
3c After the upgrade is complete, start the cluster stack.
rcopenais start
rcopenais stop
Stopping the cluster stack ensures that the cluster resources remain accessible and avoids
fencing of nodes.
4b Upgrade Analytics Server on the active node. See “Upgrading Analytics Server” on
page 61.
4c After the upgrade is complete, start the cluster stack.
rcopenais start
4d Run the csync2 -x -v command to synchronize any changes in the configuration files.
5 Disable the maintenance mode on the cluster.
The OpenSSL open source project team regularly releases updates to known OpenSSL
vulnerabilities. Access Manager Appliance and Analytics Server use the OpenSSL library for
cryptographic functions. It is recommended that you keep Access Manager Appliance and Analytics
Server updated with the latest OpenSSL patch.
Prerequisites
Before upgrading the kernel, ensure that you have updated the operating system to a supported
version.
Access Manager Appliance and Analytics Server install a customized version of SLES 11 SP4. If
you want to install the latest patches as they become available, you must have a user account to
receive the Linux updates.
Ensure that you have obtained the activation code for Access Manager Appliance from Novell
Customer Center.
WARNING: Installing additional packages other than security updates breaks your support
agreement. If you encounter a problem, Technical Support can require you to remove the additional
packages and to reproduce the problem before receiving any help with your problem.
Section 7.1, “Installing or Updating Security Patches for Access Manager Appliance and
Analytics Server,” on page 65
NOTE: You must perform the proceeding steps to register with Novell Customer Center for Access
Manager Appliance and Analytics Server separately.
zypper lr
# | Alias | Name
| Enabled | Refresh
--+--------------------------------------+-----------------------------------
1 | NetIQAccessManagerAppliance-4.x.x-x | NetIQAccessManagerAppliance-4.x.x-x
| Yes | No
2 | nu_novell_com:NAM42-APP-Updates | NAM42-APP-Updates
| Yes | Yes
Analytics Server
# | Alias | Name
| Enabled | Refresh
--+--------------------------------------+-----------------------------------
1 | NetIQAnalyticsServer-4.x.x-x | NetIQAnalyticsServer-4.x.x-x
| Yes | No
2 | nu_novell_com:NAM42-APP-Updates | NAM42-APP-Updates
| Yes | Yes
To use an SMT server for client registration and as a local update source, you must configure the
SMT server in your network first. The SMT server software is distributed as an add-on for SUSE
Linux Enterprise Server. For information about configuring the SMT server, see Subscription
Management Tool (SMT) for SUSE Linux Enterprise 11.
The following sections describe the configuration required for Access Manager Appliance:
1 Install the SMT server in a SLES 11 SP4 server. For more information, see Subscription
Management Tool (SMT) for SUSE Linux Enterprise 11.
2 Log in to you Novell Customer Center account.
3 Select My Products > Mirroring Credentials, then click Generate Credentials.
4 Copy the mirroring credentials before logging out of your Novell Customer Center account.
5 Run the SMT Configuration tool from YAST, then specify the mirroring credentials.
6 Run the SMT Management tool.
The NAM4x-APP-Updates, sle-11-x86_64 repository is displayed in the Repositories tab.
7 Select sle-11-x86_64, then click Toggle Mirroring to ensure mirroring is selected for this
repository.
8 Click Mirror Now. This step ensures that the NAM4x-APP-Updates channel updates are
mirrored from nu.novell.com to your local SMT server.
9 When mirroring is complete, click OK to close the tool.
For example,
You can get the SMT server URL by running the SMT Configuration tool at the server. The URL
is set by default.
3 Enter y to accept the CA certificate of the server.
4 Enter y to start the registration.
5 The script performs all necessary modifications on the client.
6 Execute the following command to perform registration:
suse_register
7 Specify the following command to get online updates from the local SMT server:
zypper up
8 Reboot the machine if prompted at the end of any patch install.
9 Confirm that all the patches are installed by running zypper up command again.
Upgrade
The installation logs are located in the /tmp/novell_access_manager directory. The following is the
list of useful log files:
Troubleshooting Installation 71
Log File Description
72 Troubleshooting Installation
8.6 DN Is Added as Provider ID While Installing the
NMAS SAML Method
While installing the NMAS SAML method in an external user store, DN is added as a provider ID
instead of the metadata URL.
To workaround this issue, perform the steps mentioned in TID 7022372 (https://www.netiq.com/
support/kb/doc.php?id=7022372).
Troubleshooting Installation 73
74 Troubleshooting Installation
9 Troubleshooting Upgrade
9
Section 9.1, “Access Gateway Throws a 403 Forbidden Page Error for a Resource Protected by
a Form Fill Policy,” on page 75
Section 9.2, “Issue in SSL Communication between Access Gateway and Web Applications,” on
page 75
Section 9.3, “Administration Console Upgrade Fails,” on page 75
Section 9.4, “Customized Login Pages Are Missing After Upgrading Access Manager,” on
page 76
Section 9.5, “The Email OTP JSP Page Does Not Render Properly on Internet Explorer 11,” on
page 76
Section 9.6, “Access Manager Upgrade Hangs While Upgrading eDirectory,” on page 77
1 Click Devices > Access Gateways > Edit > Advanced Options.
2 Specify ProxyErrorOverride off.
3 Click OK.
After upgrading Access Manager from 3.1 SP4 or 3.1 SP5 to 4.0.x, applications are not accessible.
This issue happens when there is any discrepancy between the cipher suites configured for Access
Gateway and the applications protected by this Access Gateway.
Troubleshooting Upgrade 75
Perform the following steps:
IMPORTANT: Administration Console checks for proper host entry in the FQDN format before
upgrading to Access Manager 4.4. The host entry must be the first entry in the /etc/hosts file. For
example, 10.10.10.10 amac.blr.novell.com must be the first entry in the /etc/hosts file, where
10.10.10.10 is the IP address of Administration Console. To find FQDN, use command openssl
s_client -connect <IP address>:636 | grep CN, where <IP address> is the IP address of
Administration Console LDAP server.
To resolve this issue, see Section 4.1, “Maintaining Customized JSP Files for Identity Server,” on
page 54.
To workaround this issue, add the following entry to the nidp_latest.jsp page:
Linux: /opt/novell/nids/lib/webapp/jsp
<%
76 Troubleshooting Upgrade
9.6 Access Manager Upgrade Hangs While Upgrading
eDirectory
On Windows 2012 R2 Server, the Access Manager upgrade hangs while upgrading eDirectory. This
occurs because the nservmsg.dll file gets locked. This is a random issue.
Troubleshooting Upgrade 77
78 Troubleshooting Upgrade
IV Appendix
IV
Appendix A, “Configuring Ports 9000 and 9001 to Listen on the Specified Address,” on page 81
Appendix B, “Refactoring SQL Database,” on page 83
Appendix 79
80 Appendix
A Configuring Ports 9000 and 9001 to
A
In Access Manager Appliance 4.4, ports 9000 and 9001 listen on 127.0.0.1 by default. Access
Manager Appliance uses these ports for scheduling jobs. If you encounter any issue because of
these ports listening on 127.0.0.1, such as issue with IPv6 connectivity, you can specify a different
address by using the following Java option in the tomcat8.conf file:
/opt/novell/nam/adminconsole/conf/tomcat8.conf
"com.microfocus.nam.adminconsole.localhost.ipaddress"
For example:
JAVA_OPTS="${JAVA_OPTS} -
Dcom.microfocus.nam.adminconsole.localhost.ipaddress=10.0.0.0"
Access Manager uses a user's DN to store data for Risk Based Authentication in SQL database. A
majority of LDAP user stores uses lowercase naming convention. From Access Manager 4.4
onwards all user data will be stored in the SQL database using a lower case DN. Hence, it ensures
that Access Manager interacts with other products without any conflict.
If you are upgrading from an older version with SQL database in place, you must refactor your
database to save existing users’ DN to lowercase. To refactor your database, you must run a jar utility
supplied along with Access Manager 4.4. If you do not run this utility, the existing user data can
become irrelevant in RBA and may not be used for Risk Score calculation.
IMPORTANT
hibernate.connection.url=<URL>
hibernate.connection.username=<Username>
hibernate.connection.password=<Password>
hibernate.dialect=<Database Dialect>
hibernate.connection.driver_class=<Database Driver>
IMPORTANT: Make sure that you specify absolute paths in classpath and arguments to avoid
platform specific issues.