26.3 Troubleshooting the Administration Console

26.3.1 Global Troubleshooting Options

The following options allow you to view the status of multiple devices and identify the devices that are not healthy.

Checking for Potential Configuration Problems

If your Access Manager components are not behaving in the way 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 Dashboard, click 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 5). If an option contains an entry, you need to clear it. Select the appropriate action from the following table:

    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 the commands, 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.

    Other Known Device Manager Servers

    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 Remove next to the console that is in the non-reporting state. All references to the secondary Administration Console are removed from the configuration database.

    Access Gateways with Corrupt Protected Resource Data

    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 Repair 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

    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 Repair.

    Access Gateways with Protected Resources Referencing Nonexistent Policies

    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.

    Access Gateways with Invalid Alert Profile References

    You can create XML validation errors on your Access Gateway Appliance 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 Remove. You should then be able to modify its configuration, and when you update the Access Gateway, the changes should be applied and saved.

    Devices with Corrupt Data Store Entries

    If an empty value is written to an XML attribute, the device with this invalid configuration appears in this list.

    Click Repair 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) Verify that all members of an Access Gateway cluster have the same configuration in cache:

    1. Click Troubleshooting > Configuration.

    2. Scroll to the Cached Access Gateway Configuration option.

    3. 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.

  5. (Conditional) After viewing the Access Gateway configuration (see Step 4) 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.

Checking for Invalid Policies

The Policies page displays the policies that are in an unusable state because of configuration errors.

  1. In the Administration Console Dashboard, click Troubleshooting > Policies.

    If you have configured a policy without defining a valid rule for it, the policy appears in this list.

  2. Select the policy, then click Remove.

Checking for Version Conflicts

The Version page displays all the installed components along with their currently running version. Use this page to verify that you have updated all components to the latest compatible versions. There are two steps to ensuring that your Access Manager components are running compatible versions:

  • All components of the same type should be running the same version. If you have components that display multiple versions, identify the components that need to be upgraded and upgrade them to the newer version.

  • All components need to be running versions that are compatible with each other.

To view the current version of all Access Manager devices:

  1. In the Administration Console Dashboard, click Troubleshooting.

  2. Click Version.

    A list of the devices with their version information is displayed. If a device also has an Embedded Service Provider, the version of the Embedded Service Provider is also displayed.

Checking and Terminating User Sessions

The User Sessions page helps you to find users logged into your system and also helps to terminate their sessions if required. It displays the active user details for each Identity Server. You can search for a user with the user ID and terminate the session(s).

  1. In the Administration Console Dashboard, click Troubleshooting > User Sessions.

  2. Specify the user ID and click Search. If a match is found, it lists the IP address of the Identity Server and its sessions.

  3. Click Terminate Sessions to terminate the sessions of the specific user.

    NOTE:User details are fetched once per administration session. The last updated date is displayed. To refresh the data, click on Refresh.

For more information about user sessions, see Terminating an Existing Authenticated User from the Identity Server.

Checking for Invalid Policies

The Policies page displays the policies that are in an unusable state because of configuration errors.

  1. In the Administration Console Dashboard, click Troubleshooting > Policies.

    If you have configured a policy without defining a valid rule for it, the policy appears in this list.

  2. Select the policy, then click Remove.

Viewing System Alerts

The System Alerts page displays how many unacknowledged alerts have been generated for all the devices imported into this Administration Console.

  1. In the Administration Console Dashboard, click Alerts.

  2. To acknowledge and clear the alerts for a device, select the name of the server, then click Acknowledge Alerts.

The following columns display information about the alerts for each server.

Column

Description

Server Name

Specifies the name of the server receiving alerts. Click the server name to view more information about an alert before acknowledging it.

Severe

Indicates how many severe alerts have been sent to the server.

Warning

Indicates how many warning alerts have been sent to the server.

Informational

Indicates how many informational alerts have been sent to the server.

26.3.2 Diagnostic Configuration Export Utility

