Previous     Contents     Index     Next     
iPlanet Portal Server Administration Guide



Chapter 7   Configuring The Netlet


This chapter describes how to set up applications to run securely between users' remote desktops and the application servers on your site's intranet using the Netlet service. Topics covered include:

  • Configuring the Netlet to enable applications to run securely

  • Customizing the iPlanet Portal Server profiles to provide links to user-defined applications

  • Configuring third-party client/server applications to allow them to work with the Netlet



Providing Secure Applications Through the Netlet

iPlanet Portal Server users will want to run popular or company-specific applications on their remote desktops in a secure fashion. You provide these applications by setting up the iPlanet Portal Server Netlet on your platform. After you implement the Netlet at your site, users can securely run common TCP/IP services, such as Telnet and SMTP, and HTTP-based applications, such as pcANYWHERE or Lotus Notes.


Requirements for the Netlet

You can run any application over the Netlet if:

  • It is TCP/IP-based.

  • It uses fixed ports.


    Note You cannot use the Netlet with applications that dynamically allocate ports. For example, you cannot run FTP over the Netlet if you run it as part of a cron job. The one exception is Microsoft Exchange, for which there is a limited dynamic port capability.


  • Fixed ports and servers are available to the iPlanet Portal Server gateway or server without using a web proxy.

Only a limited number of sockets can be opened up on remote PCs.


How the Netlet Works

The Netlet is a Java applet that sets up an encrypted TCP/IP connection through fixed ports between the remote client and your intranet. Depending on whether the Netlet proxy is enabled, the connection will be made to the iPlanet Portal Server Gateway or iPlanet Portal Server Server. The Netlet has its own provider on the iPlanet Portal Server desktop, which users can tailor.

In a session involving the Netlet:

  1. The remote user logs in and authenticates to the desktop.

  2. If any Netlet rules have been defined, the Netlet is automatically loaded onto the remote client.

  3. The Netlet listens on localhost to the ports defined in the Netlet rules.

  4. The user clicks a link in the Netlet provider on the iPS desktop for a TCP/IP application or a UNIX service for which you have defined a Netlet rule.

  5. The Netlet sets up an encrypted transaction between client and server over the ports specified in the Netlet rule defined in the Administration Console.

  6. The transaction follows the path shown in Figure 7-1, which illustrates the movement of a telnet session over the Netlet with the Netlet proxy enabled.


    Note The Gateway Management>Manage Gateway Profile>Advanced Options include an attribute for enabling the Netlet proxy.


.

Figure 7-1    Path of a Telnet Session Run Over the Netlet

The entities in the path include:

  1. Remote client

  2. Internet

  3. Company's external firewall

  4. DMZ, where the Netlet is forwarded through the iPlanet Portal Server gateway

  5. Company's internal firewall

  6. Corporate intranet

  7. iPlanet Portal Server server

  8. Netlet proxy on the iPlanet Portal Server server, which decrypts the transaction

  9. Recipient host on the corporate intranet


What Is Involved in Configuring the Netlet?

Setting up the Netlet requires four steps:

  1. Create Netlet rules for the applications you want to support at your site.

  2. Determine which rules should be domain-, role-, or user-based.

  3. Add these rules to each level of the role tree by configuring the Applications profiles in the Administration Console.

  4. Define the privileges for each Netlet rule in the policy pages of the Administration Console.



Writing Netlet Rules

Netlet behavior is defined through a series of Netlet rules that are configured on the profile pages of the Administration Console. Netlet rules can be configured for domains, roles, or users. The links to get to the Netlet rules are Manage Domains>Domainname>Applications>Netlet. Of course, if the netlet rule is for a role or user, select the desired role or user after selecting the domain name.

Netlet rules exist for:

  • Predefined Netlet applications

  • User-defined Netlet applications

Netlet rules are either static or dynamic. A static rule specifies a particular destination host. A dynamic rule specifies that the end user allocates destination hosts are allocated dynamically.


Syntax of Netlet Rules

Netlet rules use the following syntax:

name|<url to invoke>|<download applet ?>|listen-port| destination-info|destination-port

