The Release Notes for iPlanet Portal Server, Version 3.0, Service Pack 4 document important information available at the time of release.
These release notes contain the following sections:
Read this document before you begin installing Service Pack 4. For an online version of this and other Portal Server 3.0 documentation, see the iPlanet documentation Web site at:
http://docs.iplanet.com/docs/manuals/
After you install and start using iPlanet Portal Server 3.0, Service Pack 4, check this Web site periodically to view the most up-to-date documentation.
This section provides details about this document. It contains the following topics:
The following tables describes the typographic conventions used in this release note.
The following table lists the machine names used in code examples and the types of iPlanet Portal Server components to which they correspond.
Machine Name
Running as . . .
iPlanet Portal Server not being used as the profile server in multiple server installations
This section summarizes enhancements implemented in iPlanet Portal Server 3.0, Service Pack 1, Service Pack 2, and Service Pack 3a as well as in Service Pack 4.
See the "Authentication Changes" section of this document for details on these changes.
See the "Desktop and Provider Changes" section of this document for details on these changes.
See the "Gateway Changes" section of this document for details on these changes.
See the "Localization Changes" section of this document for details on these changes.
See the "Mobile Access Pack Support Changes" section of this document for details on these changes.
See the "NetFile Changes" section of this document for details on these changes.
See the "Netlet Changes" section of this document for details on these changes.
See the "Performance and Tuning Changes" section of this document for details on these changes.
See the "Profile Service Changes" section of this document for details on these changes.
See the "Server Changes" section of this document for details on these changes.
See the "Third-Party Software Changes" section of this document for details on this change.
See the "Webmail Changes" section of this document for details on this change.
This section provides details about authentication changes in iPlanet Portal Server. It contains the following topics:
The goto parameter is now available. It enables applications to instruct authentication to redirect the user to a URL other than the default URL stored in the user profile upon login or logout. It is valid for the current session only, and it does not change the default URL stored in the user profile.
To be redirected to a specific URL, the application must specify the goto parameter in the URL.
The goto parameter allows the calling application to specify where the user is redirected upon successful login.
For example, if an application wanted to redirect the user to my.sesta.com after successful authentication, the URL would be:
http://server1.domain:port/login?goto=http://my.sesta.com
An API developer can use the goto parameter in conjunction with the logout URL to specify where the user should be redirected upon logout.
For example, if an application wanted to redirect the user to sesta.com after logout, the logout link would be:
http://server1.domain:port/logout?goto=http://sesta.com
Authentication chaining can provide a higher level of security for organizations by requiring users to authenticate against more than one authentication mechanism. For example, if the membership and UNIX authentication modules are chained, desktop users would authenticate against both to access the desktop.
To set up authentication chaining, complete the following steps:
The user's default URL can now be set in the pluggable authentication interface, without changing the default URL in the user's profile. When the user authenticates successfully, the user is redirected to this URL.
A new method called setDefaultURL in the pluggable authentication API allows the authentication modules to set the user's default redirect URL on successful authentication:
To use this, replace the setDefaultURL parameter with the user's default URL. This is an example of setting the default URL to www.sesta.com:
public void setDefaultURL("http://www.sesta.com")
Tip
This method overrides the goto parameter. See "Using the goto Parameter."
Portal Server now contains a membership authentication module that is useful for open portal installations. Combined with anonymous user, unregistered users can view non-personalized content in a portal, and registered users can log in and view personalized content.
The addition of a login channel on the desktop allows registered users to access the portal, register and receive personalized pages. It allows non-registered users to view static content.
The login channel also allows the user to enable persistent cookies, if the domain allows this option. Persistent cookie support puts user login information into a cookie so that the user does not have to log in for subsequent sessions.
The user interface for the login channel does not have an edit page, as user-editable preferences are not available.
In a typical anonymous installation, the anonymous authentication module would be the only authentication type enabled. When the URL http://server.domain:port/login/domain is specified, the user's browser displays the anonymous user desktop. No user input, other than the URL, is required.
A list of user IDs authorized to log in to the anonymous user's desktop can be specified and modified through the administration console.
When a user ID appears in the List of Anonymous Usernames, access to the anonymous user's desktop is granted. The session is assigned to the specified userID. When user ID does not appear in the List of Anonymous Usernames, the session is assigned to the user ID specified in the Default Anonymous Username field and the anonymous desktop is displayed.
To change the default anonymous user name, complete the following steps:
To define the default anonymous user name, complete the following steps:
Use the administration console to enable an anonymous desktop using the Anonymous Authentication Module and Login Channel.
To enable the anonymous desktop, complete the following steps:
Portal Server is now defaulted to the Anonymous authentication module in all cases and displays the anonymous desktop by default.
This enables users to use the login channel to use Membership authentication instead of having to use the provided membership login page.
You can customize templates for the anonymous desktop by editing the menubar.html file and changing settings in the administration console.
To customize a user logout from the desktop redirect to the anonymous user desktop, complete the following steps:
Use this format to set the logout from the desktop to be redirected to the anonymous desktop in all cases:
Tip
To customize the Help page for the anonymous desktop, complete the following steps:
The default English locale value in Front Page Help is assumed to be relative from the /opt/SUNWips/public_html/docs/en_US/online_help directory.
To create an anonymous user for any other domain, complete the following steps:
To disable anonymous desktop, complete the following steps:
The login channel can be modified to work with other authentication modules. A sample template is available to illustrate how the login channel can be changed to work with the Unix authentication module, rather than the Membership authentication module.
To enable Unix authentication for the login channel, complete the following steps:
When replacing files to modify the operation of the desktop, make copies of the files being replaced, first, so that they can be reinstated at any later date.
Note
The login channel now uses UNIX authentication.
The template file, display_iwtAuthUnix.html, is an example of how templates could be created to enable other authentication modules for the login channel. The contents of the built-in login page for a given authentication method provide an example of the correct parameters to include in the display.html template.
When a registered user authenticates from the anonymous desktop, Portal Server obtains information about the user and presents the user desktop from the user profile. When a new user registers from the anonymous desktop, the user's current session from the anonymous desktop is destroyed before the auth module in the URL for the user's default desktop is called.
This allows a user with a valid iPlanet Portal Server session to directly go to a login module without sending a logout URL. For example, a login channel sends the following URL to allow an anonymous user to register with the membership module:
http://server.domain:port/login/Membership?domain=/mydomain&arg=newsession
The arg=newsession parameter instructs the authentication module to destroy the current session before calling the authentication module in the URL.
Previously, if a user wanted to switch from anonymous user to registered user, it was impossible to authenticate the user using another authentication module such as the Membership module since an anonymous user has a valid session.
Users can now change their membership login passwords.
To change the membership login password, the user must complete the following steps:
Password checking is subject to the same rules as the membership authentication module. The user must authenticate via Membership for changes to the Membership password.
A user's email address can now be used as the user profile ID on the certificate. When the email address is selected, the cert auth module searches for the emailAddr field in the certificate's user subject dn field for the attribute tag emailaddr and uses its value to access the user's profile ID.
The tag emailAddr is stored in the iwtAuthCert.properties file. It can be replaced with a different value, depending on the site or the certificate issuer.
To use the email address as profile ID, complete the following steps:
Persistent cookies are now supported. If the persistent cookie mode is enabled, the user:
If the user explicitly logs out when persistent cookie mode is enabled, logging in is required on the next visit.
Note
To set up persistent cookie mode for an individual user, the user must select the Remember My Username and Password check box using the Login Channel.
Administrators can set a persistent cookie for a domain. To do this, complete the following steps:
This section provides details about desktop changes in iPlanet Portal Server. It contains the following topics:
The JSP Provider allows you to use JavaServer Pages technology to write providers for desktop channels. JSP Provider-based channels have the following attributes in addition to the attributes of other channels:
The contentPage and editPage JSP specifications can be used in various combinations. For example, you can use a JSP specification to generate content while you can use Java code in the provider class to generate the edit page. Both have access to iPlanet Portal Server platform services.
Processing of the edit form consists of Java code that checks validity of the form entry and updates user preferences for the channel. The result is a display of the desktop in the case of success or a display of the edit page in the case of a failure, possibly with some error information for the user.
To handle the processing of an edit form, the JSP-based provider has these options:
Support for JSP-based channels is provided through a class called JSPProvider. The JSPProvider extends the ProfileProviderAdapter class to support other attributes for the channel by using the profile service.
When specifying a JSP in one of the JSP attributes, the path name is interpreted relative to the desktop template directory using the same algorithm as for other desktop templates, including the locale setting.
If the user's locale is de_DE, the desktop type is SunBlue, and a JSP attribute is set to myChan/chan.jsp, the system would search for these JSP files:
/etc/opt/SUNWips/desktop/SunBlue_de_DE/myChan/chan.jsp
/etc/opt/SUNWips/desktop/SunBlue_de_DE/chan.jsp
/etc/opt/SUNWips/desktop/SunBlue/myChan/chan.jsp
/etc/opt/SUNWips/desktop/SunBlue/chan.jsp
/etc/opt/SUNWips/desktop/default_de_DE/myChan/chan.jsp
/etc/opt/SUNWips/desktop/default_de_DE/chan.jsp
/etc/opt/SUNWips/desktop/default/myChan/chan.jsp
/etc/opt/SUNWips/desktop/default/chan.jsp
For more information on implementing JSP-based channels, see the Javadoc software shipped with Service Pack 4.
Tip
When the desktop accesses templates to generate content, it reads them from disk and caches them. All subsequent requests for the template are served from the cache.
The desktop periodically checks to see if the disk files have been updated. If the disk file is newer than the cache, the template is re-cached based on the updated disk file.
The length of time between checking to see if the disk files have been updated is the template scan interval. This interval can now be changed in the administration console. Changing the template scan interval causes the desktop to immediately check for changes to the disk files and then wait for the new interval value before re-checking again.
To change the template scan interval, complete the following steps:
The default value for the template scan interval is 900 seconds, or 15 minutes.
Tip
The desktop can now use tabs to organize content. Tabbed desktop pages can be individually modified to customize the desktop.
The tab feature must be turned on for any given domain. By default, it is not active. The super administrator must enable the Tab Provider and then configure or remove tabs in a chosen domain.
To enable desktop tabs in a particular domain, complete the following steps:
name=new tab|channels=iwtTabProvider;iwtUserInfoProvider;
iwtIPInfoProvider;iwtSampleRss|desc=new tab description|
removable=true|renamable=true
name=Make From Scratch ...|channels=iwtTabProvider;iwtUserInfoProvider;
iwtBookmarkProvider;iwtIPInfoProvider|desc=Design a tab from the ground up|
removable=true|renamable=true
Users can configure the tabs on their desktops. The tab's channel edit page allows users to create, rename, or remove tabs from their desktops. In addition, users can select which tab should be present on the initial desktop page.
To configure tabs, the user must complete the following steps:
In the Edit Tab Provider page, the user can use a predefined tab content template by topic, or by choosing each channel for the new tab manually.
To create custom tabs, the user must complete the following steps:
During configuration of desktop pages and layout, the administrator uses the administration console to determine which channels are thin and thick.
Tip
To create a default content for a tab, the user must complete the following steps:
Desktop tabs can now be aligned from the left side or the right side of the desktop. By default, tabs are left-aligned.
To use tabs, the super administrator must enable the Tab Provider and then configure or remove tabs in a selected domain.
To change to right-to-left ordering of desktop tabs, complete the following steps:
The Provider API now allows a channel to return either a complete HTML edit form, or a subset of a complete HTML page in response to a request for the edit page.
Integer constants are added to the Provider interface that return values from the getEditType() method. These integer constants define the form type, return type, from the getEditType() method:
New methods query and set the form type.
The desktop uses the getEditType() method so that it knows to expect either a complete or subset HTML form to be returned when calling channel.getEdit().
These restrictions apply to what can be returned from getEdit() when the edit type is equal to EDIT_COMPLETE:
For channels that extend the ProfileProviderAdapter class, a new attribute can be defined in the profile component:
The default value is different for each provider. Variations to this might include turning off write permission for OWNER, if one or the other edit type was not implemented.
All iPlanet Portal Server default channels return Provider.EDIT_SUBSET. Modifying the -editType attribute causes a malfunction. A new channel must return Provider.EDIT_SUBSET, or Provider.EDIT_COMPLETE depending on how the getEdit() method is implemented.
Administrators can now lock a channel's position so that the user cannot change its position or remove it from the desktop. The purpose is to force the user to see particular content.
The Layout page that allows the user to arrange channels on the desktop does not list locked channels.
To lock a channel's position, complete the following steps:
If you select the Movable check box, the user can move channels around in the desktop.
Tip
If you select the Removable check box, the user can remove channels from the desktop.
Tip
To unlock a channel's position, complete the following steps:
If you select the Movable check box, the user can move channels around in the desktop.
Tip
If you select the Removable check box, the user can remove channels from the desktop.
Tip
The Portal Server desktop can now display full-width channels. A full-width channel spans the width of the desktop, either at the top or bottom.
To configure a full-width channel, complete the following steps:
The Portal Server desktop can now display unframed channels. A frameless channel is one that is displayed without a title, controls, and a border or frame.
To configure a frameless channel, complete the following steps:
If the Framed? check box is selected, the channel is displayed with a title, controls, and border.
Tip
To modify just the border of the channel, edit the hasBorder attribute in the Policy page.
Note
The Login Provider Channel template files now use the POST method for improved security when submitting the login forms. This change provides the choice of using the POST or GET methods in customized login channels.
Using the POST method is more secure because it prevents the password from showing up in the server logs, URLs and bookmarks.
The URL scraper can now forward cookies passed in the HTTP request to the desktop. That is, the URL scraper sends cookies when it makes a connection to the target site to retrieve the content it is scraping. The URL scraper also sends set-cookie requests to the browser. That is, it gets all cookies from set-cookie headers and adds them to the HTTP response to the client browser.
By default, no cookies are forwarded. For the affected domain, role or user, the administrator must use the administration console to set the list of cookies to forward.
To forward cookies, complete the following steps:
Using multiple cookies differing only in path or value is now supported. This is useful when managing non-iPlanet Portal Server cookies passed to other Web applications.
If the cookie is in a different domain from the server (for example, if scraping a page to the iPlanet Portal Server desktop that sets its own cookie), complete the following steps:
Use this format to add the domain name:
Note the . that precedes the name.
Tip
If the cookie is set from the same domain as the server, complete the following steps:
Providers can now access HTTP request and response headers. This change is desirable for single sign-on, setting cookies, getting parameters from the HTTP headers, and for inserting data into the headers.
Three new methods in the Content Provider interface are available to provide this. The methods are:
These methods in the ProviderAdapter and ProfileProviderAdapter classes call the getContent, getEdit, and processEdit methods.
The HttpServletRequest and HttpServletResponses objects passed to the new methods have the following indicated methods and return values:
The session time out unit of measurement is now in minutes.
To set the session time-out to the maximum possible value, complete the following steps:
NetFile and NetMail applications now work on a Macintosh similarly to the way they work on other supported platforms.
The Netlet application, when used on a Macintosh, however, does not support the dynamic loading feature. If the Netlet is enabled, Macintosh clients automatically load the Netlet when the Netlet Channel is enabled on the desktop.
Table 4 lists the minimum system requirements for running the Netlet, NetMail, and NetFile applications on Macintosh clients.
Component
Description
This section provides details about gateway changes in iPlanet Portal Server. It contains the following topics:
Gateway logging is now disabled by default because logging traffic between the gateway and the server can affect portal performance.
Administrators can use the administration console to enable gateway logging.
To enable gateway logging, complete the following steps:
In the following instructions and examples, /opt is the default installation directory.
Note
The entries in this list are the names of the JavaScript variables which are in turn expressed in JavaScript, and which is rewritten by the gateway.
The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Variables in JavaScript list.
If the list has the following entries:
The gateway tries to rewrite the right-hand sides of both jsvarjs1 and jsvarjs2.
The gateway wraps the matched parameters with a function called iplanet, which does the actual rewriting when the browser interprets the page.
The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Function Parameters Function list. This is the syntax for entries in this list:
java_script_function_name: [y|], [y|], ...
The gateway rewrites JavaScript variables or JavaScript functions according to existing rules specific to that variable, or function, in the gateway profile.
The gateway tries to rewrite the matched parameters. A matched parameter in JavaScript is either in the form of a JavaScript variable or a JavaScript function.
The iPlanet Portal Server administration console's Gateway Profile page contains the Rewrite JavaScript Function Parameters list. Each entry in the list has the following syntax:
java_script_function_name: [y|], [y|], ...
The gateway tries to rewrite func2 and var3.
Administrators can now use the administration console to edit the Rewrite Applet/Object Parameter Values list on the Gateway Profile page.
This is the syntax for entries in this list:
If the gateway receives this request for the URL:
If the Rewrite Applet/Object Parameter Values List contains the following example entries, the corresponding URLs is rewritten as noted in Table 5.
A new attribute allows administrators to deny unknown certificate authorities (CAs). The ips.gateway.trust_all_server_cert attribute is in the /etc/opt/SUNWips/platform.conf file. It is used when the Portal Server gateway component uses SSL to communicate with:
See "Adding a Root CA Certificate" for instructions on installing a Root CA certificate.
Tip
The default value of this attribute is false. Administrators should change the value to true to trust all CAs presenting signed certificates to the gateway component during an SSL handshake. For example:
ips.gateway.trust_all_server_certs=true
Typically, the Root CA certificate should be added to gateway certificate database so that the gateway component can identify the certificate presented. However, if a site presents a self-signed certificate, setting the ips.gateway.trust_all_server_cert attribute to true allows the iPlanet Portal Server gateway component to communicate with the site presenting the unknown certificate.
If the gateway does not recognize the certificate that is presented, and if the ips.gateway.trust_all_server_cert attribute is set to false, this error is generated:
A new parameter now allows administrators to specify the number of times the iPlanet Portal Server gateway tries to make a socket connection to a destination server should the first attempt fail. The ips.gateway.sockretries parameter is in the platform.conf file.
To specify the number of times the gateway tries to make a socket connection, edit the platf `orm.conf file in /etc/opt/SUNWips and change the ips.gateway.sockretries definition. For example:
The Outlook Web Access (OWA) 2000 application can now be used with the iPlanet Portal Server gateway component. To do so, enable basic authentication for your server.
NTLM authentication is not supported.
These attribute settings in the iPlanet Portal Server administration console are no longer used:
These settings appear in administration console on the Manage Gateway Profile page, but they do not function. The information in the "IP address validation" section in Chapter 8 "Configuring the Gateway" of the iPlanet Portal Server 3.0 Administration Guide no longer applies.
This section provides details about localization changes in iPlanet Portal Server. It contains the following topics:
The administrator can now specify the locale for domains, roles, and users. A single Portal Server installation with three locale packages installed, for example, allows the administrator to set up three domains, one for each locale. Users registering in domain1 use locale 1. Users registering in domain2 use locale2 and so on.
When you install a new locale, you must run the ipsadmin command to update the iwtPlatform attribute. The iwtPlatform-availableLocales attribute lists all the locales available for the user. For example:
Although values for this attribute are en_US or ja_JA, for example, users see only the common name of the available locale English or Japanese.
To specify the locale for domains, complete the following steps:
Users can now select their own locale from a list of locales available.
The provider displays the list of languages to the user. After the user makes a selection, it stores the selection in the user profile. The user must then log in again to get the new locale.
To select locale, users complete the following steps:
This feature allows the user to see the changes in the locale of choice.
When editing the profile, for channels created with the channel wizard in a non-English locale, the administrator now sees the choices translated in the chosen language of the locale.
A new properties file was added to localize the default desktop's JSP Provider's title and description. The file, iwtSampleJSP.properties, is in /opt/SUNWips/locale.
This change is visible in the Desktop content provider list as the title and description and also on the desktop channel title bar as the title.
To change the values of the JSP channel title and description, edit the iwtSampleJSP.properties file and change the description and title entries to display the desired text. For example:
Other entries in the file are used in the administration console for this provider. They are not displayed for the end user. These values align with the idx values in the attributes of the XML files.
A copy of the JSP Provider properties file is created specifically so that you can create your own JSP property file for different localizations. In the file, locale specifiers are used as suffixes for locale-specific files. For example:
When a user creates a JSP Channel using the Channel Wizard, no properties file is created for that channel. The default property file for a newly created JSP channel is the iwtJSPProvider.properties file, but this file cannot be customized.
To customize or localize the title and description of the newly created JSP channel, complete the following steps:
The entries other than title and description in this file are unused, because newly created JSP channels get their admin strings from the iwtJSPProvider.properties file. They all share the same strings and would all be edited or localized at once.
This section provides details about changes in iPlanet Portal Server for supporting iPlanet Portal Server: Mobile Access Pack 3.0. It contains the following topics:
A generic file path search API is now available for all data file types to support the iPlanet Portal Server: Mobile Access Pack architecture.
All components use the same API for file lookup, including desktop template lookup and JSP file lookup.
This file lookup API uses a combination of attributes to create a list of file paths to search. These attributes include:
For information about the attributes, see "Appendix A" of the iPlanet Portal Server: Mobile Access Pack Programmer's Guide.
Tip
This example of the file path search API asks for file name foo.template with these values:
The File Lookup API searches the appropriate paths and returns the first file encountered, with its given file name.
In the Mobile Access Pack architecture, each channel is responsible for identifying itself as able to present content for a particular client type. Each channel has access to the client type via the session, and is therefore capable of making the decision as to whether it supports the output format for this client type.
A channel determines if it is presentable by indexing the client data based on the client type stored in the iPlanet Portal Server 3.0, Service Pack 4 session. The channel can use any of the client data elements to determine whether it is presentable. For example, in the simplest case the channel may determine that it only supports clients where:
Each channel must be asked whether it supports the client type before output is gathered and returned to the user. So for each place in the desktop core where content is gathered, the channel generating the content must first be asked if it can produce this output format.
An iPlanet Portal Server 3.0, Service Pack 4 channel can generate content from two methods:
The Provider.getContent() returns the main channel content. The Provider.getEdit() returns an edit page for the channel.
A channel is able to signal the desktop that it supports output of the main content or the edit page separately for different devices.
A new Provider API method answers whether the channel can return main channel content for the particular client:
public boolean isPresentable();
The isPresentable() method is part of the Provider interface and is implemented in the ProviderAdapter.
This section provides details about NetFile changes in iPlanet Portal Server. It contains the following topics:
File Transfer Protocol (FTP) support for NetWare File Systems through the NetFile and NetFile Lite applications is now available.
The administrator uses the administration console to add a NetWare File System to NetFile applications. This allows users to use NetFile in the same way they do for any other host type.
To add a NetWare File System, complete the following steps:
The administrator uses the administration console to add a Novell file system to NetFile Lite applications. This allows users to perform NetFile functions by using the check boxes next to the file names and selecting an action using a button at the bottom of the page.
To add a Novell file system, complete the following steps:
Administrators can now define Systems and Shares for NetFile and NetFile Lite at the domain, role and user levels. By setting common host data attributes, administrators can define systems and shares to be displayed in the end user's Network Neighborhood.
These NetFile profile attributes changes were made to allow this:
To define Systems and Share at the domain level, complete the following steps:
Applying changes to subroles may overwrite customizations done further down the tree, for example, at the user level.
Note
To view the defined systems or shares in NetFile, the end user must complete the following steps:
To define Systems and Share at the role level, complete the following steps:
End users cannot delete defined hosts and shares, even if they remove them and choose to save their session upon exit.
Note
To view the defined systems or shares in NetFile, the end user must complete the following steps:
To define Systems and Share at the user level, complete the following steps:
End users cannot delete defined hosts and shares, even if they remove them and choose to save their session upon exit.
Note
To view the defined systems or shares in NetFile, the end-user must complete the following steps:
Administrators and desktop users can now define NT hidden shares for use in NetFile. The Common Host Data attribute allows administrators to define NT hidden shares through the administration console.
The procedure for defining hidden shares through the administration console is the same as that for defining regular shares. Desktop users can add hidden NT shares the same way they would add a regular share, as long as they use the correct user name and password for the hidden share.
For administrators and user instructions, see "Defining Systems and Shares at the Domain Level."
Windows NT shares in NetFile are now alphabetized. Because all shares on a Windows NT system are automatically displayed when a user selects a system name, alphabetizing the list of shares makes locating the desired share easier.
Several NetFile enhancements now make NetFile easier to use. These include the following:
This section provides details about Netlet changes in iPlanet Portal Server. It contains the following topics:
The Netlet now supports an unlimited number of connections per Netlet. This rule change is beneficial if an application running through the Netlet requires many connections per Netlet.
Secure remote FTP transfers from an end user system to an FTP server are now provided through a Netlet connection. Without a user name, an FTP URL is interpreted as an anonymous FTP connection.
Administrators can use static or dynamic Netlet rules to set up FTP service to a single FTP server. Static rules define the FTP server that is used to transfer files. Dynamic rules allow the user to specify the FTP server.
Table 6 describes netlet rules and provides their formats.
Purpose
Type
Format
Rule in which the user logs in to the FTP server as an anonymous user
Rule in which the user logs in to the FTP server with a user ID
This Netlet enhancement requires creating a Netlet rule that listens for FTP requests. To create a static FTP Netlet rule for the Default Role, complete the following steps:
The Netlet proxy is used for these reasons:
To configure the Netlet proxy, complete the following steps:
To determine whether the port desired is available and unused, enter this command from the command line:
Tip
Administrators can use the command line interface to configure an automatic restart of the Netlet proxy whenever the system server is rebooted.
To start the netlet proxy automatically when the machine is rebooted, execute these commands as root:
These steps do not automatically start the netlet proxy when you use ipsserver start to restart iPlanet Portal Server 3.0, Service Pack 4.
Note
Administrators can now change the contents of Netlet windows by editing the files that store the values for these messages.
To change the message displayed in the interim status window that lets the user know when the Netlet has finished loading, modify the nc3 value in the install_dir/SUNWips/locale/iwtNetletServlet.properties file. For example:
To change the message displayed in the status window when a static rule has been defined for the current user, modify the Netlet-Provider-wait value in the iwtNetletProvider.properties file. For example:
To change the messages displayed when a Macintosh client attempts to use an automatic proxy configuration file, or when the Netlet cannot determine the Macintosh browser's proxy settings, modify values in the iwtNetletApplet.properties file. For example:
ppd.2=Netlet was unable to determine your browser proxy port setting.
ppd.3=Please enter your browser Proxy Port setting below:
pwarn.3mac=Netlet was unable configure your browser proxy settings. In your browser's Preferences->Network->Proxies section:\n\n - add these entries to the 'List of sites that you want to connect to directly':\nlocalhost\n\127.0.0.
To change the message displayed when the Netlet is started from a link within the Netlet channel itself rather than being launched following a successful login, modify the iwtNetletServlet.properties file. For example:
The nc4 value and the contButton value are displayed in the intermediate status window.
The Netlet applet can be used with Web browsers that are configured to use automatic proxy configuration (PAC) files. The automatic proxy configuration feature is supported in the Netscape Navigator and Internet Explorer browsers.
In addition to using automatic proxy configuration (PAC) files, Internet Explorer can also use an .ins automatic configuration file for automatic proxy services.
If end users are using .ins files for automatic proxy purposes, the .ins file must contain an entry for AutoConfigJSURL so that the Netlet can read proxy settings correctly. The value for the AutoConfigJSURL is a URL that points to a valid PAC file. For example: AutoConfigJSURL=http://sesta.com/corp.pac
This section provides details about performance and tuning changes in iPlanet Portal Server. It contains the following topics:
Netscape Security Service (JSS) version 2.8.4 to version 2.8.6 is now supported on the gateway component. This increases the number of HTTPS operations that the gateway component can sustain.
Certificates installed for the previous SSL library are automatically converted to the format required by NSS when Service Pack 4 is installed. However, certificate management for the gateway component is different from previous releases of the iPlanet Portal Server software. For more information on gateway certificate management see, "Web Server Performance."
For better performance under load, administrators can increase the value of the Maximum Thread Pool Size parameter to 500. The default value is 200.
To increase this value, complete the following steps:
A new method called Profile.loadAttributes for loading multiple attributes in one profile request is now available. It is used to pass a set of attribute names that can contain wildcards for multiple profile components.
The parameter name is attributeNames. The value is a set of attribute names that can contain wildcard characters.
The returned attribute values are cached in the profile object. This allows a subsequent call to retrieve these attributes faster, thereby improving overall Portal Server performance.
Short-circuiting for session and logging requests reduces the number of HTTP requests for logging and session services and eliminates XML parsing for these requests. This improves the overall performance of iPlanet Portal Server.
If the logging client and the logging server are in the same JVM, the HTTP connection is bypassed during client and server communication.
Likewise, if the session client and the session server are in the same JVM, no HTTP connection is needed for them to communicate.
Adjusting iPlanet Web Server parameter settings can improve the performance of the gateway component. Table 7 describes these parameters. These configuration files are located in the install_directory/netscape/server4/https-server/config file.
This section provides details about profile service changes in iPlanet Portal Server. It contains the following topics:
A separate profile service is now used for each Portal Server instance. The profile services are synchronized with each other to keep all modified profile data current. Previously, all Portal Server instances in a deployment used a single profile service. This was a potential single point of failure.
Profile requests originating at any Portal Server instance are now directed to the profile server of that Portal Server. Each Portal Server instance communicates directly with the Directory Server. Performance and scalability for simultaneous logins are improved because all profile requests go directly to LDAP without XML-to-LDAP overhead.
Multiple directory servers are not supported at this time.
The LDAPMonitor object now checks for LDAP connectivity. If it finds a lost connection, it removes all connections from its LDAP connection pool and lets the profile service create the LDAP connection as needed. The first profile service requesting an LDAP connection would then refill the connection pool.
Administrators can use directory.monitor.sleeptime, a new parameter in the etc/opt/SUNWips/properties.file, to define the length of the sleep interval, which is 30 seconds by default.
This is the format of the parameter:
directory.monitor.sleeptime=sleeptime_in_milliseconds
To set the interval to 40 seconds, for example:
directory.monitor.sleeptime= 40000
Tip
Two new methods called setUserSessionProperty and getUserSessionProperty in the pluggable auth API enable authentication modules to get and set properties in the user session. They allow authentication modules to communicate with channels, applications, or other authentication modules by setting session properties.
A custom authentication module may add the user password to the session, so that an application can retrieve this property, for single sign-on at a later time.
The parameter name is the property name, and the parameter value is the property value in this example:
The parameter name is the property name and this returns the property value in this example:
This section provides details about server changes in iPlanet Portal Server. It contains the following topics:
iPlanet Portal Server can now be deployed without the services of the gateway. Running without the gateway is referred to as open portal mode. One iPlanet Portal Server installation can be configured to support both open and secure portal modes.
The services presented by the open portal typically reside within the DMZ, not within the secured intranet. If a portal provides public information and allows access to free applications, using open portal mode allows Portal Server to respond faster to access requests.
Using the iPlanet Portal Server in open portal mode may improve the individual response of the portal for a large number of simultaneous users.
Tip
The following Portal Server features are provided by the gateway component and are thus not available when running in open portal mode:
If a user is restricted from either running the desktop or adding specific channels within the desktop, for example, this type of policy is still enforced.
The typical public portal uses HTTP. You can now deploy a portal using HTTP over SSL (HTTPS). You can configure Portal Server to run HTTPS services during installation, or you can manually change from HTTP to HTTPS after installation.
See the iPlanet Portal Server 3.0, Service Pack 4 Administration Guide for more information on using SSL.
The user accesses the server directly as though the server is configured for HTTP, but uses the URL https://server.domain instead of http://server.domain.
To update Portal Server to open portal mode following installation, complete the following steps:
The rules for logging in to the open Portal Server include the following:
In a portal setup without the gateway, this feature provides support for SSL (HTTPS) server for user registration although the sites run without SSL (HTTP).
All registrations and logins now can be directed to an HTTPS server, while all desktop redirects are sent to an HTTP server. The iPlanet Portal Server supports this configuration by running two instances of iPlanet Portal Server. One instance runs HTTP, and the other instance runs HTTPS.
After you set up the server instances, you convert the second instance of the server to SSL. After configuring the second instance, you update user profiles to redirect users to the non-SSL server after authentication. See "Multi-Profile Server Support" for detailed information on setting up two instances of iPlanet Portal Server.
To ensure that all unauthenticated sessions on the non-SSL server are redirected to the SSL server, you must edit the platform.conf file in /etc/opt/SUNWips/ directory and then set the user profile to point to the non-SSL port on the open portal.
To do this, complete the following steps:
ips.nosession.url=https://server.domain:port/login
Replace server with the host name of the SSL server and port with the port number where the server is running. For example:
ips.nosession.url=https://server1.sesta.com:8081/login
Tip
If you have multiple iPlanet Portal Server server instances, you must edit the platform.conf file associated with each instance.
<FORM ACTION="https://server1.sesta.com:8081/login/Membership" onSubmit="return checkBlank()" MET
HOD=GET NAME="userid_form" ENCTYPE="application/x-www-form-urlencoded">
<FONT FACE="[tag:iwtDesktop-fontFace1]" SIZE="-1"><A HREF="https://server1.sesta.com:8081/login/Membership?arg
=newsession&page=1&Submit=New%20User">Sign Me Up</A></FONT>
For information about changing multiple instance servers to SSL in open portal mode, see "Changing Created Multiple Instance Servers to SSL."
Note
Some rewriting facilities that were only in the Gateway Component Profile are now available with the server. This allows administrators to configure parameters for URL scraping in open portal mode. These parameters include:
When the open portal mode is installed, the selections on the Gateway Component Profile page are not disabled even though most selections are disabled because no gateway is running.
To view this and observe the impact, in the administration console, do the following to access the Gateway Component Profile page:
iPlanet Portal Server now supports using a load balancer in open portal mode. The load balancer must support persistent connections, sometimes referred to as sticky sessions based on cookies. If the load balancer supports persistence based on a cookie name and value, this feature must be enabled.
If the Portal Server environment includes a load balancer, and a URL scraper channel that references material from a server other than the iPlanet Portal Server, that material is looked up from the server on which it sits. For example, server names in an image's URL are visible in the browser's page information window, and the browser accesses those images without using the load balancer.
The load balancer must be able to recognize the cookie on the first reply from portal. It should then continue to send all requests with that cookie name and value to that same server. Cookie persistence algorithms that do not recognize the cookie on the reply do not work, because the first and second request can end up on different servers.
If the load balancer does not support this type of cookie persistence algorithm, but it supports load balancing to specific servers based on the presence of a cookie name and value, the administrator can edit the appropriate platform.conf file to configure cookie values on each server.
Each server defines a special cookie that the load balancer is configured to recognize and always forwards requests with that cookie to that specific server. Each Portal Server instance sets this cookie along with the usual portal session cookie.
Cookies can be used to establish session persistence between some load balancers and servers in an iPlanet Portal Server installation.
To use a load balancer in open portal mode, complete the following steps:
Use this format to add the domain name:
Note the . that precedes the name.
Tip
This step is not for channels that point to external content. It is useful for portal-related content that is displayed in channels.
Note
For example, change this URL scraper channel value:
http://server1.sesta.com:8080/ipinfo.html
Tip
The profile server's protocol can be changed to HTTPS. This is the server that has the profile service running on it. See the following instructions.
In the following instructions and examples, /opt is the default installation directory.
Note
https://server1.server2.sesta.com@8080/profileservice
ips.server.protocol (for example, ips.server.protocol=https)
ips.naming.url (for example, ips.naming.url=https)
ips.notification.url (for example, ips.notification.url=https)
You can now run multiple instances of the iPlanet Portal Server 3.0, Service Pack 4 on different ports. Running multiple instances of Portal Server, each with its own copy of iPlanet Web Server on the same physical machine, changes the context of iPlanet Portal Server 3.0, Service Pack 4 to have multiple web servers and JVMs on the same machine.
It is possible to configure the various instances to implement SSL, giving a user the flexibility of switching to SSL mode for security on any of the iPlanet Portal Server instances. So when running in open portal mode, iPlanet Portal Server instances can talk over SSL.
Using the create command only configures new iPlanet Portal Server instances using the HTTP protocol.
Note
You can create multiple instances of the iPlanet Portal Serveron different ports, after you install iPlanet Portal Server 3.0, Service Pack 4 Service Pack 4.
For installation instructions, see "Service Pack 4 Installation Notes" in the iPlanet Portal Server 3.0, Service Pack 4 Service Pack 4 Installation Guide.
Tip
To configure multiple server instances, complete the following steps:
In the following instructions and examples, /opt is the default installation directory.
Note
This option is interactive. The administrator can continue to enter unique port numbers, not already in use, where multiple instances are to be created. Select Return after your last entry.
To determine whether the desired port is available and unused, enter this command from the command line:
Tip
This process takes approximately 5 minutes, depending on the machine architecture. Here is an example of what the script output and user input looks like:
Should any instances entered already exist, the following message is displayed before you are prompted to overwrite:
These instances can be directly accessed through the web browser. For example:
If the machine name is siroe.iplanet.com, and two port numbers 8081 and 8082 were configured as shown in the Step 1, and the install directory was /opt, the following files are listed:
/opt/SUNWips/bin/ipsserver.server1.sesta.com@8080
/opt/SUNWips/bin/ipsserver.server1.sesta.com@8081
/opt/SUNWips/bin/ipsserver.server1.sesta.com@8082
The following command options have been updated, and new commands have been added. The following examples assume that the commands are being run from the directory in which they reside:
In open portal mode, you can change the protocol to HTTPS of any of the other created multiple instances. Make these changes for the server where SSL is required. Make sure that the key pair file password and the trust database password entered for any of the certificate installation is the same between all the iPlanet Portal Server created multiple servers which are being configured to talk over SSL and that password must be the SSL passphrase entered during the iPlanet Portal Server installation.
In the following instructions and examples, /opt is the default installation directory.
Note
If the instance running on port 8081 is to be secure, for example, complete the following steps:
The server can now access multiple instances of iPlanet Portal Server from a single server installation. Access to Portal Server is through one of these:
To log in to a different domain on Portal Server, use this URL:
If the existing installation of Portal Server contains multiple servers and multiple domains, a URL-to-domain mapping setting allows Portal Server to find the domain automatically. The domain name does not need to be provided in the URL.
If the Portal Server installation has one server and two domains (domain1 and domain2), the following URL-to-domain mapping is needed:
To map a URL to a domain, complete the following steps:
You must repeat these steps for each domain.
Note
The domain URL list for domain1 must contain the following URLs:
In the following instructions and examples, /opt is the default installation directory.
Note
NameTrans fn="redirect" from="/domain1" url="/login/domain1"
NameTrans fn="redirect" from="/domain2" url="/login/domain2"
Replace domain 1 and domain 2 with iPlanet Portal Server domain names.
If there are three servers (server1, server2, and server3) and two domains (domain1 and domain2), the following are the URL to domain mappings:
To map a URL to a domain, complete the following steps:
The domain URL list for domain1 must contain the following URLs:
The domain URL list for domain2 must contain the following URLs:
If you write applications using iPlanet Portal Server APIs, you can run them on a server host that is not iPlanet Portal Server. The applications can be either standalone Java applications (with some limitations) or a servlet application running on iPlanet Web Server.
iPlanet Portal Server 3.0, Service Pack 4 public APIs are supported only on Solaris operating systems.
Note
In the following instructions and examples, /opt is the default installation directory.
Note
To set up a non-Portal Server, complete the following steps:
A notification feature of the iPlanet Portal Server session and profile APIs allows applications to listen for profile and session state changes. If an application runs as a standalone application:
Use the administration console to reduce the cache seconds attribute in the session profile.
Tip
If the iPlanet Portal Server 3.0, Service Pack 4 server is configured to use SSL, the iPlanet Portal Server APIs also use SSL. The application must also use SSL to communicate with the iPlanet Portal Server services.
The iPlanet Web Server, when installed, is not properly configured to support outgoing SSL connections by servlets.
In the following instructions and examples, /opt is the default installation directory.
Note
To enable SSL connections by servlets, complete the following steps:
To run applications using the iPlanet Portal Server gateway, you must configure the gateway to forward iPlanet Portal Server cookies to the application host. By default the gateway forwards cookies only to the iPlanet Portal Server.
If the URL of the server the application is running on is not added to this attribute, the iPlanet Portal Server cookie is not forwarded, and the application has an invalid user session.
In the following instructions and examples, /opt is the default installation directory.
Note
To configure the gateway to forward cookies, complete the following steps:
To run applications without the gateway, access the application using a fully qualified domain name (FQDN).
If a fully qualified domain name is not used, the iPlanet Portal Server cookie is not forwarded to the application, and the user session is invalid.
This section provides details about updating the smbclient command in iPlanet Portal Server.
The smb.conf parameter has been added to the smbclient command to allow NetFile to display ISO8859-1 character sets in file names.
This new parameter also provides a way for administrators to configure the NetFile application to take advantage of other smbclient features.
Here is an example of an smb.conf file that could be used to see the choices translated in a locale's chosen language:
An accompanying map file in /opt/samba/lib/users.map might look like this:
For more information about Samba-specific configurations, refer to the samba Web site at:
This section provides details about enabling Webmail applications in iPlanet Portal Server.
Portal Server can now deliver Webmail applications.
A connection handling problem between the Internet Explorer 5.5 browser and iPlanet Portal Server 3.0, Service Pack 4 may result in Page not Found errors when Webmail is used. The administrator can avoid this problem by editing the Messaging Server's main.js file.
To change the main.js file on the Messaging Server, complete the following steps:
The following features and products might not be supported in future releases of the iPlanet Portal Server product:
Although the GraphOn client, Citrix software, and PCAnywhere Java client will no longer be included as third-party software with the iPlanet Portal Server product, they will continue to work with the iPlanet Portal Server product and are available from their respective websites.
This section lists known problems with iPlanet Portal Server 3.0, Service Pack 4. Details are provided in the following areas:
The text field, search filter for userId, refers to the attribute (by default, the uid attribute) to use in searching the directory. Then the attribute specified in the search filter for userId is used to create the search filter used in the lookup.
For example, if you did not specify an attribute in the search filter for userId text field and left it blank, the default is uid. So, the search filter becomes (uid=jim), where jim is the user name that the user entered. If the search filter for userId field contained the value surname or sn, then the search filter would become surname=jim.
The setDomain method should attempt to retrieve a domain profile before setting the domain. (4378030)
Workaround:
The administration console allows duplicate tab names if one attribute is different. (4376634)
Workaround:
Verify that tab names are not duplicated.
The Valid Session number in the Manage User Session page provides an inaccurate number of valid sessions. (4381586)
When you log in to the administration console (either as super user or any user) and select Manage User Session, the Valid Session number is shown as 1. When you log in again from another browser, the Valid Session number does not increment to 2 to show that two valid sessions are in progress.
Contents of profilestyle.css can become visible in the administration console when adding a new user to a newly created domain. (4379326)
Workaround:
After the server is restarted, the gateway cannot be restarted from the administration console. (4531433)
Workaround:
Log in to the iPlanet Portal Server product through the gateway.
The gateway cannot be restarted from the administration console if a case mismatch for the gateway name occurs during installation. (4521387)
During installation of the gateway and the profile server, the fully qualified name of the gateway given should match the profile server name. For example, if gateway.sesta.com is the fully qualified name provided during the gateway installation, during the profile server installation. the gateway name must be entered as gateway.sesta.com (not gateway.SESTA.COM, for example) during the profile server installation.
if there is a case mismatch problem occurs, edit the /etc/opt/SUNWips/platform.conf file to change the ips.gateway.host value to match the entry in the server configuration. For example, change the value to ips.gateway.host=gateway.sesta.com. Then restart the gateway.
When accessing the administration console through the gateway, the URL in the browser's address field reflects the name of the server that the gateway is connecting to. The server name must be that of the primary server. If more than one instance is running on the primary server, the URL must also contain the port number for the primary instance.
The URL should be similar to the following:
https://server1.sesta.com:333/https://primary_server.sesta.com:primary_instance_port/
Remove the provider from the channel list in the Administration console.
When using Internet Explorer 5x on Windows 98, closing the Netlet window crashes the web browser. (4355280)
Workaround:
Using bookmark provider with Internet Explorer 4.x client on open portal gets a script error (4358738)
Workaround:
None. This Internet Explorer 4.x bug is not reproducible with Internet Explorer 5.x or Netscape browsers.
delAttribute permits deletion of a profile attribute without write permission. (4447005)
Workaround:
Administrators can delete their own accounts. (4454833)
Workaround:
To localize the description and title for a channel created with the channel wizard, complete the following steps:
description=This is the description
The .properties file must use Java Unicode encoding, where multi-byte characters are represented as XXXX where the Xs are hexidecimal digits.
Files in this encoding can be created from files in a variety of native encoding using the java native2ascii program.
A separate .properties file is necessary for each locale to be supported.
Note
Specify the user's character set in the profile and in the .properties file. To do so, complete the following steps:
This workaround applies for the NetMail character set and the iwtNetMailServlet.properties file. Perform this procedure for creating and editing the iwtNetMailServlet.properties file.
Note
Install Microsoft VM for Java, 5.0 Release 5.0.0.3802.
Users logged in as anonymous cannot access other authentication mechanisms with the same iPlanet Portal Server session. (4525900)
This problem requires the user to exit the browser because the anonymous user desktop page does not have a means for logging out of the session.
Use lower case letters when setting domain names during installation and when referring to domain names.
External bookmark URLs are not redirected. (4324617)
Workaround:
Create a second bookmark channel to handle external sites.
The bookmark provider can not be used for URLs referencing Internet URLs that the gateway cannot or should not fetch.
To prevent this, remove openURL from the gateway profile rewrite JavaScript function parameters.
After installation, remove the installation log file /var/sadm/install/logs/ipsinstall.process_id/install.log.
Solaris 8 patch causes patchadd -p command called from install script to fail due to large output. (4638284)
Workaround:
Change the variable assignment for AWK from usr/bin/awk to usr/bin/nawk in ipsinstall. The approximate location for this change is at line 10 in the script.
When you create an XML file, if the attribute type is boolean, add a true or false statement. For example:
If the iPlanet Portal Server software is in a non-English locale, any input provided to the ipsadmin command should be in UTF-8 character encoding when using the certain options with an xml file. (4614401)
These options include the following:
XML files should not use Java Unicode encoding as produced by native2ascii. To change the character set encoding in an XML file, do one of the following:
An example of an encoding header using the Thai character set would be:
<?xml version="1.0" encoding="TIS620"?>
An example of an encoding header set to UTF8 would be:
<?xml version="1.0" encoding="UTF8"?>
To convert an XML file to UTF8 do the following:
For example, if using Thai character set encoding, the command would look like:
# native2ascii -encoding TIS620 getdomain.xml getdomain-ascii.xml
For more information, see "Configuring Multiple Server Instances."
To start all processes for all instances, use the ipsserver startall command:
To start the processes for a specific instance, use the ipsserver start command and the server-specific ipsserver file:
Heavy loads for an extended duration cause components in the operating system to fail. (4472975)
Workaround:
A hot patch for using Service Pack 4 with Mobile Access Pack is needed. See the iPlanet Web site for information on this hot patch.
Select some other part of NetFile to clear up the hour glass.
NetFile Lite does not check the size of a file before attempting to upload. If the file is greater than 5 MB, the upload fails. (4293370)
Workaround:
Uploading tar files greater than the 5 MB limit in NetFile Lite, and tar files greater than the 500 MB limit in NetFile generates an incorrect error message. (4372826)
Workaround:
The NetFile application allows users to access denied hosts if those hosts were added to the desktop before a deny rule was added in the iPlanet Portal Server administration console. (4463515)
Workaround:
if Portal Server and the FTP server are on different subnets, the FTP server is tried on all the IP addresses of the interfaces. (4486094)
It is expected that the interface's IP address and the IP address of the FTP Server are on the same subnet. The solution does not work with IPv6 to IPv4 tunneling. The solution does not work with tunnelled source and destination, even if the source and destination addresses are IPv4. The solution works with multiple homes created for separating two different networks.
In the case an appropriate IP address/interface cannot be determined, the FTP server is tried for on all IP addresses of the interfaces. In this case the request can time out and NetFile would show the contents to be blank.
Wait for the reply flag to be set (slow down) or delete the message again.
IMAP password is displayed in clear text in source of edit. (4307367)
Workaround:
Add the following code inside the component tags of iwtHelloWorld3Provider.xml:
Add the following code inside the component tags of iwtQuotationProvider.xml:
Temporarily change the ips.profile.host entry in the platform.conf file from the localhost to the "real" profile FQD.
When attempting to upgrade from a highly-customized Portal Server with many new components or channels, a tuned ipsadmin script is replaced by a default script and heap space allocated for successive component imports is inadequate.
Workaround:
Modify the ipsinstall script to stop for intervention right after the SUNWwtds package has been installed. The approximate location for this change is at line 3353 in the script. Change the following lines:
To the lines below:
Once the installer prompts you to continue, edit install_dir/SUNWips/bin/ipsadmin. The approximate location for this change is at line 34 in the script. Change the following line:
To the line below:
Upgrade may take a long time because custom components are imported twice, regardless of whether they differ from their XML counterparts.
Workaround:
Edit the ipsinstall and ipsadmin scripts as noted previously in this Upgrade section. In addition, once the installer prompts you to continue, remove the XML files from /etc/opt/SUNWips/xml that do not differ from values stored in LDAP.
This release of iPlanet Portal Server includes enhancements and fixes to the following known problems:
Bug ID
Bug Description
Fixed In
The attribute in LDAP to use for Profile ID field in Cert Authentication is a password field.
Administration console allows roles and users to be entered with non-ASCII characters, and generates an unclear warning message.
The Users First Name field in Membership Authentication is a password field.
The Service Pack 3 and Service Pack 3a versions limit the number of entries in the Cookie Domain List field to four. If more than four entries are used, the gateway component does not start.
Missing choice value (CVal) key value pairs in the iwtAuthCert.properties file, and spaces in the keys in the iwtAuthCert.properties file prevent some translated strings from being displayed in the administration console. Instead, the strings are displayed in the default language, which is English.
The keys in the xml files and the .properties files do not match, so some translated strings are not displayed in the administration console. Instead, the administration console displays the strings in the default language, which is English.
Domain Admin Roles page shows incorrect listing of domain administration roles.
Authentication time out returns the error message document contains no data instead of a message stating that the session timed out.
Login channel causes passwords to show up in Web Server's access log. For more information, see "Default Login Channel Templates Changes" in this document.
Authentication chaining fails when SecureID is the second authentication module.
Authentication fails when platform server is configured to use HTTPS.
certadmin self-signed certificate validity defaults to 90 days.
UNIX authentication fails when the server and the doUnix helper are out of sync.
The option to match the certificate in LDAP does not work if the certificate in the LDAP directory is stored as binary.
Maximized channel with no content should display the message Content not available.
Edit Page of Netlet and Bookmark Provider can not be accessed after any one of the fields is deleted.
Entries with multiple sn and givenname do not display correctly in the User Info channel.
A URL scraped channel does not display JPEG files with a non-relative path.
The tab provider displays tabs in only right-to-left alignment. For more information, see "Tabbed Desktop" in this document.
The JSP provider cannot localize title or description. For information on the JSP Provider sample properties file, see "Localizing JSP Provider Titles and Descriptions" in this document.
Occasionally, the desktop is displayed only after the entire timeout the default timeout is 30 seconds.
Detaching all channels on the desktop causes an unrecoverable error that makes the desktop unusable.
Desktop provider does not catch throwable, resulting in a desktop error page with the message A fatal error has occurred displayed in the channel window.
Some attribute strings for desktop tabs are displayed in English for other locales.
Desktop logs expired or invalid sessions as an errors instead of warnings in the debug log files. This can debug files to grow unnecessarily large.
URLScraperProvider does not preserve backward compatibility.
Channel titles are always displayed in the language stored in the profile service.
Changes to TimeZone are not effective until user logs in again.
Changing to layout Option Four causes wide channels to be removed.
Selecting Open all pages in the desktop when editing bookmarks causes the javaScript function openURL to call the server twice in the URL.
The Channel Wizard works incorrectly when an in-line channel is created if the iSyndicate connector is installed.
Weather provider templates should not be installed. The product does not contain a weather provider.
Content provider should check for null provider in content provider edit page creation.
The URL scraper failed when it tried to fetch a URL that resulted in a redirect.
URL rewriting did not work for relative URLs in URL scraper.
Removing a channel with thin-thick-thin layout caused null pointer.
Outlook Web Access 2000 does not work out-of-the-box. See "Using Outlook Web Access 2000" in this document.
The gateway cannot handle cookies differing only in path. For more information, see "Desktop and Provider Changes" in this document.
JavaScript window.location.path value is not rewritten correctly.
The gateway component does not rewrite JavaScript variables that contain escaped double quotes.
Internal applications cannot be accessed because cookie domain rewriting does not use gateway domain or cookie domains list.
Internal applications that use URLs in which the file path starts with the word login cannot be accessed when using personal digital certificates (PDCs). iPlanet Portal Server redirects these URLs to the desktop.
The gateway does not rewrite cookies correctly when used with the HTTP Proxy.
Re-submitted HTTP posts to foreign hosts by the gateway contain no data.
The gateway component does not handle pages correctly when lines end with line feed only.
iPlanet Portal Server 3.0, Service Pack 3 does not work with iPlanet Messaging Server 5.1.
The gateway component should not add default port number to re-written links.
The gateway rewrites src= tags when it is an SSL site and the site is not in the rewrite domain/subdomain list.
The gateway does not display a URL correctly unless / follows the hostname.
If the socket connection cannot be created, the gateway sends a 502 HTTP error code to the client indicating that the server is unavailable. For information about the addition of the isp.gateway.sockretries parameter, see "Setting the Number of Socket Connection Retries" in this document.
HTTP basic auth caching (SSO) fails when using server HTTP proxy.
Referer headers must be forwarded so servers can track the user's URL.
The ipshttpd script does not set the maximum number of file descriptors to a high enough value for the gateway proxy process, causing the ipshttpd process to run out of file descriptors. When that happens, ipshttpd stops responding.
Users cannot authenticate with Internet Explorer, if hostname contains capital letters.
If the server and the gateway are installed on two different machines, the iwtGateway.properties file is not installed in basedir/SUNWips/locale directory of the server machine. The gateway-related strings are displayed in the default language, English, for foreign languages on the server machine.
The URL rewriter incorrectly rewrites relative URLs by using the document's URL instead of its instead of its base URL (indicated by the BASE tag).
In some cases the gateway or gateway proxy would not respond due to CLOSE_WAIT sockets accumulating, and not getting closed.
If an applet is between <OBJECT> and </OBJECT>, the URL rewriter does not rewrite the URL.
The URL rewriter does not rewrite the applet parameter value if there is space between an HTML tag's parameter name and value.
URL Scraper and RSS channel providers fail when load balancing is active.
URLscraper does not handle the character set from Content-Type.
Internet Explorer 5.5 cannot display Webmail application when used with the gateway.
The gateway component should use JSS for talking to the platform server in HTTPS mode.
Gateway boot process hangs if the server is not started first.
Rewriter did not work if a URL had no leading http:// and no port number specified.
Rewriter for applet tags could rewrite only limited number of URLs in a parameter.
Install needs to check disk space for installing Java packages. If Java packages don't get installed, the install script fails.
Stop script stops all slapd processes and all external LDAP server processes.
The installation script requires a fully qualified domain name (FQDN) with three parts (separated by two dots). It does not accept an FQDN with only one dot.
Installing gateway with profile server, using non-default port for SSL, sets port to 443.
Service Pack 3 image should not include jdk1.2.2_05 patches.
Installing profile server with a web proxy causes ipsserver to fail.
Importing privileges after accessing the Policy page requires relogging to view.
ipsadmin -import converts new attributes in previously existing components to lower case and reports all attributes of new components as already existing. This bug is fixed in the iPlanet Directory Server 4.12 release.
ipsserver stop script kills all HTTPD processes running on the server. In doing so, it may also kill some external iPlanet Web Servers running on the server. The ipsserver stop command should stop only relevant processes.
Incorrect country code for Japan in the iwtUser.properties file.
On Japanese localization, NetFile Java did not work on Solaris and Windows NT.
When logging is disabled, the log client still sends the log message.
Oracle jdbc driver does not re-initialize when the database cycles off and on.
Double-byte nickname entries in NetMail Lite address book are not supported.
Mail form field values in NetFile are not checked uniformly.
File names are not displayed when mailing multiple files from the NetFile Java application. File names are now displayed as a comma separated list.
Sending a blank email reply with the NetFile application causes the browser to spin indefinitely.
The window for displaying files on right side is too small. The file name window has been changed to allow 11 additional characters.
NetFile FTP connection method does not work properly with server components using multiple network interfaces. The PORT command uses the wrong IP address when sending data back to the client.
The Print and Save functions don't work in Netscape Navigator for files sent by NetFile.
The NetFile Lite application incorrectly displays compressed file names when using Windows NT hosts.
NetFile Lite behavior, under certain circumstances, can compromise password security.
NetFile Lite can display only one share for Windows systems.
NetFile Lite does not save changes to host information upon exiting and saving the session.
NetFile has problems displaying hidden shares that have been defined by the administrator.
NetFile shares that have been defined through ipsadmin can be added again through the NetFile application resulting in duplicate shares.
Using the host info menu in NetFile to edit host information, such as user name and password, removes the shares associated with that host.
NetFile assumes that a system is valid without verifying that the system exists. If the system to which NetFile tries to connect does not exist, the NetFile application eventually times out.
NetFile applet occasionally does not pass the sessionid to the servlet during a servlet call, resulting in a session exception that causes the log files to get unnecessarily large.
If the server's LANG setting specifies Japanese or Chinese locale, NetFile download functions for image, HTML, and executable files do not work.
If the server's LANG setting specifies Japanese or Chinese locale, NetFile upload functions for image, HTML, and executable files do not work.
NetFile mail functionality can overwrite iPortal Web Server configuration files.
NetMail was unable to receive mail with attached text file sent from NetFile.
Netlet does not support .ins files for Internet Explorer Configuration. For more information, see "Configuring Internet Explorer INS Files" in this document.
Netlet activity is not monitored and causes a session idle time out even when the Netlet is in use.
Dynamic rules should be supported when using FTP through a Netlet connection.
The port number is not stripped from the host name when evaluating a PAC file.
Netlet does not support Netscape with PAC files. For more information, see "Installed Software Modules, Customizations, and Third-Party Products" in Chapter 2 of the iPlanet Portal Server 3.0, Service Pack 4 Installation Guide.
Netlet applet is hardcoded for a maximum of ten connections per rule.
The global encryption version of Netlet Applet incorrectly shipped with the domestic version of iPlanet Portal Server 3.0, Service Pack 3.
A certificate error occurs when using an HTTPS connection when the VIP name does not match the server name.
Profile server should be able to reconnect to the LDAP server.
ipsadmin has wrong content type for UpdateProfileCache request.
Profile API returns valid profile object for non existing profiles.
Domain search did not search for users mapped from external LDAP. The search limit for external LDAP users is 400 users only.
External LDAP attribute mappings did not work with binary type attributes.
The steps to add a gateway are documented incorrectly in the iPlanet Portal Server 3.0 Administration Guide. For correct instructions, see "Adding a Gateway After Installation" in this document.
Document required disk space for /var; /etc; /opt; and installation directory.
Portal Server and gateway components on a single computer must use the same install directory.
Correct instructions for adding iwtTabProvider in selected channels.
This section provides information that supplements the iPlanet Portal Server 3.0, Service Pack 4 Administration Guide. Topics include:
Documentation for iPlanet Portal Server 3.0, Service Pack 4 is at this Web site:
http://docs.iplanet.com/docs/manuals/portal.html
SSL certificate management changes have changed information for SSL certificates for the gateway component presented in Chapter 11 of the iPlanet Portal Server3.0 Administration Guide and Appendix A of the original iPlanet Portal Server 3.0 Installation Guide.
The following information replaces the existing documentation on SSL certificates for the gateway.
Documentation about certificates for the iPlanet Portal Server server component still applies.
Note
The certadmin script in installation_directory/SUNWips/bin/ wraps around the ipscertutil command for convenience and consistency with previous certificate administration. The certadmin script should satisfy the conventional needs of certificate administration. For additional functions, use the ipscertutil command directly. For example, use ipscertutil to delete a certificate from the certificate database. The command ipscertutil -H lists use.
Certificate-related files are located in /etc/opt/SUNWips/cert. Three of the five certificate files, cert7.db, key3.db, and secmod.db, are binary files containing data for certificates, keys, and cryptographic modules. These files can be manipulated implicitly by using the certadmin script.
These binary files have the same formats as the database files used by iPlanet Web Server. They are located in installation_directory/netscape/server4/alias. If necessary, they can be shared between the iPlanet Portal Server server and gateway components or the gateway proxy.
The other two certificate files are hidden text files: .jsspass and .nickname. The .nickname file stores the names of the token and certificate that gateway currently uses, in the form of token_name:certificate_name. If using the default token (the token on the default internal software encryption module), omit the token name. In most cases, only the certificate name is stored in .nickname file.
The .jsspass file contains the password for the encryption module that iPlanet Portal Server gateway currently uses. The default module is the internal software module.
During the installation of the iPlanet Portal Server gateway component, a self-signed SSL certificate is created and installed. If necessary, use the certadmin script to do additional certificate administration.
Administrators use the certamin script to generate a self-signed certificate for the gateway. To do this, complete the following steps:
Multiple certificates can be stored in the database files. The one that the gateway component uses is identified by the .nickname file. You can edit this file to switch to a different existing certificate.
During installation of the gateway component of the Portal Server product, a self-signed certificate is created and installed. At any point after installation, you can install SSL certificates signed either by vendors who provide official certificate authority (CA) services or by your corporate CA.
Three main steps are involved in this task.
To generate a certificate signing request, complete the following steps:
The webmaster's email and phone number are required.
Note
A CSR is generated and stored in the file /tmp/csr.hostname and is printed to the screen so that you can copy and paste it.
To use the certificate signing request to order a certificate from a certificate authority, complete the following steps:
The following example omits the actual certificate data.
Include both the BEGIN CERTIFICATE line and the END CERTIFICATE line with the certificate in the file.
Note
To install the certificate from the CA in your local database files in /etc/opt/SUNWips/cert, complete the following steps:
The script asks you to enter certificate file name, certificate name and token name.
Once the certificate is installed in /etc/opt/SUNWips/cert, the screen prompt returns.
Tip
When the gateway is an SSL client, importing a root CA certification into the gateway's certificate database enables the gateway component to communicate with an Internet or an intranet HTTPS site. If the root certificate is not in the gateway's certificate database, the gateway component does not recognize the server's CA certificate, and the SSL handshake fails.
To import a root CA certificate into the gateway component's certificate database, complete the following steps:
If the gateway component is set up to communicate with an HTTPS site that presents a self-signed certificate, allowing the gateway component to trust any unknown CAs can be useful. However, this approach must be used with caution. See "Denying Unknown Certificate Authorities" for more information on configuring the gateway component.
Most well-known public certificate authorities are already included in the certificate database.
Tip
To view the list of Public CAs, compete the following steps:
Table 9 displays all public certificate authorities included in the certificate database by default. Their trust attributes are also provided.
For information on modifying the trust attributes of a public CA, see "Modifying Trust Attributes of a Certificate."
The trust attributes of a certificate provide information about whether the certificate is a regular server certificate (also called user certificate) as opposed to a root certificate, and whether the certificate (in the case of a root certificate) can be trusted as the issuer of a server or client certificate.
Three trust categories are available for each certificate: SSL, email, and object signing. In the context of the gateway component, only the first category is useful. In each category position, zero or more attribute codes are used.
The possible attribute values and the meaning of each value are listed in Table 10.
Attribute codes for the categories are separated by commas, and the entire set of attributes is enclosed by quotation marks. For example, the self-signed certificate generated and installed during the gateway installation is marked u,u,u to designate that it is a server certificate (user certificate), as opposed to a root CA certificate.
You can use the certificate administration script to view all certificates and their corresponding trust attributes.
To view the trust attributes of a certificate, complete the following steps:
The trust attributes of a certificate must be modified if client authentication is used with the gateway.
An example of client authentication is PDC (Personal Digital Certificate) as described in Chapter 6 of the iPlanet Portal Server 3.0 Administration Guide. The CA that issues the PDCs must be trusted by the gateway. For example, the CA certificate should thus be marked T for SSL.
To set the trust attribute for a certificate, complete the following steps:
Once the certificate trust attribute is changed, the gateway recognizes client certificates signed by that certificate authority.
The first two steps in the procedure "To Add a Gateway After Installation" in the iPlanet Portal Server 3.0, Service Pack 4 Administration Guide are incorrect. The correct procedure for adding a gateway after installation is described here.
To add a gateway after you install Portal Server, complete the following steps:
The new gateway uses the default platform values for gateway port number, name of platform profile, retry interval, and default domain.
For example, if the new gateway host name is host1.domain1.com and the iPlanet Portal Server host name is host2.domain2.com, then domain1.com is added to the Cookie Domain List attribute.
If you have problems with iPlanet Portal Server 3.0, Service Pack 4 Service Pack 4, contact iPlanet customer support using one of the following mechanisms:
So that we can best assist you in resolving problems, please have the following information available when contacting customer support:
Useful iPlanet information can be found at the following Internet locations:
Use of iPlanet Portal Server is subject to the terms described in the license agreement accompanying it.
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Sun, Sun Microsystems, the Sun logo, Java, iPlanet, and all Sun, Java, and iPlanet based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
Federal Acquisitions: Commercial Software -- Government Users Subject to Standard License Terms and Conditions The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation. No part of the product or this document may be reproduced in any form by any means without prior written authorization of Sun Microsystems, Inc. and its licensers, if any.
THIS DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID.
Copyright © 2002 Sun Microsystems, Inc. Tous droits réservés.
Sun, Sun Microsystems, le logo Sun, iPlanet, et le logo iPlanet, Java, JVM, JavaScript, et Solaris sont des marques de fabrique ou des marques déposées de Sun Microsystems, Inc. aux Etats-Unis et d'autre pays. Netscape et le logo Netscape N sont des marques déposées de Netscape Communications Corporation aux Etats-Unis et d'autre pays. Les autres logos, les noms de produit, et les noms de service de Netscape sont des marques déposées de Netscape Communications Corporation dans certains autres pays. UNIX est une marque enregistree aux Etats-Unis et dans d'autres pays et licenciée exclusivement par X/Open Company Ltd.
Le produit dé crit dans ce document est distribué selon desconditions de licence qui en restreignent l'utilisation, la copie, la distribution et la décompilation. Aucune partie de ce produit ni de ce document ne peut être reproduite sous quelque forme ou par quelque moyen que ce soit sans l'autorisation écrite préalable de Sun Microsystems, Inc., le cas échéant, de ses bailleurs de licence.
CETTE DOCUMENTATION EST FOURNIE "EN L'ÉTAT", ET TOUTES CONDITIONS EXPRESSES OU IMPLICITES, TOUTES REPRÉSENTATIONS ET TOUTES GARANTIES, Y COMPRIS TOUTE GARANTIE IMPLICITE D'APTITUDE À LA VENTE, OU À UN BUT PARTICULIER OU DE NON CONTREFAÇON SONT EXCLUES, EXCEPTÉ DANS LA MESURE OÙ DE TELLES EXCLUSIONS SERAIENT CONTRAIRES À LA LOI.
Last Updated October 10, 2002