In the Administration Console, you can create a .ldif file that you can export for diagnostic purposes:

  1. Log in as root.

  2. On Linux: Change to the /opt/novell/devman/bin directory and run the following command:

    ./amdiagcfg.sh

    On Windows: Go to the C:\Program Files (x86)\Novell\bin directory and run the following command:

    ./amdiagcfg.bat

  3. Specify the Access Manager administrator’s password.

  4. Confirm the password.

  5. Specify the path where you want to store the diagnostic file.

  6. Specify a name for the diagnostic file. The system adds .xml automatically as file extension.

  7. Press Enter.

The Diagnostic Configuration Export utility is almost identical to the backup utility because it also creates a LDIF file with an addition of an XML Dump file. Passwords from the final LDIF file are removed by a program called Strippasswd.

Strippasswd removes occurrences of passwords in the LDIF file and replaces 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.

With every Access Manager release you must copy the corresponding XML style sheet file (XSL file) to the same directory where the XML file is located. This helps in displaying the information in correct format. The XSL file is located at /opt/novell/devman/bin.

The XML file along with XSL file or LDIF file (if required) can then be sent to NetIQ Support for help in diagnosing configuration problems.

26.3.3 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 Tomcat7

Whichever method you use to stop Tomcat, Tomcat is stopped. Wait a minute before restarting Tomcat.

26.3.4 Logging

You can troubleshoot by configuring component logging. In the Administration Console, click Devices > Identity Server > Edit > Logging.

For more information, see Using Log Files for Troubleshooting.

26.3.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. If the failed console is part of the configuration, other Access Manager devices try to contact it.

  1. On the primary console, click Troubleshooting.

  2. In the Other Known Device Manager Servers section, click Remove next to the secondary console that is failed.

  3. Remove traces of the secondary console from the configuration datastore:

    1. In the NetIQ Access Manager menu bar, select View Objects.

    2. In the Tree view, select novell.

    3. 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.

26.3.6 Moving the Primary Administration Console to New Hardware

If you do not have any secondary consoles:

  1. Perform a backup. For instructions, see Backing Up the Access Manager Configuration.

  2. Install the Administration Console on the new hardware, using the same DNS name and IP address.

  3. Restore the configuration. For instructions, see Restoring the Access Manager Configuration.

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 Backing Up the Access Manager Configuration.

  2. Down any secondary consoles.

  3. Install the Administration Console on the new hardware based on the following scenarios:

    1. When the Primary Administration Console is installed on a new hardware: Use the same DNS name and IP address used with the 4.0 Administration Console.

    2. When the Primary Administration Console is migrated from 3.1 SP4 or 3.1 SP5: Use the same IP address used with the 4.0 Administration Console and the DNS name of the 3.1 SP4 or 3.1 SP5 Administration Console.

  4. Restore the configuration. For instructions, see Restoring the Access Manager Configuration.

  5. Remove any secondary consoles from the configuration:

    1. In the Administration Console Dashboard, click Troubleshooting.

    2. 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 NetIQ Access Manager 4.2 Installation and Upgrade Guide.

  7. Reinstall the secondary consoles as secondary consoles to the new primary console.

NOTE:Taking the backup of the Administration Console configuration on one platform such as Linux and restoring it to another platform such as on Windows or vice versa is not supported.

26.3.7 Converting a Secondary Administration Console into a Primary Console

To convert a secondary Administration Console into a primary the Administration Console, a recent backup of Administration Console must be available. For information about how to perform a backup, see Backing Up the Access Manager Configuration. A backup is necessary to restore the certificate authority (CA).

If the failed server holds a master replica of any partition, you must use ndsrepair to designate a new master replica on a different server in the replica list.

WARNING:Perform these steps only if the primary Administration Console cannot be restored. If you have a recent backup, you can restore the primary Administration Console to new hardware. This is an easier configuration task than converting a secondary console into a primary console. See Moving the Primary Administration Console to New Hardware.

This conversion includes the following tasks:

Shutting Down the Primary 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 x64 NDS Server.

Changing the Master Replica

Changing the master replica to reside on the new primary Administration Console makes 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

  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. Specify the DN of the admin user in leading dot notation. For example:

    .admin.novell

  12. Specify password.

  13. Type I Agree when prompted.

  14. Continue with Restoring CA Certificates.

Windows Secondary Administration Console

  1. At the secondary Administration Console, log in as an administrator.

  2. Change to the C:\Novell\NDS directory.

  3. Start the NDSCons.exe program.

  4. Select dsrepair.dlm.

  5. In the Parameters box, specify -A, then click Start

  6. Click Partitions > Root > Designate This Server As The New Master Replica.

  7. Open Partitions > Root, select the server, and verify that the replica is the master replica.

  8. Run dsrepair 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. Specify the DN of the admin user in leading dot notation. For example:

    .admin.novell

  12. Specify password.

  13. Continue with Restoring CA Certificates.

Restoring CA Certificates

Perform the following steps 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. On the Windows 2012 server, open the Registry Editor using the regedit command.

    1. Traverse to \HEKY_LOCAL_MACHINE\SOFTWARE\NOVELL\AccessManager\Devman key.

    2. Update the value of the key with the IP address of the new Primary Administration Console.

  3. Change to the backup bin directory:

    Linux: /opt/novell/devman/bin

    Windows Server 2012: \Program Files (x86)\Novell\bin

  4. Verify the IP address in the backup file. The IP_Address parameter value should be the IP address of the new Primary Administration Console.

    1. Open the backup file:

      Linux: defbkparm.sh

      Windows: defbkparm.properties

    2. Verify that the value in the IP_Address parameter is the IP address of your new primary console.

    3. Save the file.

  5. Run the certificate restore script:

    Linux: sh aminst-certs.sh

    Windows: aminst-certs.bat

  6. When prompted, specify the administrator’s password and location of the backup files.

  7. Continue with Verifying the vcdn.conf File.

Verifying the vcdn.conf File

Verify whether the vcdn.conf file contains IP address of the new Administration Console. If it contains IP address of the failed primary Administration Console, replace it with the new IP address.

  1. Change to the Administration Console configuration directory:

    Linux: opt/novell/devman/share/conf

    Windows Server 2012: \Program Files (x86)\Novell\Tomcat\webapps\roma\WEB-INF\conf

  2. Run the following command in the command line interface to restart the Administration Console:

    Linux: /etc/init.d/novell-ac restart or rcnovell-ac restart

    Windows: net stop Tomcat7

    net start Tomcat7

  3. Continue with Deleting Objects from the eDirectory Configuration Store.

Deleting Objects from the eDirectory Configuration Store

Objects representing the failed primary Administration Console in the configuration store must be deleted.

  1. Log in to the new Administration Console, then click Troubleshooting.

  2. In the Other Known Device Manager Servers section, select the old primary Administration Console, then click Remove.

  3. Remove traces of the failed primary Administration Console from the configuration datastore:

    1. In the NetIQ Access Manager menu bar, select View Objects.

    2. In the Tree view, select novell.

    3. Delete all objects that reference the failed primary Administration Console.

      You should find the following types of objects:

      • SAS Service object with the hostname of the failed primary console

      • An object that starts with the last octet of the IP address of the failed primary console

      • DNS AG object with the hostname of the failed primary console

      • DNS IP object with the hostname of the failed primary console

      • SSL CertificateDNS with the hostname of the failed primary console

      • SSL CertificateIP with the hostname of the failed primary console

      • NCP server object

  4. Continue with Performing Component-Specific Procedures.

Performing Component-Specific Procedures

If you have installed the following components, perform the cleanup steps for the component:

Identity Server Installed with the Failed Primary Administration Console

If you had an Identity Server installed with your failed primary Administration Console, you need to clean up the configuration database to remove references to this Identity Server.

  1. Log in to the Administration Console.

  2. Remove the Identity Server:

    1. Click Devices > Identity Servers.

    2. Select the Identity Server that was installed with the primary Administration Console.

    3. Remove it from the cluster, then delete it.