where:

  • name - Designates a name for this Netlet rule.

  • URL to invoke - Specifies the URL that the browser opens when the user clicks its associated link in the Netlet provider window. The browser then opens the window for the application, connecting to localhost at the port number specified later in the rule.

    URL to invoke can have either of these values:

    • URL - URL to the application invoked by the Netlet rule.

    • null - Value that you set if the application is not started by a URL or controlled by the desk top.

  • download applet? - Indicates whether it is necessary to download an applet for this rule. Specify one of these actions in the field:

    • false - Do not download an applet.

    • true - Download the applet using the default values:

      localport = iwtNetlet-clientLoopbackPort - the port on the remote client to be used to retrieve other URLs.

      downloadServer = ipsServer - the server where the Netlet code resides.

      downloadPort = ipsPort - the port on the server where the Netlet code will be retrieved.

    • server info - Gives information about the server. Use the form cport:server:sport where:

      sport represents the port on the server used to download the applet.

      server is the server name.

      cport indicates the destination port on the client.

  • listen port - Port on the client where the Netlet will listen.


    Note The listen port value must be unique. You cannot specify a particular port number in more than one rule only.


  • destination info- Recipient of the Netlet connection. Specify either of these values for destination info:

    • host - Name of the host to receive the Netlet connection, used when you are creating a static rule. You can use either the simple host name, such as example1, or a fully-qualified DNS-style host name, such as example1.mycompany.com. The name used here must be what the iPlanet Portal Server uses to get to the destined machine. For example, if the iPlanet Portal Server requires the fully qualified name of the host, specify that.

    • TARGET - Represents the host names that the user specifies on the iPlanet Portal Server desktop for the Netlet target list. A rule specifying TARGET enables users to select their own destination host when they use this rule. Rules that specify TARGET in the syntax are considered dynamic rules.

  • destination-port - the port on the destination host (specified in destination-info)

In addition to the host and target, you must specify a destination port. And in the case where multiple target hosts can be defined, you must have that mentioned here as well.


Ports Used by iPlanet Portal Server

Table 7-1 identifies the ports reserved in iPlanet Portal Server for various applications and services.


Table 7-1 Reserved Listen Ports for Predefined Netlet Rules

Predefined Netlet Rule

Reserved Port

Telnet  

30000  

GO-Joe  

10491  

Citrix  

1494  

pcANYWHERE  

4631, 5632  

CarbonCopy  

1138  

LapLink  

51547  

RapidRemote  

45414  

ReachOut  

43188  

RemotelyPossible  

799  

loopback*  

8000  

* loopback is an internal Netlet rule used for internal functions.


Sample Netlet Rules

This section contains some examples of Netlet rules that illustrate how the Netlet syntax works.


Basic Static Rule

This rule supports a Telnet connection from the client to the machine example1.

myrule|null|false|1111|example1|23

where:

  • myrule is the name of the rule.

  • null indicates that this application is not invoked by a URL or run through the desktop.

  • false indicates that the client does not download an applet to run this application.

  • 1111 is the port on the client where the Netlet listens for a request for a connection from the target host.

  • example1 is the name of the recipient host in the Telnet connection.

  • 23 is the port number on the target host for the connection, in this case the well-known port for Telnet.


How the Netlet Rule Works When Run by the User
The Desktop Netlet provider does not show a link, but Netlet automatically starts and listens on the port specified (1111). Instruct the user to start the client software, in this case a Telnet session that connects to localhost on port 1111.

For example, start the Telnet session, the client types the following on the UNIX command line in a terminal:

% telnet localhost 1111


Static Rule With Multiple Target Hosts

This rule supports a Telnet connection from the client to two machines, example1 and example2.

myrule|null|false|1111|example1|23|1234|example2|23

where:

  • 1234 - port on the client where the Netlet listens for a connection request from the second target host.

  • example2 - name of the second target host, such as example2.

  • 23 - Port number on the target host for the connection - well-known port for Telnet.

The first six fields in this rule are the same is in Basic Static Rule." The difference is that three more fields identify the second target host. When you add additional targets to a rule, you must add three fields, listen port, target host, and target port, for each new target host.


Note You can have multiple sets of three fields describing the connection to each target host. Listen port numbers which are less than 2048 must not be used if the remote client is a solaris machine because low numbered ports are restricted and you must be root to start a listener.



