- How this Article is Organized
- Obtaining the Scripts and Tools for this Article
- Integration – A Historical Perspective
- Pre-Cooking and General Preparation
- Outlook Fat Client a la Carte Recipe
- Outlook Express Messaging Soup Recipe
- OWA Over a Netlet With a DNS Twist Recipe
- OWA Luau with Rewriter Fire Dancing: the 3 o'clock Show
- OWA Luau with Rewriter Hula Dancing: the 6 o'clock Show
- Glossary
- About the Author
- Acknowledgements
- Bibliography
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
OWA Over a Netlet With a DNS Twist Recipe
This tasty treat is compliments of Thor Mitchell.
Ingredients
Client:
Internet Explorer 5.5SP2 with December 2002 Security update
One Netlet rule required to listen to HTTP traffic on port 80
Advantage:
OWA access without the rewriter rules or client-side configuration
Disadvantages:
Requires a split DNS configuration.
Embedded URLs which do not have external DNS entries will not be accessible.
A Netlet rule could conflict with a local web server such as IIS, personal web server, Netscape Fastrack, and so forth, using a standard port.
Generates significant overhead on the Gateway due to mass encryption and decryption.
No BASIC authentication SSO to the Exchange server.
Sun ONE Portal Server 3.0 software does not currently support modern browsers for the NetApps.
Netlet traffic may be denied by some proxying firewalls or proxies which perform SSL packet-level investigation.
What
Create a Netlet rule to listen to local port 80.
Create a public DNS entry for the Exchange server, which maps to the local loopback address.
Create a link which will not be rewritten on the portal desktop, to launch OWA.
How
To Create a Netlet Rule to Listen on Local Port 80:
Log in to the Portal Administration Console.
Select Manage Domains.
From the list, select the Domain name for which the Exchange users are mapped.
Expand the Applications key.
Select Netlet.
Add OWA|null|false|80|exchange-server|80 in the form field under the Netlet Rules attribute (where exchange-server is the fully qualified address of the Exchange server).
Select Add.
Uncheck Warning for Popup windows.
Scroll to the bottom of the page and check Apply changes to all subRoles.
Select Submit.
Log out of the Portal Administration Console.
Log in as a user to the Portal Gateway.
Verify the static Netlet rule is configured by looking at the output of the browser's Java console, and make sure there is an entry for each of the ports which the Netlet should be listening on.
NOTE
If the Java Console output indicates a bind error with port 80, the service already listening on that port must be disabled prior to connecting remotely with Exchange.
To Create a DNS Entry Which Will Publicly Resolve the Exchange Server Address to the Loopback Address
The DNS resolution must be made from a public DNS server. Most companies have internal subdomains which are subsets of their external second-level domains. In this case, an entry must be added to the SOA of the second-level domain to resolve the fully qualified Exchange server address to localhost.
The following procedure uses BIND 8 as an example of how to create a split DNS. If you are using a different version, the procedure will differ.
Use BIND 8 (using int as a fictitious subdomain of sun.com), and perform the following steps:
-
Add a zone entry for to the BIND config file (/etc/named.conf):
- Create a Start of Authority in the hosts file:
Push DNS maps:
Test lookup:
////////////////////////////////////////////
// Zone info for int.sun.com domain
zone "int.sun.com" in {
type master;
file "named.sun_int_hosts";
// Restrict zone transfers to localhost
allow-transfer { 127.0.0.1; };
};
@ IN SOA int.sun.com.
postmaster.int.sun.com.
(
101 ; serial number
3600 ; refresh
600 ; retry
2073600 ; expire
3600 ) ; minimum TTL
IN NS ns-sun.int.sun.com.
; hostname of Exchange server
exchange-server IN A 127.0.0.1
# pkill -HUP named
# nslookup exchange-server Server: ns-sun.int.sun.com Address: 10.0.0.1 Name: exchange-server.int.sun.com Address: 127.0.0.1
NOTE
For internal testing purposes, the mapping can be done by adding an entry in the client's hosts file (c:\windows\hosts). For example:
127.0.0.1 exchange-server # Fully qualified address of Exchange server
To Create a Link to Launch OWA Which Will Not Be Rewritten on the Portal Desktop:
Edit the display.template file (located in the ./iwtBookmarkProvider directory.
Change the value of exchange-server to the fully qualified URL of your Exchange host.
Copy the display.template file to /etc/opt/SUNWips/desktop/iwtBookmarkProvider/display.template or to your own custom templates directory.
Restart the Portal Server and Gateway component.
-
Log in to the Gateway and verify that the link exists and works (FIGURE 1).
See "Obtaining the Scripts and Tools for this Article" on page 3).
Note the use of top.window.open instead of window.open to avoid the link from being rewritten. This obviously won't work if top.window.open is already in the Gateway profile.
NOTE
To create a single logout, use the exWin handle from the LogOut link defined in menubar.html template file in:
/etc/opt/SUNWips/desktop/iwtDesktop/
If there are multiple Exchange servers, the Netlet rule can be made dynamic, and links can be created directly from the desktop which will launch the Netlet. An example is included in the ./iwtBookmarkProvider/display.template2 downloadable file.
)
FIGURE 1 Example
of new Bookmark Provider
Why
This solution makes use of the popular practice of implementing a split DNS. By using a split DNS, the internal network IP addresses are not exposed, and by mapping the Exchange entry to localhost, the result is that would-be wrongdoers will simply end up talking to themselves. If exposing a single hostname is still a problem, a reverse proxy can be used in front of the Exchange server, and the Netlet rule can be configured so the traffic will be directed to the proxy instead of to the Exchange server. This allows the proxy to perform the correct hostname resolution and forward the request. This solution is ideal for customers whose end users require the full feature set of Exchange but cannot use the Outlook fat client recipe. It is also advantageous in situations where the Gateway profile has already been considerably modified, but Exchange is the primary application that remote users require. Beefy Gateway hardware is also recommended for this recipe. A proxy might also be a good solution if the internal DNS is not a subdomain of the external DNS and when the domain is unregistered.