Third Administration Console

If you installed a third Administration Console used for failover, you must manually perform the following steps on that server:

  1. Open the vcdn.conf file.

    Linux: /opt/novell/devman/share/conf

    Windows Server 2012: \Program Files (x86)\Novell\Tomcat\webapps\roma\WEB-INF\conf

  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: /etc/init.d/novell-ac restart OR rcnovell-ac restart

    Windows: Use the following commands:

    net stop Tomcat7

    net start Tomcat7

Access Gateway Appliances

For each Access Gateway Appliance imported into the Administration Console, edit the settings.properties file on the Access Gateway if the primary Administration Console was not configured as the Audit Server. The settings.properties file is required for JCC Communication between devices and the Administration Console.

If the primary Administration Console was configured as an Audit Server, you must edit the config.xml file and the settings.properties file on the Access Gateway and edit the CurrentConfig and WorkingConfig XML documents in the configuration store on the new primary Administration Console.

When the Primary Administration Console Was not Configured as the Audit Server

  1. At the Access Gateway Appliance, log in as the root user.

  2. Open a terminal window and shut down all services by entering the following command:

    /etc/init.d/novell-appliance stop

  3. Edit the settings.properties file:

    1. Enter: vi /opt/novell/devman/jcc/conf/settings.properties

    2. Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.

    3. Enter :wq! to save and exit.

  4. At the Access Gateway Appliance, start all services by entering the following commands:

    /etc/init.d/novell-appliance start

  5. (Conditional) Repeat this process for each Access Gateway that has been imported into the Administration Console.

When the Primary Administration Console Was Configured as the Audit Server

  1. At the Access Gateway Appliance, log in as the root user.

  2. Open a terminal window and shut down all services by entering the following command:

    /etc/init.d/novell-appliance stop

  3. Edit the config.xml file:

    1. Enter vi /opt/novell/nam/mag/webapps/agm/WEB-INF/config/current/config.xml

    2. Enter /Remote, then press Enter.

      In the IPv4Address field, change the IP address from the failed Administration Console to the new primary Administration Console address.

    3. Enter /NsureAuditSetting, then press Enter.

      In the IPv4Address field, change the IP address from the failed Administration Console to the new primary Administration Console address.

    4. Enter :wq! to save and exit.

  4. Edit the settings.properties file:

    1. Enter: vi /opt/novell/devman/jcc/conf/settings.properties

    2. Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.

    3. Enter :wq! to save and exit.

  5. At the new primary Administration Console, open an LDAP browser and edit the CurrentConfig object of the Access Gateway Appliance.

    IMPORTANT:You should use an LDAP browser for the following steps, rather than iManager. Because iManager is slow at saving large files, your iManager connection might time out before your modifications are saved.

    1. Browse to the following container: novell > accessManagerContainer > VCDN_Root > PartitionsContainer > Partition > AppliancesContainer.

      A list of devices appears. Access Gateways have an ag prefix.

    2. Expand an Access Gateway container, then select the CurrentConfig object.

    3. Select the romaAGConfigurationXMLDoc attribute and open it so you can view its value.

      The value is a large XML file.

    4. Copy the contents of the attribute to a text editor.

    5. (Conditional) To verify which Access Gateway Appliance you are changing, search for the <Local> element.

      The IP address should match the IP address of the Access Gateway Appliance that you are configuring for the new primary Administration Console.

    6. Search for the <Remote> element.

    7. Change the IP address of the <Remote> element so that it matches the IP address of the new primary Administration Console.

    8. Search for the <NsureAuditSetting> element.

      Change the IP address of the <NsureAuditSetting> element so that it matches the IP address of the new primary Administration Console.

    9. Copy the modified document in the text editor to the value field of the romaAGConfigurationXMLDoc attribute.

    10. Save your changes.

  6. At the new primary Administration Console, edit the WorkingConfig object of the Access Gateway Appliance:

    Use an LDAP browser for these steps.

    1. Browse to the following container: novell > accessManagerContainer > VCDN_Root > PartitionsContainer > Partition > AppliancesContainer.

      A list of devices appears. Expand the Access Gateway container.

    2. Select the WorkingConfig object.

    3. Select the romaAGConfigurationXMLDoc attribute and open it so you can view its value.

    4. Copy the contents of the attribute to a text editor.

    5. Search for the <Remote> element.

    6. Change the IP address of the <Remote> element so that it matches the IP address of the new primary Administration Console.

    7. Search for the <NsureAuditSetting> element.

      Change the IP address of the <NsureAuditSetting> element so that it matches the IP address of the new primary Administration Console.

    8. Copy the modified document in the text editor to the value field of the romaAGConfigurationXMLDoc attribute.

    9. Save your changes.

  7. At the Access Gateway Appliance, start all services by entering the following command:

    /etc/init.d/novell-appliance start

  8. (Conditional) Repeat this process for each Access Gateway that has been imported into the Administration Console.