How the Netlet Rule Works When Run by the User
This rule works the same as the previous rule. There are no entries for this rule in the Desktop Netlet Provider. The Netlet automatically starts and listens on the two ports specified (1234). The user needs to start the client software, in this case a Telnet session that connects to localhost on port 1111 or local host on port 1234 to connect to host example2.


Dynamic Rule That Invokes a URL

This rule defines a Telnet connection from the client to hosts that are dynamically allocated, enabling the user to Telnet to various hosts over the Netlet.

myrule|telnet://localhost:30000|false|30000|TARGET|23

where:

  • myrule is the name of the rule.

  • telnet://localhost:30000 is the URL invoked by the rule.

  • false indicates that no applets are to be downloaded.

  • 30000 is the port on the client where the Netlet will listen for connection requests for this rule.

  • TARGET indicates that the target host is dynamically allocated from the desktop Netlet target list when the user invokes this Netlet rule.

  • 23 is the port on the target host opened by the Netlet, in this case the well-known port for Telnet.


How the Rule Works When Run by the User
After this rule is added, the user must complete some steps to get the Netlet running as expected. Give the user the following instructions:

  1. Press the Edit button in the Netlet provider section of the iPlanet Portal Server desktop.

    The new Netlet rule is listed under Rule Name in the Add New Target section.

  2. Click the rule name and type the name of the target host.

  3. Save the changes.

    You return to the Desktop with the new link visible in the Netlet provider section.

  4. Click the new link.

    A new browser is launched that goes to the URL given in the Netlet rule.


    Note You can add more than one target host for the same rule by repeating these steps.



Dynamic Rule That Downloads an Applet

This rule defines a GO-Joe connection from the client to hosts that are dynamically allocated. The rule downloads a GO-Joe applet from the application server to the client.

gojoe|/gojoe.html|8000:goejoeserve:8080|3399|TARGET|58

where:

  • gojoe is the name of the rule.

  • /gojoe.html is the path of the HTML page containing the applet, relative to the iPS installation directory /opt/SUNWips/public_html (in a default installation.).

  • 8000:server:8080 indicates that port 8000 is the destination port on the client to receive the applet, gojoeserve is the name of the server providing the applet, and 8080 is the port on the server from which the applet is downloaded.

  • 3399 is the port on the client where the Netlet listens for connection requests of this type.

  • TARGET indicates that the target host is dynamically allocated by the client when the Netlet rule is invoked.

  • 58 is the port on the target host opened by the Netlet, in this case the port for GoJoe. Port 58 is the port that the target host listens to for its own traffic. The Netlet passes information to this port from the new applet.



Configuring Netlet Profiles in the Role Tree

You define Netlet rules in the application profile pages for the domain, role, or user levels. Each Netlet profile has an attribute called "Netlet Rules," where you type the rules for the applications to run over the Netlet.

This section contains procedures for setting up and modifying the Netlet profiles. It assumes that you have decided on whether you want Netlets to run on a domain, role, or user basis (or all three), and have composed a few rules. If you need assistance on writing Netlet rules, go to Writing Netlet Rules.


Note Consider making most of your Netlets role-based, as opposed to domain or user-level-based.



