March 12, 2008
The following sources provide information about Novell® Access Manager:
Access Manager Support (support TIDs)
If your Access Manager system has experienced any of the problems listed in Section 2.2, Issues Fixed in the 3.0 SP2 IR1 Release, you should upgrade to the IR1 release.
Your system must be upgraded to SP2 before applying this patch release. (For SP2 installation information, see Section 3.0, Installing the 3.0 SP2 Release.)
The patch file for upgrading the components to the IR1 release (nam3sp2ir1.tar.gz) can be downloaded from Novell Downloads Web site. This patch contains the following files:
Table 1 Access Manager 3.0 SP2 IR1 Patch File
NOTE:If you have ordered (for free) the high bandwidth version, log in to the Novell Customer Center to download the patch for the high bandwidth version.
Log in as root on the machine you need to patch.
Copy the AM_302_SP2_IR1_IdentityServer_Upgrade.tar.gz file to the machine and unpack it.
When the file is unpacked, you should see a manifest file, a nampatch.sh install script, and a patchIR1 directory. These three items need to be in the same directory.
From this directory, enter the following command:
./nampatch.sh
(Optional) Verify the upgraded version number.
This patch installer does the following:
It warns connected users that services are being restarted.
If you have installed your Identity Server and Administration Console on the same machine, it detects this and patches both components.
Events from the patch process are logged to a file in the /tmp directory.
A backup of the files that are being replaced is stored in the $HOME directory.
Before you upgrade the Linux Access Gateway, the Linux Access Gateway file (AM_302_SP2_IR1_lagrpms.tar.gz) needs to be renamed. In the download, it needs to have a version-specific name, but to use it in an upgrade, it needs the generic name. It should be renamed as follows:
AM_302_SP2_IR1_lagrpms.tar.gz renamed to lagrpms.tar.gz
For more information on the various methods for upgrading the Linux Access Gateway, see Upgrading the Linux Access Gateway.
Select the correct patch file according to the version of SSL VPN you have installed:
To upgrade the low bandwidth version of SSL VPN, extract the AM_302_SP2_IR1_sslvpnrpms.tar.gz file from the patch file.
To upgrade the high bandwidth version of SSL VPN, download the AM_302_SP2_IR1_HB_sslvpnrpms.tar.gz file from the Novell Customer Center. The high bandwidth version is subject to certain export restrictions. Check with your sales representative to see if you are eligible to receive this version.
WARNING:If you use the AM_302_SP2_IR1_sslvpnrpms.tar.gz file to upgrade the high bandwidth SSL VPN, you downgrade your system to the low bandwidth version, which causes serious performance and configuration issues. Make sure you use the correct file for the version you have installed.
To check the version of SSL VPN that is currently installed on your system, enter the following command:
rpm -qa|grep novl-sslvpn
The RPM names for high bandwidth version appear with an _hb.
NOTE:To upgrade from the SP2 low bandwidth version of SSL VPN to the high bandwidth version of SSL VPN, refer to “Installing the High Bandwidth Version of SSL VPN” in the Novell Access Manager Installation Guide. Perform this upgrade before installing the patch.
Refer to “Upgrading the SSL VPN Server” in the Novell Access Manager Installation Guide for instructions for all installations of SSL VPN: installed as standalone component, installed with the Identity Server or Administration Console, or installed with the Linux Access Gateway.
The version number for SSL VPN, after the upgrading to IR1 should be 3.0.2.01.
If your agents have an unhealthy status because the SSL health check is failing, you need to upgrade the nipd.jar file to solve this problem. If your agents are not experiencing this problem, your configuration is not triggering the problem and the upgrade to IR1 is optional.
Log in as root on the agent machine you need to patch.
Copy the AM_302_SP2_IR1_IdentityServer_Upgrade.tar.gz file to the agent machine and unpack it.
When the file is unpacked, you should see a manifest file, a nampatch.sh install script, and a patchIR1 directory. These three items need to be in the same directory.
From this directory, enter the following command:
./nampatch.sh
This patch installer does the following:
It warns connected users that services are being restarted.
Events from the patch process are logged to a file in the /tmp directory.
A backup of the files that are being replaced is stored in the $HOME directory.
Unzip the nam3sp2ir1.tar.gz patch file.
Copy the AM_302_SP2_IR1_IdentityServer_Upgrade.tar.gz file to the computer where the agent is installed and unzip it.
When the file is unzipped, you should see a manifest file, a nampatch.sh install script, and a patchIR1 directory. The patchIR1 directory contains the nidp.jar file.
Shut down the Application Server.
Copy the nidp.jar file in the patchIR1 directory so that it replaces the nidp.jar file of the agent.
The easiest way to replace the nidp.jar file is to do a search on the drive for nidp.jar, then replace the files with the new one. These files are located in the following directories in a typical installation:
WebSphere: c:\Program Files\IBM\WebSphere\AppServer\profiles\ default\installedApps\am3-was6-agentNode01Cell\NIDPJ2EEApp.ear\ nesp.war\WEB-INF\lib\nidp.jar
WebLogic: Two locations.
c:\bea\user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_user\AccessManagerEmbeddedServiceProvider\pagp7x\war\WEB-INF\lib\nidp.jar c:\Novell\nesp.ear\nesp.war\WEB-INF\lib\nidp.jar
JBoss: c:\jboss\jboss-4.0.3SP1\server\default\tmp\deploy\ tmp3756nesp.ear-contents\nesp-exp.war\WEB-INF\lib\nidp.jar
Start the Application Server.
If your NetWare® Access Gateways have an unhealthy status because the SSL health check is failing, you need to upgrade the nipd.jar file to solve this problem. If your NetWare Access Gateways are not experiencing this problem, your configuration is not triggering the problem and the upgrade to IR1 is optional.
To upgrade the NetWare Access Gateway:
Unzip the nam3sp2ir1.tar.gz patch file.
Unzip the AM_302_SP2_IR1_IdentityServer_Upgrade.tar.gz file.
When the file is unzipped, you should see a manifest file, a nampatch.sh install script, and a patchIR1 directory. The patchIR1 directory contains the nidp.jar file.
Stop the NetWare Access Gateway.
Copy the nidp.jar file to sys:\tomcat\4\webapps\nesp\WEB-INF\lib and replace the existing nipd.jar file.
Start the NetWare Access Gateway.
Fixed a rewriter issue where the input fields for search and replace were limited to 255 characters. The input fields now have a limit of 2047 characters.
Fixed the health status issues that caused the SSL communication check to fail when SSL communication was still functioning correctly. This fix modified the nidp.jar file. All Access Manager components must be updated with the new nidp.jar file in order to fix the issue for that component.
Fixed issues with server persistence to the back-end Web servers.
Fixed the Linux Access Gateway crash that occurred while allocating scache entry in the server-side code.
Fixed issues with the Linux Access Gateway cache setting, which resulted in the Linux Access Gateway going into the non-responsive mode when a Web page accessed through Firefox* is refreshed.
The maximum size of a route in Enterprise mode is now increased to 2048 characters.
You can now assign a maximum of 32 roles with a maximum of 64 characters each to a user.
Fixed an issue that occurred when SSL VPN was connected through a forward proxy in the Kiosk mode.
The Novell Access Manager 3.0 SP2 release contains ISO files for installing the Access Manager components and a patch file for upgrading all components from SP1.
Your system needs to be upgraded to SP1 in order for you to upgrade to SP2. To verify that all components have been upgraded to SP1:
In the Administration Console, click > >
Examine the value of the field and ensure that it displays the correct version.
All of the above versions can be used to upgrade to SP2. The SP2 version contains all of the fixes that were available in the three Interim Releases.
Your Access Manager components must be upgraded to 3.0 SP1 before you upgrade to 3.0 SP2. The patch consists of one download file, which can be downloaded from Novell. The following table lists the files contained in the patch file (nam3sp2.tar.gz) that you can use to upgrade existing components or to install new instances:
Table 2 Access Manager 3.0 SP2 Upgrade Files
To upgrade to this release, you should first back up your current configuration. The Administration Console should be the first device you upgrade. You can then upgrade the various devices that you have imported into the Administration Console. We highly recommend that you upgrade all members of a cluster before moving to another type of device to upgrade. When you finish upgrading, you should perform a system backup.
The LAG file (AM_302_SP2_lagrpms.tar.gz) needs to be renamed. In the patch download, it needs to have a version-specific name, but to use it in an upgrade, it needs the generic name. It should be renamed as follows:
AM_302_SP2_lagrpms.tar.gz renamed to lagrpms.tar.gz
For the Identity Server and the Administration Console, copy the .tar.gz file to machine where these components are installed. For the Access Gateways, copy the files to a server that is accessible to your Access Gateway and perform an over-the-wire upgrade. For more information about upgrading the Access Manager components, see Upgrading Access Manager Components.
For specific installation steps, installation requirements, and overview information, see the Novell Access Manager Installation Guide.
WARNING:The J2EE Agents page now displays a option. Do not use this option; it is unsupported in SP2 and corrupts the configuration of secondary agents added to a cluster.
If you add only one agent to the cluster, the agent continues to function. If you add secondary agents to the cluster, the configuration of the primary agent overwrites the configurations of the secondary agents. With this configuration, the Identity Server can no longer authenticate users trying to access the secondary agents. To fix the problem, remove the secondary agents from the cluster and reconfigure the secondary agents, starting with the base URL.
For instructions on upgrading the agents, see Upgrading the J2EE Agents.
For a known issue when upgrading the Linux Agents, see The Health of the Linux Agent Is Not Green after Upgrading to SP2.
The high bandwidth SSL VPN server does not ship with the product because of export laws and restrictions. The high bandwidth version does not have the connection and performance restrictions that are part of the version that ships with the product. Your regular Novell sales channel can determine if the export law allows you to order the high bandwidth version at no extra cost.
After you have purchased (for free) the high bandwidth version, log in to the Novell Customer Center and you will see a link that allows you to download the high bandwidth version.
For installation instructions, see Installing SSL VPN.
If you are installing Access Manager 3.0 SP2 from CD, the following ISO images are provided:
Table 3 Access Manager 3.0 SP2 ISO Files
For specific installation steps, installation requirements, and overview information, see the .
When you start the upgrade process for the SP2 release, you need to upgrade all Access Manager components. When you have finished, use the following procedure to verify that all components have been upgraded to SP2.
In the Administration Console, click > >
Examine the value of the field and ensure that it displays the correct version.
The following sections briefly discuss the new features that were added between Access Manager 3.0 SP1 and Access Manager 3.0 SP2.
The use of Kerberos* for authentication is now supported.
Added a option to the > page that allows certificates to be re-pushed to keystores and trust stores.
Added full GZIP functionality. When the Web server sends compressed data and the rewriter needs to process the data, the data is decompressed, rewritten, and then recompressed. When Form Fill needs to process the data, the date is decompressed and then processed.
An LDAP OU condition has been added for Access Gateway Authorization policies.
The Identity Server now checks and reports on the health of its SSL port.
SSL VPN can now be configured to connect through forward proxy.
SSL VPN thin client can now be installed on a Macintosh machine.
Fixed an install issue that failed to identify which Administration Console was the primary Administration Console.
Fixed an issue with the evaluation of a policy that required all conditions in a policy to use the same comparison type (either case sensitive or case insensitive). This fix requires an update to the Identity Server and the embedded service providers of the devices.
Fixed a health status issue that allowed the health status to remain green when the secure port (8443) is no longer responding. The Identity Server now pings itself with an SSL request and reports the status of the secure port on the Health page.
Fixed a user store issue so that you can now use an eDirectory™ LDAP server as a user store when eDirectory has been configured to use Domain Services for Windows. This user store acts like an Active Directory* user store, so when you configure it, its Directory Type must be set to Active Directory for proper operation.
Fixed an issue that occurred when the ESP attempted to refresh the IDP authentication and the attempt failed. The session is now logged out so no additional retries take place.
Fixed an issue with the SAML2 POST profile. The SP did not have a location value to compare to the destination URL specified in the response.
Fixed Kerberos authentication so that the credential profile now returns the LDAP username and DN for LDAP credentials.
Fixed a certificate issue that caused parsing to fail for the CRL distribution point of an externally signed certificate.
Fixed an issue with the X509 class that caused the OCSP validation process to fail when the OCSP trust store included only the root chain.
Fixed an issue with the restore script that caused an out-of-memory error.
Fixed an installation bug that allowed the IP address of the primary and secondary Administration Console to be the same.
Fixed a security issue where direct URL access allowed users with fewer privileges to access certain pages.
Removed informational errors that occurred when backing up the Administration Console when Identity Server is installed on a separate machine.
Fixed the issue where secondary Administration Console would not install because of a failure to create certificates when DNS was not used.
Fixed HTML rewriting so that IP addresses are allowed in the and the .
Fixed HTML rewriting so that a back slash (\) is now allowed in an entry.
Fixed HTML rewriting so that a modification to a profile enables an Access Gateway update.
Fixed an XML validation error that was triggered when an HTML rewriter profile was modified.
Fixed an XML validation error that was triggered when the log push time was set to 12:00 p.m.
Fixed an XML validation error by adding an option to the Troubleshooting page that allows you to repair the XML.
Fixed a Pin List issue that now prevents entries with query stings in the URL.
Fixed a Pin List issue so that file extension entries cannot contain a path.
Fixed an issue with the option on the Web Servers page so that it displays the published DNS name of the proxy service.
Fixed an issue with vending correct data on a 304 response from the Web server when the data is compressed and cached.
Fixed a Form Fill issue that allowed attribute injection only when string constants were also injected
Fixed a Form Fill issue that allowed Form Fill to use cached credentials after the policy deleted stored values.
Fixed many issues that caused the proxy services to randomly restart.
The Linux Access Gateway now sends system down alerts to the Administration Console.
Fixed the rewriter data structure corruption issue.
The Linux Access Gateway now appropriately handles deflated compressed files.
Fixed issues with the reverse proxy service when there are more than 20 secondary IP addresses configured.
Fixed a phishing vulnerability threat that could have been caused by tampering with the login URL.
Fixed a problem in setting the cookie domain on server persistent cookies.
Fixed the order in which Linux Access Gateway sends certificates to the browser, when intermediate CA certificates must be sent.
Fixed issues with the health check of Web servers so a health check can be returned when the Web server is defined with a DNS name rather than an IP address.
Fixed issues with downloading large PDF files.
Fixed session timeout issues with Firefox when a long POST occurs.
Fixed issues with GroupWise® interoperability that resulted in failure to download files bigger than 128 KB when Form Fill was enabled.
Fixed HTTP processing so that it now supports the RPC_OUT_DATA and RPC_IN_DATA methods and forwards them to the Web server. This allows the Linux Access Gateway to support applications that are accelerated with RPC over HTTP.
Fixed an issue that prevented the tab from showing all the routes pushed to a client.
Fixed an issue that prevented a user from connecting to the SSL VPN server when the user had more than 27 traffic rules.
Fixed an issue that caused a 64-bit client machine to prevent traffic to the SSL VPN server.
Fixed an issue that made SSL VPN traffic appear to throttle, which caused slow performance.
Fixed an issue with enabling a logging profile that contained rollover and old file options.
Ensure that you synchronize the correct date, time, and time zone settings between the Identity Servers and Access Gateways servers. You must synchronize your servers to within one minute of each other. Otherwise, you encounter federation and session time-out errors. It is recommended that you use NTP for time synchronization.
Ensure that DNS names can be resolved.
Enable (allow) browser pop-ups for the Administration Console (administration server).
Network Address Translation routers cannot be placed between Access Manager components. All Access Manager components must be on the same side of a NAT router.
Image display problems can arise when an unprotected page references multiple protected resources. Best practices for HTML are that you avoid situations where an unprotected page contains references to multiple, automatically loaded protected resources. For example, the unprotected page index.html might contain references to two GIF image files. Both GIF files are protected resources. The browser automatically attempts to load the GIF files during the initial load of index.html. Because of multiple requests happening at the same time, one or more of the GIFs might be denied access. To avoid this, you should add the page and index.html as a protected resource. Doing this avoids the possibility of missing GIFs.
In rare instances, if Audit Logging is enabled, the Audit Logging sub-system can block all HTTP(S) threads on the machine for an extended period of time. Sometimes the blockage lasts 15 minutes and other times it lasts indefinitely. The result is that all system HTTP(S) threads become blocked and requests through Access Manager become extremely slow or stop processing.
To determine if this issue is happening and correct it:
On the machine in question, open a console window.
Execute the command:
ps -aux | grep java
This lists the Java* processes.
Locate the processes with classpaths that have nidp in the names. Each entry has a process ID number at the beginning. Locate that process ID number to use in the next step. If you are not sure which one to use, use all of them with nipd in the name.
Execute the command:
kill - QUIT <PID>
Where the <PID> value is replaced with the process ID obtained from Step 3. Do this for all process IDs obtained in Step 3.
Open the /var/opt/novell/tomcat4/logs/catalina.out log file.
Near the bottom of the file is a summary of all of the active threads on the machine.
Search the stack traces of the threads looking for any (or many) threads in the following:
com.novell.naudit.LogEvent.jniLogEventExt() com.novell.naudit.LogEvent.LogEventExt() com.novell.nidp.logging.NSureAuditLog.log()
If you see many threads in this location, there is an issue with blocked threads.
To solve the problem, reboot the machine.
This problem will be fixed in a future release.
If you use an Alteon* L4 switch and do not enable the sticky bit, you must turn on Direct Access Mode, which allows a client to communicate with any real server’s load balanced service.
If you reboot too many machines at the same time, some of the machines might report a configuration store error and not start. This problem resolves itself eventually, but it can take several hours.
To prevent this problem, reboot the cluster members individually, waiting until the rebooted machine has started before issuing the next reboot command. This is a known issue and will be fixed in a future release.
This section discusses known issues for the Administration Console.
Access Manager uses a modified version of Novell iManager, called the Administration Console. You cannot use standard iManager features or plug-ins with the Access Manager version of the product.
If you are running Access Manager in a VMware* ESX Server environment (ESX Server 3.0.2) and your Access Gateway configuration contains a path-based multi-homing reverse proxy with over 200 protected resources, you might experience an extended delay (five minutes or more) when viewing the configuration page for the proxy.
The Administration Console requires a GUI. The minimal SUSE® Linux Enterprise Server (SLES) installation does not install a GUI. You must install the Administration Console on a system on which you have installed a GUI.
If you enable SSL between the proxy service and the Web server and then modify the IP address of the Web server, an exception is thrown. Both the old IP address and the new IP address are displayed in the list of Web servers. Select the old IP address, then click . This bug will be fixed in the next support pack.
If you set up Access Manager to use an auditing server other than the one installed on the Administration Console, devices that are imported after this configuration do not receive the IP address of the auditing server. When the device is rebooted, it tries to send auditing events to the auditing server on the Administration Console.
To work around this issue after importing new devices, configure the auditing server to use the IP address of the Administration Console, then click . This saves the configuration to the Administration Console. Return to the Auditing page, reset the IP address to the address of the auditing server you want to use, then apply the configuration to all the devices imported into the Administration Console (use the links). After the configuration has been applied to the devices, reboot the devices.
For more information on how to change the IP address of the auditing server, see “Specifying the Logging Server and Events” in the Novell Access Manager 3.0 SP2 Administration Guide
The iManager version used in the Administration Console is not compatible with Identity Injection or Form Fill for single sign-on.
As long as the primary console is running, all configuration changes should be made at the primary console. If you make changes at both a primary console and a secondary console, browser caching can cause you to create an invalid configuration.
The following issues apply to the Identity Server:
When you create a user store on the Identity Server ( > ) and define it as an external Novell SecretStore® ( > > ) some attributes are not being created properly on the SAML affiliate object. The workaround is to access the user store configuration page ( > ), then exit. This action results in a check to verify that the schema, objects, and attributes exist, and it re-creates the affiliate object, if necessary.
The following affiliate objects must exist:
authsamlCertContainerDN (container holding trusted certificates, such as SCC Trusted Root.Security) authsamlProviderID authsamlTrustedCertDN (list of trusted certificates) authsamlValidAfter (180 seconds default) authsamlValidBefore (180 seconds default)
If these attributes exist, the system works normally, but your Identity Server and SecretStore server are not synchronized for time. If time sync is an issue, you can change the 180-second default validity times as a workaround.
When users are within the grace login limit, and a password expiration servlet is specified on a Name/Password or Secure Name/Password (form-based) authentication contract, they are redirected to the password expiration servlet to change their passwords. If the user does not update the password correctly, or escapes out of the page for any reason, the account is locked.
Currently, locking has not been implemented on the pages for modifying the Identity Server. If you have multiple administrators, they must coordinate with each other so that only one administrator is modifying an Identity Server cluster at any given time.
If you delete a User object in LDAP, the objects in the trust/configuration datastore related to that user can become orphaned. The system uses these objects for federated identity and user profiles. Currently, there are no known issues related to orphaned identity objects, but they might affect system performance. Orphaned user profile objects might also affect user lookup operations, and therefore you should remove them.
To do so, you first delete the user’s profile before you delete a User object, as described in the following steps:
In iManager or an LDAP browser, edit the attributes of the User object that you are going to delete.
Note the value of the User object’s GUID attribute (for eDirectory), objectGUID attribute (for Active Directory), or the nsuniqueid attribute (for SunOne*).
On the Access Manager trust/configuration datastore, locate any containers that use the following naming patterns:
cn=LUP*,cn=SCC*,cn=cluster,cn=nids,ou=accessManagerContainer,o=novell,cn=LibertyUserProfiles*,cn=SCC*,cn=cluster,cn=nids,ou=accessManagerContainer,o=novell.
Look for a child inside of these containers that is named by using the GUID noted in Step 3. There should only be one profile object for each GUID.
Delete that child profile object.
Repeat these steps for each User object that you want to delete.
Delete the User objects.
There are issues with the option. If there are already values in the LDAP attribute for X509 Subject Name mapping, and you enable for the X509 authentication class, the LDAP attribute values are overwritten with the client certificate subject name.
If the hardware of your Access Gateway fails and the Access Gateway is not a member of a cluster, you might receive the following message when you reinstall it:
Start unsuccessful. Reason: Unable to read keystore : /opt/novell/devman/jcc/certs/esp/signing.keystore.
If you receive this message, use the following process to solve the problem.
Add the failed Access Gateway to a cluster.
Ignore the pending status of this command.
Reinstall the Access Gateway with a new IP addresses.
Add the new Access Gateway to the cluster and make it the primary cluster server.
Delete the failed Access Gateway from the cluster and from the Administration Console.
(Optional) If you want the Access Gateway to use the old IP address:
Reinstall the Access Gateway by using the old IP address.
Add it to the cluster.
Make it the primary cluster server.
Delete the Access Gateway that is using the new IP address from the cluster and from the Administration Console.
Occasionally during an upgrade, the response to an upgrade command is lost, even though the command succeeds. This results in a pending status for the command, and this status is never updated to success.
To clear a pending command:
In the Administration Console, click > .
Click the link.
Select the pending command, then click .
Click .
Novell supports only UTF-8 encoding (UCS Transformation Format 8) and ISO 8859-1. Otherwise, Form Fill translations to the SSO data store cannot be guaranteed.
Both the Linux Access Gateway and the NetWare Access Gateway have the following issue when cancelling changes to certificate modifications:
If you make certificate changes on the Reverse Proxy or the Web Servers page, click the link and then cancel the changes on the Configuration page, the Reverse Proxy is configured with an invalid certificate. Return to the page and select the old certificate. As soon as you exit the page, the certificate is pushed to the device. Because you did not change the certificate, you do not need to restart the embedded service provider.
This section discusses the known issues that apply to the current release of the Linux Access Gateway.
Strip Path on POST data Does Not Work When the request is sent without the Content-Length Header
Single Machine Installation Is Not Supported for this Release
Linux Access Gateway Version Is Incorrectly Displayed on the Administration Console
YaST Goes into a Non-Responsive Mode When a Partition Is Deleted or Created by Using YaST
Web Servers That Do Not Support TLS and Do Not Fall Back to SSLV3 Are Not Accelerated
Linux Access Gateway Does Not Accelerate Netware 6.5 Pre-SP3 Web Servers
Cookies Set by JavaScript inside the Entity Are Not Rewritten
Rewriter Does Not Handle [ow], [w], and [oa] Options in Search and Replace Configuration
Form Fill Auto Submit Option Does Not Work with Multiple Forms on the Same Web Page
Form Fill Fails When a Policy Is Configured to Use String Constants
Form Fill Does Not Work if the Web Page Contains an Apostrophe
Form Fill Fails if the Web Server Does Not Send the Content Type
When reimporting a Linux Access Gateway with the initial configuration option, the health status displays the health of the previous configuration. You must apply changes from the Administration Console for health status to display the new configuration. Alternatively, you can enter the /etc/init.d/novell-vmc restart command from the command line to restart the Access Gateway. This issue does not happen when you reimport the proxy with the current configuration option.
When importing a Linux Access Gateway configuration, it is possible that the imported configuration contains an Audit server IP address that is different from the Audit server IP address that has been configured in the Administration Console. Updating the Linux Access Gateway configuration does not correct this address problem. As long as the addresses differ, the Access Gateway can hang during subsequent updates or restarts because the Novell Audit Agent of the Access Gateway cannot connect to its configured Audit server.
You must force the Linux Access Gateway to change its Audit server settings.
In the Administration Console, click > .
Specify a different IP address for the Secure Logging Server, then click .
Click , specify the correct IP address for the Secure Logging Server, then click .
Update the Linux Access Gateway.
Reboot every Access Manager machine, starting with the Administration Console.
If you have already configured the other Access Manager machines to use the correct IP address of the Secure Logging Server, rebooting the Linux Access Gateway should be sufficient.
Linux Access Gateway does not strip path on POST data, when the option is enabled and the POST request does not have a Content-Length header.
After upgrading, the embedded service provider sometimes is halted at the end of the upgrade process. When this happens, restart the Linux Access Gateway. In the Administration Console, click > , select the Access Gateway, then click .
This release does not support installation of the Administration Console, Identity Server, Linux Access Gateway, and SSL VPN on a single machine.
After the installation of Linux Access Gateway, the wrong version of the product is displayed on the Administration Console. To get the correct version of the product, select or specify the following command from a Linux Access Gateway machine:
cat /etc/issue
YaST goes into a non-responsive mode if you click after adding, deleting, or modifying a partition by using YaST. To work around this problem, click , then click instead of clicking.
During installation, if you configure the hostname as linux, the Linux Access Gateway is not imported.
The Linux Access Gateway requires both the Server Certificate and the Root CA to be present in the trusted roots imported from Web servers. If the trusted root imported from the Web server displays only the server certificate, select the option from the drop-down list when you are configuring SSL between the Proxy Service and Web servers. For more information, see “Configuring SSL between the Proxy Service and the Web Servers”.
The Linux Access Gateway uses the TLS protocol by default. However, some Web servers that do not support the TLS protocol abort the SSL handshake because they do not fall back to SSLV3.
To work around this problem, create the /var/novell/.doNotUseTLS touch file and restart the Linux Access Gateway. When this touch file is set, the Linux Access Gateway tries the SSLV3 protocol by default, instead of the TLS protocol.
The Web server closes the connection when the Linux Access Gateway sends the HTTP request to the Netware 6.5 pre-SP3 Web server, after the SSL handshake.
The Linux Access Gateway rewrites the path and domain only in those cookies that are set by using the Set-Cookie header. The cookies set by JavaScript* inside the entity are not rewritten by the Linux Access Gateway.
The character rewriter profile does not support the [w], [ow], and [oa] options to search and replace plain words and strings.
The option does not work. For example, if you add https://www.mygroup.com, it is not excluded from the list. You must provide only the DNS name, for example www.mygroup.com.
The Linux Access Gateway Form Fill fails to auto submit HTML pages with multiple <FORM> sections. For example, if you have an HTML login page, and the page contains two <FORM> sections as follows:
<HTML> <FORM name="form1"...> <INPUT name="username" type="text"...> </FORM> <FORM name="form2"...> <INPUT name="password" type="password"...> </FORM> </HTML>
Linux Access Gateway fills both the forms but does not auto submit them. To use the auto submit feature, there can only be one form on the page.
The Form Fill feature of Linux Access Gateway fails to fill the form when a policy is configured to use only string constants for all the input fields. However, Form Fill works when a string constant is used in combination with other input field values, such as credential profile.
Form Fill Auto submit fails when an input field in an HTML page contains name="submit".
The Linux Access Gateway Form Fill does not work if the Web page contains the apostrophe character.
Form Fill does not process the page if the Web server does not send the content type. Form Fill processes the following content types:
"text/html" "text/xml" "text/css" "text/javascript” "application/javascript" "application/x-javascript"
The NetWare Access Gateway embeds NetWare 6.5 SP6. The following topics are known issues for this operating system and the Access Gateway:
When you upgrade to Access Manager 3.0 SP1, the upgrade process disables mutual SSL between the proxy service and the Web servers.
To re-enable mutual SSL, select the on the Web Servers page. Click > > > > > .
The NetWare Access Gateway does not cache Form Fill data. Therefore, if you assign a Form Fill policy to a protected resource that uses a wildcard (*) in the URL path, the NetWare Access Gateway queries the Identity Server for Form Fill data each time a user accesses any page that matches the protected resource. It is strongly recommended that you specify a specific page when you assign a Form Fill policy to a protected resource.
The NetWare Access Gateway does cache Identity Injection and Authorization policy information for the lifetime of the user’s session, so the protected resources for these policies can use wildcards in their URL paths.
You can push commands from the secondary Administration Console, but any commands dealing with the Certificate Authority fail, unless you move the Certificate Authority to the secondary server.
Do not begin an Access Gateway server DNS name with a number.
In order to transfer files to and from the NetWare Access Gateway server when the SSH client that you are using for the transfer is configured with the Secure File Transfer Protocol (SFTP) enabled, you must load ncpip.nlm and enable NCP™ for the SFTP.
WARNING:Enabling NCPIP is a security risk because it opens a listener on port 524 on all bound addresses.
To set up and configure NCPIP, add the following to the tune.ncf file:
load ncpip.old SET NCP Exclude Addresses = ALL SET NCP Include Addresses = 127.0.0.1
In the BIOS you specify the modes to use for the IDEATA.HAM driver to work with a SATA controller. (Legacy or Compatible mode, and Enhanced mode.) You do not need to manipulate the driver or OS.
The IDESATA.HAM driver works with all AHCI controllers in pure AHCI mode, which is the recommended mode because it is the fastest. This driver is invoked instead of IDEATA.HAM only when the BIOS setting for the particular chip set is set to AHCI.
If you set up an X.509 contract and use it to authenticate from the NetWare Access Gateway, you might see an error generated in the Identity Server log for certificate or SSL mutual authentication. This occurs during SSL re-negotiation between Tomcat and the Internet Explorer* browser, and is possibly an IE bug. This error does not occur with Firefox. The Access Gateway can cause the error at the Identity Server by requesting the certificate authentication from the Identity Server, but it is not the only device that can cause the error. Any device requiring or requesting certificate authentication from the Identity Server, including the Identity Server itself, can cause the error. It is cosmetic.
NetWare abends can occur when Novell Remote Manager Group Operations are used on a NetWare Access Gateway. We recommend that you do not use Novell Remote Manager on a NetWare Access Gateway.
The following sections divide the known issues into general issues that apply to both the Enterprise mode and Kiosk mode and issues that apply only to the Enterprise mode and only to the Kiosk mode:
You must use the command line to restart an SSL VPN server. The and buttons in the Administration Console are not functional for this release. To restart the SSL VPN server, specify the following commands from the command line:
/etc/init.d/novell-sslvpn stop /etc/init.d/novell-sslvpn start
If the user does not have a traffic policy defined for the role, the user is denied access to the resources. However, the logout page is not displayed when user clicks the button.
The SSL VPN client randomly displays the dialog box, after the connection is established. Click to close the dialog box. If you do not click , SSL VPN disconnects. You can also follow the steps given below to resolve the problem if you are planning to use SSL VPN for a long session.
Open the Internet Explorer browser.
Select .
Select the tab.
Select , then click the button.
Select for the option.
Click .
The SSL VPN logout page is not displayed to you after you click the button when you use Internet Explorer 6.0 browser on a Windows 2000 machine to access SSL VPN in Kiosk mode. This issue does not occur when you access SSL VPN in Enterprise mode.
If you are a non admin user accessing SSL VPN through the Internet Explorer browser, the dialog box prompting you to specify the administrator username and password is not displayed. The SSL VPN connection is established in the Kiosk mode. If you are a non-admin user and want to access SSL VPN in the Enterprise mode, you must add the forcejre=true command to the end of the URL. For more information, see Section 21.1.1 Configuring SSL VPN to Download the Applet on Internet Explorer
in Novell Access Manager 3.0 SP2 Administration Guide.
If you use 64-bit machines, you can access SSL VPN only in Enterprise mode. Accessing SSL VPN in Kiosk mode is not supported.
After you have upgraded to the Novell Access Manager 3.0 SP2 version, if you roll back to the SP1 release, SSL listeners will not be created as there is a difference in the NICI versions used. To work around the problem, do the following with the SP1:
Untar lagrpms.tar.gz.
Remove the nici-<version>.rpm from the lagrpms directory.
Re-tar the lagrpms directory as lagrpms.tar.gz.
Use the new lagrpms.tar.gz for upgrading.
The Macintosh* Tiger* OS client does not support GroupWise 7.0.
In Linux, you cannot access protected HTTP traffic on the Firefox browser during the first SSL VPN connection, but subsequent connections work without problems.
To work around this problem, you can use another browser to access the protected resource as follows:
Establish an SSL VPN connection in the Kiosk mode.
Create a shortcut or launcher for Firefox on the desktop.
Click .
Log out of the SSL VPN.
Launch Firefox by using the SSL VPN-enabled shortcut.
The Firefox browser launches even though there is no SSL VPN connection.
Establish an SSL VPN connection in the Kiosk mode.
New tabs and new instances of the Firefox browser now tunnel HTTP traffic.
When you connect to SSL VPN in the Kiosk mode on a Windows Vista* machine, the browser goes into a non-responsive mode after you click the button.
The Intlclock toolbar application running on the SUSE Linux Enterprise Desktop (SLED) 10 SP1 crashes when an SSL VPN connection is established or disconnected.
In Linux, applications listed in the Program Menu are not SSLized.
Domain name search does not work in the Kiosk mode in Macintosh.
In SSL VPN Kiosk mode, the active mode of FTP is not supported.
If a client uses an HTTP forward proxy to establish the SSL VPN session, no HTTP application can be accessed over this SSL VPN connection because the browser is configured to use the forward proxy server for HTTP requests.
SSL VPN does not support 64-bit browsers to establish the initial login session.
SSL VPN certificate names can contain only alphanumeric characters, space, underscore (_), hyphen (-), the at symbol @, and dot (.).
On Windows 2000 machines, if a non-admin user tries to establish an SSL VPN connection in the Enterprise mode and specifies the wrong credentials for the admin user, no error messages are displayed. However, the user is denied access after trying to establish the connection.
The following are known issues for certificates:
In some combinations of Linux and Firefox, you might see the button display incorrectly in the Import Private/Public Keypair window. This does not affect functionality.
Certificate commands are generated when you upgrade the Administration Console, and you should ensure that they have completed successfully. In the Administration Console, click > > .
If a certificate command fails, note the store, then click > > . Select the store, then click to push the certificates to the store.
When upgrading a Linux Agent, you get an error on the Health page for the agent that says the ESP cannot read the signing.keystore file in /opt/novell/devman/jcc/certs/esp/<id>/ directory.
To correct this problem:
Remove or move the connector.keystore, signing.keystore, encryption.keystore, and truststore.keystore from the /opt/novell/devman/jcc/certs/esp/<id>/ directory.
Click > > > .
In the Keystore section, scroll to the agent certificates and select the Signing, Encryption, and ESP Mutual SSL certificates.
In the Trust Stores section, scroll to the agent trust stores and select the ESP Trust Store.
Click .
Click the link.
Select the agent.
Click > > .
No audit log events occur on 64-bit platforms. There is currently no workaround for the WebSphere* Agent. For the JBoss* and WebLogic* Agent, you can enable log events on 64-bit platforms by deleting the LogEvent.jar file and replacing it with the NAuditPA.jar file.
On Windows, the NAuditPA.jar file is located in Program Files\novell\Nsure Audit directory. On Linux, the file is located in /opt/novell/naudit/java/pa directory.
Delete the LogEvent.jar file in the server configuration lib directory (the location for the default configuration is the JBoss/server/default/lib directory). Copy the NAuditPA.jar file to this directory.
The LogEvent.jar file also needs to be deleted from the ESP directory (JBoss/server/default/deploy/nesp.ear/nesp.war/WEB-INF/lib). The NAuditPA.jar does not need to be added to this directory.
Linux: Edit the WL_HOME/common/bin/commEnv.sh file. Change the ${AGENT_LIB}/LogEvent.jar path variable to /opt/novell/naudit/java/pa/NAuditPA.jar variable.
Delete the LogEvent.jar file from the ESP directory (nesp.ear/nesp.war/WEB-INF/lib).
Windows: Edit the WL_HOME/common/bin/commEnv.cmd file. Change the %AGENT_LIB%\LogEvent.jar path variable to Program Files\novell\audit\NAuditPA.jar variable.
Delete the LogEvent.jar file from the ESP directory (nesp.ear/nesp.war/WEB-INF/lib).
In this documentation, a greater-than symbol (>) is used to separate actions within a step and items in a cross-reference path.
A trademark symbol (®, ™, etc.) denotes a Novell trademark; an asterisk (*) denotes a third-party trademark
Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.
Copyright © 2007-2008 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc., has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed on the Novell Legal Patents Web page and one or more additional patents or pending patent applications in the U.S. and in other countries.
For Novell trademarks, see the Novell Trademark and Service Mark list.
All third-party trademarks are the property of their respective owners.