Access Gateway Services

For each Access Gateway Service imported into the Administration Console, edit the settings.properties file on the Access Gateway if the primary Administration Console was not configured as the Audit Server.

If the primary Administration Console was configured as an Audit Server, you must edit the config.xml file and the settings.properties file on the Access Gateway and edit the CurrentConfig and WorkingConfig XML documents in the configuration store on the new primary Administration Console.

  1. At the Access Gateway Service, log in as the root or the Administrator user.

  2. Shut down all Access Gateway Services.

    Linux: Enter the /etc/init.d/novell-appliance stop command.

    Windows: Click Control Panel > Administrative Tools > Services, then stop the following services:

    Apache Tomcat
    JCCServer

    Stopping Apache Tomcat causes Apache 2.2 to also stop.

  3. (Conditional) If your audit server was on the primary Administration Console, edit the config.xml file:

    1. Change to the directory and open the file.

      Linux: /opt/novell/nam/mag/webapps/agm/WEB-INF/config/current/config.xml

      Windows: \Program Files\Novell\Tomcat\webapps\agm\ WEB-INF\config\current

    2. Find the NsureAuditSetting entry.

      In the IPv4Address field, change the IP address from the failed Administration Console to the new primary Administration Console address.

    3. Save and exit.

  4. Edit the settings.properties file:

    1. Change to the directory and open the file.

      Linux: /opt/novell/devman/jcc/conf

      Windows: \Program Files\Novell\devman\jcc\conf

    2. Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.

    3. Save and exit.

  5. At the Access Gateway Service, start all services by entering the following command:

    Linux: /etc/init.d/novell-appliance start OR rcnovell-appliance start

    Windows: Click Control Panel > Administrative Tools > Services, then start the following services:

    Apache Tomcat
    JCCServer

    Starting Apache Tomcat causes Apache 2.2 to also start.

  6. (Conditional) Repeat this process for each Access Gateway Service 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:

  1. Log in as the root user.

  2. Open a terminal window and shut down all services by entering the following commands:

    • /etc/init.d/novell-jcc stop OR rcnovell-jcc stop

    • /etc/init.d/novell-idp stop OR rcnovell-idp stop

  3. Edit the settings.properties file:

    1. Enter vi /opt/novell/devman/jcc/conf/settings.properties

    2. Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.

    3. Enter :wq! to save and exit.

  4. Start the services by entering the following commands:

    • /etc/init.d/novell-jcc start OR rcnovell-jcc start

    • /etc/init.d/novell-idp start OR rcnovell-idp start

Windows Identity Server

For each Windows Identity Server imported into the Administration Console, perform the following steps:

  1. Open a terminal window and shut down all services by entering the following commands:

    net stop JCCServer

    net stop Tomcat7

  2. Edit the settings.properties file:

    1. Change to the following directory:

      Windows Server 2012: \Program Files (x86)\Novell\devman\jcc\conf

    2. Open the settings.properties file.

    3. Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console.

    4. Save your changes.

  3. Start the services by entering the following commands:

    net start JCCServer

    net start Tomcat7