To Configure a Netlet Profile for a Domain

  1. Access the Administration Console.

  2. Click Manage Domains under "Roles and Users"

    The Portal Server Domains page is displayed.

  3. Click the link for the domain for which you want to configure the Netlet.

    The Domain, Role, and User Profiles page is displayed.

  4. Click the icon to the left of Applications to expand the list of Applications profiles.

  5. Click the Netlet link to display the Netlet profile for the domain.

    All default Netlet rules already active for the domain are shown in the Netlet Rules attribute box.

  6. Scroll down to the field below the listed Netlet rules.

  7. Do one of the following to add Netlet rules:

  8. Add Netlet rules individually by typing each Netlet rule that you want to configure in this field and pressing Add.

    Each new rule is displayed in the Netlet rules box.

  9. Use this shortcut:

    1. Select and highlight an existing rule in the Netlet rules box that is similar to one that you want to create.

      The text of the highlighted rule is displayed in the input field.

    2. Modify the displayed text to reflect the change for the new Netlet rule.

    3. Click Add to add the new rule.

  10. (Optional) You can also change the defaults for other attributes in the Domain Netlet profile, depending on your site's needs. These attributes are:

  11. Warning Popup for Connections

    This attribute pops up a message on the user's desktop warning that someone is trying to connect to the desktop through the listen port. The message comes up when the user runs the application over the Netlet, but also when an intruder tries to gain access to the desktop through the listen port.

    If you do not want the popup to appear on the user's desktop, deselect this attribute.

  12. Default Loopback Port

    This attribute specifies the port on the client to be used when applets are downloaded through the Netlet. The default value of 8000 is used unless it is overridden in the Netlet rules.

  13. Apply changes to subroles

    The default is to not apply changes to subroles. To propagate all changes to the Netlet profile down the role tree, select this attribute. If any child of the current entity has customized a field which is currently changed in the HTML form, then those customized fields will be removed from the children.


    Caution

    		Use care when applying changes to subroles, refer to Section "Inheritance at the Domain Level" on page 24, for a full description of this feature.


  14. Click Submit to register these changes.

  15. Go on to To Set Permissions for the Netlet.


To Set Permissions for the Netlet

The final step in setting up a Netlet profile is to assign permissions for the Netlet rules. The permissions set apply to each level of the role tree and are inherited relative to the level of the profile being set: Domain, Role, or User.

  1. Scroll to the top of the Netlet profile page.

  2. Click the Show Read/Write Permissions button to enable viewing of the default permissions

  3. Scroll down to the Netlet Rules attribute to view the permissions set for each relevant attribute in the profile.

    "Netlet Permissions" on page 139 shows the default permissions, which you can change depending on the requirements of your site.



Figure 7-2    Netlet Permissions

    • Admin indicates the permissions granted to the Domain Administrator for access to the attributes in this profile. The default permissions allow the Domain Administrator to both view and change the attributes. If only Read were selected, the Domain Administrator could view the attribute but not change it.


      Note The Super Administrator always has read and write permissions for all attributes in the role tree.


    • User indicates the permissions granted to the application run by the client. By default, the application can read the attribute, for example, the Netlet rule, but cannot change it. If both Read and Write were selected, the application could both read and change the Netlet Rule attribute, for example.

  1. Press Submit to activate your changes.

    You get a confirmation message that the profile was updated.

  2. Press Continue to return to the Netlet profile.

  3. Go on to Configuring Netlet Privileges for the Role Tree for instructions on setting up policies for the Netlet rules.


To Configure a Netlet Profile for a Role or Users

The procedure is the same as that stated inTo Configure a Netlet Profile for a Domain" except for the role:

    • Access the role of interest by navigating to:
      manage domains><role name>.

    • Access the user by navigating to:
      manage domains> role> <user name>.


To Delete a Netlet Rule

  1. Access the Administration Console.

  2. Click Manage Domains under "Roles and Users"

    The Portal Server Domains page is displayed.

  3. Click the link for the domain with the Netlet.

    The Domain, Role, and User Profiles page is displayed.

  4. Do the following depending on where the Netlet rule you want to delete is located:

  5. Navigate down to the appropriate profile for the role or user.

  6. Remain at the domain level.

  7. Click the icon to the left of Applications to expand the list of Applications profiles.

  8. Press the button to the left of Applications to open the Applications links.

  9. Click the Netlet link to display the Netlet profile.

  10. Click and highlight the Netlet rule that you want to delete in the Netlet Rules attribute box.

  11. Press the Delete button associated with the filed.

    The highlighted rule is removed from the list of rules.

  12. Press Submit to activate your changes.

    You get a confirmation message that the profile was updated.

  13. Press Continue to return to the Netlet profile.


To Modify an Existing Rule

  1. Access the Netlet profile with the rule to be modified, as explained in To Configure a Netlet Profile for a Domain, To Configure a Netlet Profile for a Role or Users.

  2. Click and highlight the existing rule in the Netlet Rules attribute box.

    The rule text is displayed in the field below the box.

  3. Modify the rule text in the field as needed.

  4. Click the Add button.

    Both the old rule and the changed rule are displayed in the Netlet Rules attribute box.

  5. Click and highlight the old rule in the Netlet.

  6. Click the Delete button.

    The highlighted rule is removed from the list of rules.

  7. Press Submit to activate your changes.

    You get a confirmation message that the profile was updated.

  8. Press Continue to return to the Netlet profile.



