This section provides information about general troubleshooting issues found in the Administration Console:
Section 26.3.5, Converting a Secondary Access Manager Appliance into a Primary Appliance
Section 26.3.8, Unable to Log In to the Administration Console
Section 26.3.9, Exception Processing IdentityService_ServerPage.JSP
Section 26.3.10, Backup and Restore Failure Because of Special Characters in Passwords
Section 26.3.15, Incorrect Health Is Reported on the Access Gateway
Section 26.3.16, Administration Console Does Not Refresh the Command Status Automatically
Section 26.3.18, Error: Tomcat did not stop in time. PID file was not removed
Section 26.3.20, View Objects Do Not Function Properly in Internet Explorer 10 Default Mode
The following options allow you to view the status of multiple devices and identify the devices that are not healthy.
If your Access Manager Appliance 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.
In the Administration Console, click Auditing > Troubleshooting > Configuration.
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. |
When you have finished repairing or deleting invalid Access Gateway configurations, click the Access Gateways link, then click Update > OK.
(Optional) Verify that all members of an Access Gateway cluster have the same configuration in cache:
Click Auditing > Troubleshooting > Configuration.
Scroll to the Cached Access Gateway Configuration option.
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.
(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.
The Policies page displays the policies that are in an unusable state because of configuration errors.
In the Administration Console, click Auditing > Troubleshooting > Policies.
If you have configured a policy without defining a valid rule for it, the policy appears in this list.
Select the policy, then click Remove.
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 Appliance components are running compatible versions:
To view the current version of all Access Manager Appliance devices:
In the Administration Console, click Auditing > Troubleshooting.
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.
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).
In the Administration Console, click Auditing > Troubleshooting > User Sessions.
Specify the user ID and click Search. If a match is found, it lists the IP address of the Identity Server and its sessions.
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 Section 26.5.24, Terminating an Existing Authenticated User from the Identity Server.
The Policies page displays the policies that are in an unusable state because of configuration errors.
In the Administration Console, click Auditing > Troubleshooting > Policies.
If you have configured a policy without defining a valid rule for it, the policy appears in this list.
Select the policy, then click Remove.
The System Alerts page displays how many unacknowledged alerts have been generated for all the devices imported into this Administration Console.
In the Administration Console, click Access Manager > Dashboard > Alerts.
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. |
In the Administration Console, you can create a .ldif file that you can export for diagnostic purposes:
Log in as root.
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
Specify the Access Manager administrator’s password.
Confirm the password.
Specify the path where you want to store the diagnostic file.
Specify a name for the diagnostic file. The system adds .xml automatically as file extension.
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.
The XML file or LDIF file (if required) can then be sent to NetIQ Support for help in diagnosing configuration problems.
You can troubleshoot by configuring component logging. In the Administration Console, click Devices > Identity Server > Edit > Logging.
For more information, see Section 17.7, Using Log Files for Troubleshooting.
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 Appliance devices try to contact it.
On the primary console, click Auditing > Troubleshooting.
In the Other Known Device Manager Servers section, click Remove next to the secondary console that is failed.
Remove traces of the secondary console from the configuration datastore:
In the NetIQ Access Manager menu bar, select View Objects.
In the Tree view, select novell.
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
Install a new secondary console. For installation instructions, see Section 7.1, Installing Secondary Versions of Access Manager Appliance.
To convert a secondary Access Manager Appliance into a primary Access Manager Appliance, a recent backup of Access Manager Appliance must be available. For information about how to perform a backup, see Section 24.2, Backing Up the Access Manager Appliance 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.
This conversion includes the following tasks:
If your primary Access Manager Appliance is running, you must log in as the administrator and shut down the service.
Start YaST, click System > System Services (Runlevel), then select to stop the ndsd service.
Changing the master replica to reside on the new primary Access Manager Appliance makes this Access Manager Appliance into the certificate authority for Access Manager. You need to first designate the replica on the new primary Access Manager Appliance as the master replica. Then you need to remove the old primary Access Manager Appliance from the replica ring.
At the secondary Access Manager Appliance, log in as root.
Change to the /opt/novell/eDirectory/bin directory.
Run DSRepair with the following options:
./ndsrepair -P -Ad
Select the one available replica.
Select Designate this server as the new master replica.
Run ndsrepair -P -Ad again.
Select the one available replica.
Select View replica ring.
Select the name of the failed primary server.
Select Remove this server from replica ring.
Specify the DN of the admin user in leading dot notation. For example:
.admin.novell
Specify password.
Type I Agree when prompted.
Continue with Restoring CA Certificates.
Perform the following steps on the machine that you are promoting to be a primary Appliance.
Copy your most recent Access Manager Appliance backup files to your new primary Access Manager Appliance.
Change to the backup bin directory:
/opt/novell/devman/bin
Verify the IP address in the backup file. The IP_Address parameter value should be the IP address of the new Primary Administration Console.
Open the backup file:
defbkparm.sh
Verify that the value in the IP_Address parameter is the IP address of your new primary console.
Save the file.
Run the certificate restore script:
sh aminst-certs.sh
When prompted, specify the administrator’s password and location of the backup files.
Continue with 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.
Change to the Appliance configuration directory:
opt/novell/devman/share/conf
Run the following command in the command line interface to restart Access Manager Appliance:
/etc/init.d/novell-ac restart OR rcnovell-ac restart
Continue with Deleting Objects from the eDirectory Configuration Store.
Objects representing the failed primary Access Manager Appliance in the configuration store must be deleted.
Log in to the new Administration Console, then click Access Gateways.
If the failed primary Appliance's Access Gateway is the primary server (has the red icon next to it), then change the primary Access Gateway server.
Click [Access Gateway cluster name] > Edit.
Select a different primary Access Gateway > click Ok > click Close.
Ignore any trust store related warnings.
Click Update All.
Wait until the status becomes current for all except the failed primary Appliance.
Click Auditing > Troubleshooting.
In the Other Known Device Manager Servers section, select the old primary Appliance, then click Remove.
Remove traces of the failed primary Access Manager Appliance from the configuration datastore:
In the NetIQ Access Manager menu bar, select View Objects.
In the Tree view, select novell.
Delete all objects that reference the failed primary Access Manager Appliance.
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
Continue with Performing Component-Specific Procedures.
If you have installed the following components, perform the cleanup steps for the component:
If you installed a third Appliance used for failover, you must manually perform the following steps on that server:
Open the vcdn.conf file.
/opt/novell/devman/share/conf
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 Appliance IP address.
Change this IP address to the IP address of the new primary Appliance.
Restart the Access Manager Appliance by entering the following command from the command line interface:
/etc/init.d/novell-ac restart OR rcnovell-ac restart
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.
At the Access Gateway Service, log in as the root or the Administrator user.
Shut down all Access Gateway Services.
/etc/init.d/novell-appliance stop OR rcnovell-appliance stop
(Conditional) If your audit server was on the primary Administration Console, edit the config.xml file:
Change to the directory and open the file.
/opt/novell/nam/adminconsole/webapps/agm/WEB-INF/config/current
Find the NsureAuditSetting entry.
In the IPv4Address field, change the IP address from the failed Administration Console to the new primary Appliance address.
Save and exit.
Edit the settings.properties file:
Change to the directory and open the file.
/opt/novell/devman/jcc/conf
Change the IP address in the remotemgmtip list from the IP address of the failed Appliance to the address of the new primary Appliance.
Save and exit.
At the Access Gateway Service, start all services by entering the following command:
/etc/init.d/novell-appliance start OR rcnovell-appliance start
(Conditional) Repeat this process for each Access Gateway Service that has been imported into the Administration Console.
On the new primary Appliance, change to the /opt/novell/devman/bin directory.
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 Appliance you are on.
Modify these lines to use the hostname of the failed Appliance.
When you install the primary Appliance, 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 Appliance had amlab as its hostname, you would change these lines to have the following values:
EDIR TREE="amlab_tree" EDIR CA="amlab_tree CA"
Save your changes.
Take a backup from your new primary Appliance.
WARNING:After configuring the secondary Appliance to be the new primary Appliance and performing all the cleanup steps, you cannot restore an old backup from the primary Appliance.
Take a new backup as soon as your new primary Appliance is functional.
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 Section 24.3, Restoring the Access Manager Appliance Configuration.
To run DSRepair:
In a browser, enter the following URL.
http://<ip_address>:8028/nds
Replace <ip_address> with the IP address of your Administration Console.
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.
In the View bar, select the Repair icon.
For more information about DSRepair, see the following:
Click the Help icon.
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.
If you experience problems logging in to the Administration Console, you might need to restart Tomcat.
Restart Tomcat by running this command:
/etc/init.d/novell-ac restart OR rcnovell-ac restart
If this does not solve the problem, check the log file:
/opt/novell/nam/adminconsole/logs/catalina.out
Check for the following error:
Error Starting up core services. Application manager is Shutting down the Device Manager suite. Shutting down Device Manager suite.
If you see this error, check the status of eDirectory:
Enter the following command:
/etc/init.d/ndsd status
If the status command returns nothing, start eDirectory manually.
Enter the following command:
/etc/init.d/ndsd start
Restart Tomcat.
If you see the message Exception processing IdentityService_ServerPage.jsp on the 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]
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:
/opt/novell/devman/bin/defbkparm.sh
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 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 7004701: iManager: Certificate Server Plugin Errors.
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.
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.
If you change the existing values and click Apply, an information window displays the following messages:
All Access Gateways need to be updated.
All servers need to be rebooted to start using the new configuration.
Click OK.
Update the Access Gateway whose events are not seen.
Restart the Access Gateway.
If Server Listening IP Address, Server Public NAT IP Address and Port Numbers are valid and still have problems, repush the configuration.
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.
Change the invalid port number again to the valid port number, then click Apply.
The configuration is repushed and works successfully.
Update the Access Gateway whose events are not seen.
Restart the Access Gateway.
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:
In the Administration Console, click Devices > Access Gateways.
Click the Health icon of the Access Gateway that has the problem.
Note the Reverse Proxies that have the problem.
In the Administration Console, click Devices > Access Gateways.
Click the Edit link for the cluster that has problem.
For each of the Reverse Proxies that have the problem, do the following:
Click Reverse Proxy.
Select the cluster member from the list.
Select the new IP address on which the proxy service will listen to.
Unselect the old IP address on which proxy service was listening to.
Click OK.
An alert is displayed as "Select at least one listening address for the service."
Click OK.
Again select the Listening IP Address check box.
Click OK.
If the update link is enabled, click on it. If not, do the following:
Click Edit for the cluster that has problem.
Click the Proxy name link.
Click Proxy service name in the Proxy Service list.
Enter the description.
Click OK.
The Update link will be enabled.
Click Update.
After the device command status moves to Succeeded, verify the health status of the Access Gateway.
Even after successful installation or upgrade of Access Gateway, the health shows failure in starting ESP. After an fresh import of Access 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:
On the Access Gateway, go to the <keystorefilelocation> location as specified in the health error message.
Delete the files indicated in the ESP error message.
In the Administration Console, click Auditing > TroubleShooting > Certificates.
Enable the device that has been deleted in the Access Manager Appliance and it needs to be re-pushed.
Click Re-Push Certificate.
Restart server provider of 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.
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.
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 Section 14.6, Configuring the SSL Communication.
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.
If the Administration Console is down, the IP address for that console is not seen. To bring up that Administration Console, follow these steps:
Run the sntp -P no -r PRIMARY_IP command.
Run the /etc/init.d/novell-ac restart OR rcnovell-ac restart command.
If the Administration Console is still not available, follow these steps:
Run the /etc/init.d/ndsd restart command.
Run the /etc/init.d/novell-ac restart OR rcnovell-ac restart command.
When you click View Objects, you cannot perform any popup related operations in Tree, Browse, and Search tabs.
To workaround this issue, launch Internet Explorer 10 in the compatibility mode.
NOTE:This is an iManager issue. See Operations Under the View Objects do not function properly in Internet Explorer 10 Default Mode in the iManager 2.7.6 Readme.