Old Primary Administration Console

After the secondary console has been promoted to be the primary console, uninstall the Administration Console software of the old primary Administration Console. Before uninstalling, make sure the machine is disconnected from the network. For instructions, see Uninstalling the Administration Console in the NetIQ Access Manager 4.2 Installation and Upgrade Guide.

If you want to use the old primary console as a secondary console, you need to first uninstall the Administration Console software. Connect the machine to the network, then reinstall the software, designating this console as a secondary console.

Enabling Backup on the New Primary Administration Console

If you installed your Administration Consoles using the 3.1 version of Access Manager, the backup utility is properly configured.

If you have upgraded the Linux Administration Consoles from 3.0 SP4 to 3.1, you need to modify the defbkparm.sh file before performing a backup.

  1. On the new primary Administration Console, change to the /opt/novell/devman/bin directory.

  2. Open the defbkparm.sh file and find the following lines:

    EDIR TREE=<tree_name>
    EDIR CA=<CA name>

    These lines contain values using the hostname of the Administration Console you are on.

  3. Modify these lines to use the hostname of the failed Administration Console.

    When you install the primary Administration Console, the EDIR TREE parameter is set to the hostname of the server with _tree appended to it. The EDIR CA parameter is set to the hostname of the server with _tree CA appended to it.

    If the failed Administration Console had amlab as its hostname, you would change these lines to have the following values:

    EDIR TREE="amlab_tree"
    EDIR CA="amlab_tree CA"
  4. Save your changes.

  5. Take a backup from your new primary Administration Console.

    WARNING:After configuring the secondary Administration Console to be the new primary Administration Console and performing all the cleanup steps, you cannot restore an old backup from the primary Administration Console.

    Take a new backup as soon as your new primary Administration Console is functional.

26.3.8 Repairing the Configuration Datastore

The configuration datastore is an embedded version of eDirectory 8.8. If it becomes corrupted, you can run DSRepair to fix it. Or, you can restore a recent backup. To restore a backup, see Restoring the Access Manager Configuration.

To run DSRepair:

  1. In a browser, enter the following URL.

    http://<ip_address>:8028/nds

    Replace <ip_address> with the IP address of your Administration Console.

  2. At the login prompt, enter the username and password of the admin user for the Administration Console.

    The NDS iMonitor application is launched. For more information, see Accessing iMonitor.

  3. In the View bar, select the Repair icon.

    For more information about DSRepair, see the following:

26.3.9 Session Conflicts

Do not use two instances of the same browser to simultaneously access the same Administration Console. Browser sessions share settings, which can result in problems when you apply changes to configuration settings. However, you can use two different brands of browsers simultaneously, such as Internet Explorer and Firefox to avoid the session conflicts.

26.3.10 Unable to Log In to the Administration Console

If you experience problems logging in to the Administration Console, you might need to restart Tomcat.

  1. In a terminal window on the console machine, restart Tomcat:

    Linux: Enter the following command:

    /etc/init.d/novell-ac restart OR rcnovell-ac restart

    Windows: Enter the following commands:

    net stop Tomcat7

    net start Tomcat7

  2. If this does not solve the problem, check the log file:

    Linux: /opt/novell/nam/adminconsole/logs/catalina.out

    Windows Server 2012: \Program Files (x86)\Novell\Tomcat\logs\stdout.log

  3. Check for the following error:

    Error Starting up core services.
    Application manager is Shutting down the Device Manager suite.
    Shutting down Device Manager suite.
  4. (Linux) If you see this error, check the status of eDirectory:

    1. Enter the following command:

      /etc/init.d/ndsd status

      If the status command returns nothing, start eDirectory manually.

    2. Enter the following command:

      /etc/init.d/ndsd start

    3. Restart Tomcat.

  5. (Windows) If you see this error, check the status of eDirectory:

    1. Enter the following command:

      net start "nds server0"

      If the service has been started, this command returns a message that the service has been started. If the service has been stopped, its starts eDirectory.

    2. Verify that the agent is running. Click Control Panel > Novell eDirectory Services, then verify that the Server box does not contain an agent closed message.

    3. If the agent is closed, run dsrepair.

    4. Restart Tomcat.