Configuring Netlet Privileges for the Role Tree

This section describes how to define policies to be associated with each Netlet profile in the role tree.


To Define Netlet Policies for a Domain

  1. Access the Administration Console.

  2. Click Manage Domains under "Roles and Users"

    The Portal Server Domains page is displayed.

  3. Click the link for the domain for which you want to configure policies for the Netlet.

    The Domain, Role, and User Profiles page is displayed.

  4. Click the Policy link under Profiles to display the Policy Module for the domain.

  5. Click the Netlet link in the Index to move to the Netlet-related attributes.

    The Setup netlet access to specific hosts attribute boxes are displayed. The Allow box contains the asterisk wild card, allowing all hosts in the domain as Netlet targets.

  6. Do either of the following, depending on your site's policies:

  7. Leave the asterisk in the Allow box.

  8. Configure specific host access rights as follows:

    1. Click and highlight the asterisk in the Allow box.

    2. Type the name of a host to be allowed to use the Netlet in the field below the Allow box.

    3. Click Add and then repeat these steps until you have added all hosts to which these privileges must apply.

    4. Type the name of a host to be denied access in the field under the Deny box.

    5. Click Add and then repeat these steps until you have added all hosts that must be denied access to Netlets defined at the domain level.

  9. Scroll down to the fields below the Setup netlet access to specific rule's attribute box.

    These boxes will use the Netlet name, that is, the first part of each Netlet rule.

  10. Do either of the following, depending on your site's policies:

  11. Leave the asterisk in the Allow box.

  12. Specify names of specific Netlet rules to which you want to allow or deny access on the domain level.

    1. Click and highlight the asterisk in the Allow box.

    2. Type the URL for which you want to allow access in the field below the Allow box.

    3. Click Add and then repeat these steps until you have added all hosts to which these privileges must apply.

    4. Type the URL for which you want to deny access in the field under the Deny box.

  13. Click the return to top link and then click Applications from the Index.

    The list of applications allowed to be executed from this profile is displayed. By default, the buttons next each application are pushed in (black), indicating that the application can be executed from the profile.

  14. Control access to the Netlet as follows:

  15. To allowing Netlet access to a domain or role or user, ensure that the box next to the Netlet application is pushed in.

  16. If you want to deny Netlet access to a group of users or members of a role, uncheck the box next to the Netlet application.

  17. Scroll down to the bottom of the page when you are done.

  18. (Optional) Click the box next to Apply all changes to Sub Roles if you want the lower levels of the role tree to inherit these attributes.

  19. Click the Submit button.

  20. Click the continue button to return to the previous page.


To Define Netlet Policies for a Role

Repeat the steps in To Define Netlet Policies for a Domain, but navigate down to the appropriate role level from the Domain, Role, and User Profiles page. From there, define the Netlet policies that are appropriate for the role.


To Define Netlet Policies for a User

Repeat the steps in To Define Netlet Policies for a Domain, but navigate down to the appropriate user level from the Domain, Role, and User Profiles page. From there, define the Netlet policies that are appropriate for the user.


Rules for Predefined Netlet Applications

Rules for predefined Netlet applications govern using well-known third-party remote-windowing applications. These rules are enabled by default when iPlanet Portal Server is installed. To disable them, either remove them from the Domain, Role, User profile or type the name in the deny list on the Policy page in the "Netlet Access to Specific Rules" field.

In the case of pcANYWHERE and GO-Joe, client applets are shipped and integrated with the iPlanet Portal Server software so that they will be started automatically.

Netlet connections to the predefined applications require that a destination server be specified at the time the connection is established; that is, the predefined rules have no fixed destination server.

Simply giving a rule for either a user-defined application, the name of one of the pre-defined Netlet applications, or using one of the reserved ports, will not cause the rule to be treated as a pre-defined application. Alternatively, disabling a rule for a pre-defined application will not affect any user-defined rules that happen to share the same name or ports. The only way to disable a rule for a user-defined application is to remove it.