26.3.11 (Linux) Exception Processing IdentityService_ServerPage.JSP

If you see the message Exception processing IdentityService_ServerPage.jsp on a Linux Administration Console, it is an indication that the system has run out of available file handles. You need to use the command line to increase the ulimit value (ulimit -n [new limit]), which sets the number of open file descriptors allowed.

To set this value permanently, you can create the /etc/profile.local file with the ulimit value, such as:

ulimit -n 4096

You can make changes to /etc/security/limits.conf file with a line just to change the limit for a specific user. In this case: novlwwuser. Add the following line:

novlwww soft nofile [new limit]

26.3.12 Backup and Restore Failure Because of Special Characters in Passwords

Administration passwords with special characters such as dollar signs might cause the ambkup utility to fail. The ambkup utility creates a command line for the ICE utility, and the special characters might be interpreted by it. If you must use special characters, and this issue arises, modify the defbkparm file so that the special characters are escaped.

For example, if the administrator’s password is mi$$le, then the field DS_ADMIN_PWD should be mi\$\$le.

This file is located in the following directory:

Linux: /opt/novell/devman/bin/defbkparm.sh

Windows Server 2012: \Program Files (x86)\Novell\bin\defbkparm.properties

26.3.13 Unable to Install NMAS SAML Method

When you try to create an Identity Server cluster configuration with an eDirectory user store and with the Install NMAS SAML method option enabled and you have not installed the dependent packages, the following error message is displayed:

Warning: Failed to create SAML Affiliate Object com.novell.security.japi.nmas.LoginMethodModel.getLsmWINNNTStatus()I

One of the installation requirements for the Linux Administration Console is to install the compat and the libstdc++ packages.On SLES 11, the compat package contains the libstdc++ library. The Identity Server also requires the compat package. For more information about installing these packages, see TID 7006437.

26.3.14 Incorrect Audit Configuration

If the Audit Events from Access Gateway behind NAT are not seen in the Audit Server, do the following:

Click Auditing in the Administration Console and verify if values are provided for the Server Listening IP Address, Server Public NAT IP Address, and Port Numbers fields.

Scenario 1:

  1. If the values are not provided for the Server Listening IP Address, Server Public NAT IP Address, and Port Numbers fields, enter the values, then click Apply.

  2. If you change the existing values and click Apply, the following message is displayed:

    Step 1: Update all Access Gateways.
    Step 2: To update the configuration files in the Administration Console, see the context-sensitive help.
    Step 3: Reboot all servers to start using the new configuration.
  3. Click OK.

  4. Update the Access Gateway whose events are not seen.

  5. Restart the Access Gateway.

Scenario 2:

  1. If Server Listening IP Address, Server Public NAT IP Address and Port Numbers are valid and still have problems, repush the configuration.

  2. Change the port number to some invalid port number, then click Apply.

    NOTE:Do not update or restart the Access Gateway as the message indicates.

  3. Change the invalid port number again to the valid port number, then click Apply.

    The configuration is repushed and works successfully.

  4. Update the Access Gateway whose events are not seen.

  5. Restart the Access Gateway.

26.3.15 Unable to Update the Access gateway Listening IP Address in the Administration Console Reverse Proxy

The Administration Console fails to change the Access Gateway listening IP address of the Reverse Proxy. The health status of the Access Gateway on Administration Console displays failure to start the protected resource with old Listening IP address. However, when protected resource is viewed (Devices > Access Gateways > Access Gateway or Access Gateway Cluster > Proxy), the Administration Console displays the new IP Address has been selected as listening IP address of the Reverse Proxy.