For example, if a user-defined rule directs certain traffic to the Telnet port of a specific host (myTelnet|30001|myServer|23), this rule will operate independently of the rule for the predefined Netlet application for Telnet. It does not depend on whether or not the predefined Netlet application for Telnet is enabled on the Netlet Administration page of the iPlanet Portal Server Administration Console.


Note Netlet rules cannot contain any port number higher than 64000.




Client Specifications and Examples



Configuring Client Software

Clients must be configured to connect through the Netlet, which proxies that connection to the destination server. Since the Netlet resides on the client, the connections must be made to the machine named localhost.


Integrating Applet Clients

Java security restrictions require that applets can make connections only to the machine from which they are downloaded. This means that the client applet itself must be downloaded through the Netlet. Creating a Netlet rule to download an applet from the machine localhost allows the applet to connect to ports on localhost. If Netlet rules accept connections on those ports, the applet will connect to the machines to which those ports are proxied.

Applets following this procedure require no reconfiguration because these applets normally determine the name of the host from which they were served and connect to that machine name. They will attempt to connect to localhost, which the Netlet accepts and proxies.

If an applet is configured to connect to a named machine, you have two choices for redirecting the applet to connect to localhost:

  • Have each user configure the client to use localhost as the server

  • Have DNS resolve the destination server's host name to 127.0.0.1 for external queries, and to the actual IP address for internal lookups.

The second choice is recommended solution it requires no changes to the client configuration, and the client will work correctly from the Internet and the intranet.

Use the following procedure to integrate applet clients.

  1. To integrate applet clients, you need to create the proper Netlet rule to download the applet and for the applet to make connections back to the server. You also must determine whether this rule must be under a domain, role, or only for a specific user.

  2. Once you have determined where in your domain/role/user tree to place the Netlet rule, you then create the rule based on the guidelines that were given earlier in the chapter.

    Particularly, you will have to pay attention to the <URL to invoke> field and the <download applet?> field. Most likely you will be downloading your applet from a different server than the Portal Server platform server, so you need to use the <cport:server:sport> form of the <download applet?> field to specify the local Netlet listen port and the target server:port that the applet is coming from.

    In the interest of keeping one application's setup consolidated into one rule, you can add multiple listen ports onto the end of one rule. So if you applet needs three ports to talk to its host server on, then it's rule might look like this:

    arule|/dir/applet.html|2080:appletserv:2080|8030|TARGET|8030|8040|/ TARGET|8040|8050|TARGET|8050

  3. To make this rule show up in the Netlet provider, you then Click on the Domain (Role and User, if applicable) Applications -> Desktop link, and under the 'Channels' heading,

  4. Select the 'iwtNetletProvider' channel, and click on the 'Edit Channel' button.

  5. Under the 'Targets' section, add a new target to the Netlet Provider like this:

       arule|hostname

    The first part must be the name that you gave to the new Netlet rule that you created step 2 above, and the second part must be the hostname of the server that you want as the default host for this rule to connect to.


    Note By default, users have read and write privileges on Netlet Provider targets, so they can change the target hosts for the Netlet rules that you add. If you want to fix the rule target hosts, change the read/write permissions so that users only have read permission for this attribute.


  6. Click the Add button to add the target to the list of Netlet Provider targets.

  7. Click the Submit button at the bottom of the page to submit the changes to the Portal Server.

    To integrate applet clients, navigate from Manage Domains to the domain of interest, then expand the Application link and select the Netlet link.


Integrating Non-Applet Clients

Non-applet clients, such Lotus Notes or Microsoft Exchange, must be directed to connect to the client machine on which they are running. This can be done in either of two ways:

  1. Have each user configure the client to use localhost as the server.

    or

  2. Have DNS resolve the destination server's host name to 127.0.0.1 for external queries and to the actual IP address for internal lookups.

The second choice is the recommended solution because it requires no changes to the client configuration, and client will work correctly from the Internet and the intranet.

Use the following procedure to integrate non-applet clients.

  1. To integrate non-applet clients, the proper netlet rule must be created to map the application's TCP port over the Netlet. You also must determine whether this rule must go under a domain, role, or only for a specific user.

  2. Click on the Applications>Netlet link (from the Domain, Role, or User page)

    If the application requires multiple ports to be opened, you can either write multiple rules, or add the ports on to the end of a single rule.

    The Netlet rule must be in the form outlined step 2 of "Integrating Applet Clients" on page 145.

    Rule example with 2 port definitions:

    The Netlet listens on ports 9877 and 9878, and connects to ports 17888 and 17889 on the intranet server 'intra-serv', respectively.

    zrule|null|false|9877|intra-serv|17888|9878|intra-serv|17889


    Note The client-listen-port is arbitrary, but it must be a port that is not used by the client or any other Netlet rule. Ideally, the client-listen-port and the destination-host-port should be the same. A value above 2048 should be used for the client-listen-port because certain operating systems require the end user to be root with a client-listen-port below 2048.


  3. Click the Add button to add the rule to the list of Netlet Rules.

  4. Click the Submit button at the bottom of the page to submit the changes to the Portal Server.

  5. The user can start their client software after they log in and the small Netlet window has appeared and the Netlet has initialized.


Configuring Lotus Notes

You can use the Netlet to allow end users to use Lotus Notes as clients through iPlanet Portal Server.

  • By using a Netlet, access is encrypted to Lotus Notes.

  • Since Lotus Notes has an HTML client, you can use the bookmark provider on the iPlanet Portal Server Desktop to open it.


Writing a Netlet Rule for the Lotus Notes Web Client

  1. Start the iPlanet Portal Server Administration Console.

  2. Select the domain of interest and navigate to the Applications > Netlet link.

  3. Add a Netlet rule in the Netlet Rules section similar to the following:

    LotusHTML|null|false|80|lotus-server|80

    This rule, called `LotusHTML', tells the Netlet to listen for the client on port 80 and connect to the server `lotus-server' on port 80. A requirement of the Lotus Web Client is that the client listen port must match the server port. The following rule would not work:

    LotusHTML|null|false|80|lotus-server|8080

    For the above rule, the client port does not match the server port, hence the rule will not work.

  4. Click the Add button to Add the rule to the list of netlet rules.

  5. Click the Submit button at the bottom of the page to submit the changes to the Portal Server.

  6. Click on the Continue button to return to the Applications page.

  7. Click on the Back to Overview link to return to the Domain, Roles and Users page. At this point, netlet connections to the Lotus Web Client have been added. What is needed next is a link for the Application Provider to start the Lotus Notes Web Client.

  8. From the domain of interest, click on the Applications link to expand it then select Desktop.

  9. Below the Available Applications list, add the Lotus Notes application as follows:

    Lotus Notes Web Client|http://localhost:80/

    The first part is the name that the user will see in the link, the second part is the link itself.

  10. Click the Add button to add this link to the list of available applications.

  11. Scroll to the Selected Applications list and add the Lotus Notes application from the Available Applications list. Use the same name.

  12. Click the Add button to add the Lotus Notes Web Client application to the Selected Applications list.

  13. Click the Submit button at the bottom of the page. This adds a link to the application provider list on the user's desktop.


Writing a Netlet Rule for the Lotus Notes (non-Web) Client

The Netlet rule created in the following procedure lets a Lotus Notes client connect directly to a Lotus Domino server.

  1. Start the Administration Console.

  2. Click the domain of interest and navigate to the Applications>Netlet link.

  3. In the Netlet rules section, add the following rule:

    LotusClient|null|false|1352|lotus-domino|1352

    With this rule, the Lotus Notes client can connect to a Lotus Domino server through the Netlet. Remember that when the client tries to connect to the server it must not point to localhost as the server name. It must point to the actual server name of the Lotus Domino server. The server name must be the same as the system name for the server. The client must resolve that name to 127.0.0.1 when using the Netlet. There are two ways to accomplish this:

    1. Set the server name to point to 127.0.0.1 in the client host table.

    2. Export a DNS entry of the name of the server that points to 127.0.0.1.

    The server name must be the same server name that was used to configure the Domino server during setup.

  4. Click the Add button to add the rule to the list of Netlet rules.

  5. Click the Submit button to submit the changes to the Portal Server.


Writing Netlet Rules for Stand-Alone Email Clients to an IMAP or an SMTP Server