To workaround this issue:

  1. In the Administration Console, click Devices > Access Gateways.

    1. Click the Health icon of the Access Gateway that has the problem.

    2. Note the Reverse Proxies that have the problem.

  2. In the Administration Console, click Devices > Access Gateways.

  3. Click the Edit link for the cluster that has problem.

  4. For each of the Reverse Proxies that have the problem, do the following:

    1. Click Reverse Proxy.

    2. Select the cluster member from the list.

    3. Select the new IP address on which the proxy service will listen to.

    4. Unselect the old IP address on which proxy service was listening to.

    5. Click OK.

    6. An alert is displayed as "Select at least one listening address for the service."

    7. Click OK.

    8. Again select the Listening IP Address check box.

    9. Click OK.

  5. If the update link is enabled, click on it. If not, do the following:

    1. Click Edit for the cluster that has problem.

    2. Click the Proxy name link.

    3. Click Proxy service name in the Proxy Service list.

    4. Enter the description.

    5. Click OK.

      The Update link will be enabled.

    6. Click Update.

After the device command status moves to Succeeded, verify the health status of the Access Gateway.

26.3.16 During Access Gateway Installation Any Error Message Should Not Display Successful Status

Even after successful installation or upgrade of Access Gateway, the health shows failure in starting ESP. After an fresh import of Access GatewayAccess Manager Appliance in the Administration Console, the Access Gateway Health displays “ESP Failed to initialize : Unable to read <keystorefilelocation>”. The keystore file can be Connector, Signing, Encryption or Truststore.

To workaround this issue:

  1. On the Access Gateway, go to the <keystorefilelocation> location as specified in the health error message.

  2. Delete the keystore/truststore indicated in the ESP error message.

  3. In the Administration Console Dashboard, click TroubleShooting > Certificates.

  4. Enable the keystore device or cluster that has been deleted in the Access Gateway and it needs to be re-pushed.

  5. Click Re-Push Certificate.

  6. Restart server provider of the Access Gateway.

26.3.17 Incorrect Health Is Reported on the Access Gateway

In the Administration Console, if the Stop Service on Audit Server Failure option is enabled, the Access Gateway services are stopped and show the Health status reports services as down when the Audit server is not functioning or reachable,.

If the Stop Service on Audit Server Failure option is disabled, the Access Gateway Service comes up but the related Health status still reports the services as being down.

To workaround this issue restart Tomcat.

26.3.18 Importing the 3.1 SP4 Access Gateway by Changing the Device IP Address on the Existing Configuration Is Not Supported

Importing an existing 3.1 SP4 Access Gateway configuration in to the Administration Console by changing the device IP address is not supported. It results in inconsistent behavior.

The recommendation is to freshly install the 3.1 SP4 Access Gateway pointing to the existing configuration on the Administration Console.

26.3.19 Administration Console Does Not Refresh the Command Status Automatically

The automatic refresh feature to retrieve device health is disabled when total number of the Access Gateway devices imported to an Administration Console page is more than 20. This feature is disabled to prevent the performance overhead in getting the health of 20 or more devices simultaneously.

To workaround this issue an administrator can manually refresh the page to get the health status of the devices.

26.3.20 SSL Communication with Weak Ciphers Fails

Access Manger supports only the 128-bit SSL communication among the Administration Console, Identity Server, and browsers.

If you want to enable the weak ciphers (not recommended), see Configuring the SSL Communication.

26.3.21 Error: Tomcat did not stop in time. PID file was not removed

While stopping Tomcat for the Administration Console, Access Gateway, or Identity Server, you may get this error message:

Tomcat did not stop in time. PID file was not removed.

Ignore this message. Tomcat will be forcibly stopped if it does not stop normally.

26.3.22 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.

To workaround this issue, perform the following steps:

  1. Manually stop the Windows Event Log service.

  2. On the upgrade pop-up screen, click Retry.

  3. Restart the Windows Event Log service manually again and proceed with the upgrade.