Netlet rules can be written to connect stand-alone email clients to different email servers. Although the procedure shown here uses IMAP and SMTP, this approach will work for all email servers.

  1. Start the Administration Console.

  2. On the menu on the left, click the Manage Domains.

  3. Select the domain of interest (and the role of interest, as applicable), then click the Applications link. Expand the link.

  4. Select Netlet and scroll to the "User Defined Netlet Applications," to define a netlet rule for:

    1. IMAP. For example:

      IMAPRule|null|false|143|imapserver|143

    2. SMTP servers. For example:

      IMAPRule|null|false|25|imapserver|25

The Netlet client-listen-port on the client side does not have to be the same as the destination-listen-port on the server side. If you use anything other than the standard IMAP and SMTP ports, make sure that the client is configured to connect on a port that is different from the standard port.


Note End users who use Solaris clients may have trouble connecting to port numbers lower than 1024 unless they are running as root.


  1. Click the Add button to add this rule to the list of Netlet rules.

  2. Click the Submit button to submit these changes to the Portal Server.


Configuring the Netscape Mail Client

End users may have to configure the Netscape browser they are using for mail servers. The following procedure will help them through this process. The instructions are for Netscape 4.5. See the Netscape documentation for help with configuring other versions of the Netscape browser.

End users must do the following:

  1. Start the Netscape browser.

  2. In the menu bar of the Netscape browser, click Edit and select Preferences.

  3. Click the triangle before Mail & Newsgroups to see the items in this category.

  4. Click Mail Servers.

  5. In the section "Incoming Mail Servers," click the Add button to display the window for adding a server and its port.

  6. On the General tab for the Server Name, type the following:

    localhost:any_port_1

    If port 143 is used as the client-listen-port, they only have to type localhost.

    For the server, type the following:

    localhost:any_port_2

    If port 25 is used as the client-listen-port, they only have to type localhost.


Accessing Netscape Mail

End users must do the following:

  1. Log in to the iPlanet Portal Server Desktop. Upon successful login, the netlet application will start and Netscape mail can be accessed.

  2. Open the Netscape mail client.


    Note For information on adding your own link for Netscape Mail to the remote file and windowing window, see Adding LInks to Predefined Applications and to Third-Party Browser-Based Clients the section "Adding Links to Predefined Applications and to Third-Party Browser-Based Clients" elsewhere in this appendix. The URL to add is HREF= MAILBOX:.



Configuring Netlet for Use With Microsoft Outlook and Exchange Server

  1. Start the Portal Server Administration Console

  2. Determine within what domain and at what level within the role tree the Netlet rule will apply.

  3. Click on the Applications -> Netlet link.

  4. Add a Netlet rule in the 'Netlet Rules' list window like the following rule:

       OutlookEx|null|false|135|exchange|135

    This rule, called 'OutlookEx', tells the Netlet to listen on the client on port 135 and connect to the server 'exchange' on port 135. The Outlook client uses this port to make an initial attempt to contact the Exchange Server and determine what subsequent ports it will be using to talk to the server.

  5. Click the Add button to add the rule to the list of Netlet Rules.

  6. Click the Submit button at the bottom of the page to submit the changes to the Portal Server.

  7. Click on the Continue button to continue.

  8. On the client machine, the user must change the hostname of the Exchange server that is configured in their Outlook client to be 'localhost'. The location of this option varies with different versions of Outlook.

  9. On the client machine, the user must now map the hostname (single and fully qualified) of the exchange server to the IP address 127.0.0.1 using the hosts file.

    On Windows 95/98, the file is in \Windows\Hosts On Windows NT4, the file is in \WinNT\System32rivers...tc\Hosts.

    The entry looks like this:

       127.0.0.1 exchange exchange.company.com

    The exchange server sends back its own name to the Outlook client, and so this mapping is to insure that the Outlook client uses the Netlet client to make the connection back to the server.


End User Access to Microsoft Exchange Server

End users must do the following:

  1. Log into the iPlanet Portal Server desktop.

  2. Once they have logged into the desktop and the small Netlet window has appeared and the Netlet has started, they are ready to access the Exchange server.

  3. Open the Outlook client.


Previous     Contents     Index     Next     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated May 04, 2000