IIS Front end servers and Domino - Show and Tell Thursday/Friday/Saturday
Category Lotus
Bookmark :
So I've been a little (OK, more than a little) bit busy recently! So, here's my SNTT article. On a Friday. Why? Because I want to. Nuff said
How to Configure IIS as a Front End server to Domino
Configure IIS
First up, you need to configure IIS to use the plugin (Combined from the Domino Admin help and a technote)
Create the following directory structure on the IIS machine (you can use any drive)
C:\WebSphere\AppServer\bin
C:\WebSphere\AppServer\config
C:\WebSphere\AppServer\etc
C:\WebSphere\AppServer\logs
Copy the following files from the Domino server to the IIS server:
Copy data\domino\plugins\plugin-cfg.xml to c:\Websphere\Appserver\bin
Copy data\domino\plugins\<WAS version>\w32\iisWASPlugin_http.dll to c:\websphere\AppServer\bin
Start IIS and create a new virtual directory for the web site instance that you intent to work with Websphere Application Server. These instructions assume that you are using the Default Web Site
Click Programs > Administrative Tools > Internet Information Services (IIS) Manager on a Windows Server 2003 Standard Edition system, for example.
Expand the tree on the left until you see Default Web Site. Right-click Default Web Site > New > Virtual Directory to create the directory with a default installation.
Type sePlugins in the Alias field in the Virtual Directory Alias panel of the Virtual Directory Creation Wizard, then click Next.
Browse to the location of the plugins directory under the Domino Web server, or the WebSphere\bin folder you created.
Select the appropriate permission check boxes in the Virtual Directory Access Permissions panel of the wizard. Select the Read check box and the Execute (such as ISAPI applications or CGI) check box, for example.
Click Next to add the sePlugins virtual directory to your default Web site.
Click Finish when the success message displays.
Create a text file named plugin-cfg.loc in the same directory as the plugins. The first line of the plugin-cfg.loc file identifies the location of the plugin-cfg.xml file.
Right-click the Web Sites folder in the left pane navigation tree of the IIS Manager panel, and click Properties.
Add the Internet Services Application Programming Interface (ISAPI) filter into the IIS configuration.
In the Web Site Properties panel, perform the following steps:
Click the ISAPI Filters tab.
Click Add to open the Add/Edit Filter Properties dialog window.
Type iisWASPlugin in the Filter name field.
Click Browse and point at the iisWASPlugin_http.dll in the plugins directory for the value of the Executable field.
Click OK to close the Add/Edit Filter Properties dialog window.
Click OK to close the Web Site Properties window.
Set the value in the plugin-cfg.loc file to the location of the configuration file, for example,
C:\WebSphere\config\plugin-cfg.xml.
Note that the last line of the .loc file should be a blank line (carriage return).
Configure the Web server to run WebSphere Application Server extensions:
Expand the left pane navigation tree until you see the Web Service Extensions folder in the IIS Manager panel.
Click Web Service Extensions to display information about what Web service extensions are allowed.
Click All Unknown ISAPI Extensions on the right side of the panel.
Click Allow in the middle pane. The status field for the All Unknown ISAPI Extensions changes to Allowed.
NOTE: If you are concerned with allowing all unknown ISAPI extensions because you have other ISAPI extensions on this server, follow the steps in Technote 1168244 to add a new Web service extension for Domino.
Configure the XML file
Now, you need to configure the xml configuration file (From Domino Admin help)
1. Open plugin-cfg.xml in Notepad.
2. Modify the <Transport> element to target the appropriate Domino server. To do this, change the Hostname and Port parameters to the proper values required for the plug-in to reach your back-end server's HTTP task. For example:
<!-- Server groups provide a mechanism of grouping servers together. -->
<ServerGroup Name="default_group">
<Server Name="default_server">
<!-- The transport defines the hostname and port value that the web server
plug-in will use to communicate with the application server. -->
<Transport Hostname="mydomino.server.com" Port="81" Protocol="http"/>
</Server>
</ServerGroup>
3. Add these directives to the top of the <UriGroup> section. These directives specify common URL patterns needed for accessing Domino Web applications.
<UriGroup Name="default_host_URIs">
<Uri Name="/*.nsf"/>
<Uri Name="/icons/*"/>
<Uri Name="/domjava/*"/>
<Uri Name="/execcgi/*"/>
<Uri Name="/cgi-bin/*"/>
<Uri Name="/servlet/*"/>
<Uri Name="/download/*"/>
<Uri Name="/mail/*" />
Note: there are some other things you may want to do!
Certainly, I want URL's with .NSF in the middle of them to be served by domino, so change the line <Uri Name = "/*.nsf"/> to : <Uri Name = "/*.nsf/*"/>
Next up, for DWA and java applets to load, you need to enable the HTML direcectory too. Be careful with this one though, as you may well have a HTML directory in IIS too.
Add the line: <Uri Name = "/html/""/>
Configure Domino
Add the following line the Domino servers' notes.ini
HTTPEnableConnectorHeaders=1
That's it!
Authentication
Next you need to look at authentication. Domino doesn't support Digest authentication. In certain versions of the SUN JVM, there is also a JRE bug with NTLM Authentication (which also affects reverse proxys too). Although the site will authenticate - any java applets (such as view outlines or toolbars) won't without an extra username/password box -
So, we'll start with Basic authentication and then try working up. You should be aware that basic authentication doesn't encrypt the username&password, so you should SSL enable the site too.
For basic authentication (and perhaps others), you will probably want to remove the need to enter domain\username in the user login formm and just use Username / Password. To do this, you can set a default domain.
Right click on the web site
Select Directory Security
Select "Basic authentication - deselect any others (except anonymous, if you wish to allow this)
Enter the AD Domain name in the "Domain" dialog box
Users can now log in using just their AD username and password
Once you've got this working, try using NTLM authentication. The advantage of this is that your IE users won't need to enter any passwords at all - they will be logged in using their existing desktop login ID.
Enable SSL
Next, you'll need to enable SSL on the IIS server. Here's the clever part, you can enable SSL on the IIS server and not on the domino server. IIS will act as a SSL accelerator, taking the load away from Domino (and the need to buy another cetificate).
Setting up SSL on IIS is fairly simple, but if you want to setup a self certiified certificate for testing you do need to install certificate services first. (This is from memory, so may not be exactly correct)
Go to Control Panel add/remove programs and select the windows components.
Add in certiifcation services and let that install.
Open up the Certificate services administrator.
Right click on the server, click Actions\Create certificate (or similar)
Select an enterprise root certificate (top option)
Fill out the details, until you're finished.
Go back into IIS admin and right click the default site
Click on the Directory Security tab
Click on Certificates
Follow the wizard to select a certificate form your local Certificate services, and the self signed SSL certificate will install itself.
User accounts
Finally, you need to configure the user accounts, so that Domino recognises them. IIS passes back the username you have logged into IIS with, telling Domino that you have allready been authenticated. So, you will need to add your AD account name to the "Username" field in Domino. For instance:
Warren.Elsmore
et voila! You should now be able to use a browser to connect to IIS over SSL. IIS will authenticate you against Active Directory, then pass you back on an unencrypted HTTP connection to Domino. Domino web access, authenticated via AD. Easy, eh? <sarcamsm mode off>
Finally
I have encountered one bug using IIS front end servers at present. Within Domino Web Access, you can't edit your welcome page. - UPDATE: According to IBM, this does work, so I've got a PMR open to see why my test rig doesn't work. It's bound to be something simple...
Bookmark :
So I've been a little (OK, more than a little) bit busy recently! So, here's my SNTT article. On a Friday. Why? Because I want to. Nuff said
How to Configure IIS as a Front End server to Domino
Configure IIS
First up, you need to configure IIS to use the plugin (Combined from the Domino Admin help and a technote)
Create the following directory structure on the IIS machine (you can use any drive)
C:\WebSphere\AppServer\bin
C:\WebSphere\AppServer\config
C:\WebSphere\AppServer\etc
C:\WebSphere\AppServer\logs
Copy the following files from the Domino server to the IIS server:
Copy data\domino\plugins\plugin-cfg.xml to c:\Websphere\Appserver\bin
Copy data\domino\plugins\<WAS version>\w32\iisWASPlugin_http.dll to c:\websphere\AppServer\bin
Start IIS and create a new virtual directory for the web site instance that you intent to work with Websphere Application Server. These instructions assume that you are using the Default Web Site
Click Programs > Administrative Tools > Internet Information Services (IIS) Manager on a Windows Server 2003 Standard Edition system, for example.
Expand the tree on the left until you see Default Web Site. Right-click Default Web Site > New > Virtual Directory to create the directory with a default installation.
Type sePlugins in the Alias field in the Virtual Directory Alias panel of the Virtual Directory Creation Wizard, then click Next.
Browse to the location of the plugins directory under the Domino Web server, or the WebSphere\bin folder you created.
Select the appropriate permission check boxes in the Virtual Directory Access Permissions panel of the wizard. Select the Read check box and the Execute (such as ISAPI applications or CGI) check box, for example.
Click Next to add the sePlugins virtual directory to your default Web site.
Click Finish when the success message displays.
Create a text file named plugin-cfg.loc in the same directory as the plugins. The first line of the plugin-cfg.loc file identifies the location of the plugin-cfg.xml file.
Right-click the Web Sites folder in the left pane navigation tree of the IIS Manager panel, and click Properties.
Add the Internet Services Application Programming Interface (ISAPI) filter into the IIS configuration.
In the Web Site Properties panel, perform the following steps:
Click the ISAPI Filters tab.
Click Add to open the Add/Edit Filter Properties dialog window.
Type iisWASPlugin in the Filter name field.
Click Browse and point at the iisWASPlugin_http.dll in the plugins directory for the value of the Executable field.
Click OK to close the Add/Edit Filter Properties dialog window.
Click OK to close the Web Site Properties window.
Set the value in the plugin-cfg.loc file to the location of the configuration file, for example,
C:\WebSphere\config\plugin-cfg.xml.
Note that the last line of the .loc file should be a blank line (carriage return).
Configure the Web server to run WebSphere Application Server extensions:
Expand the left pane navigation tree until you see the Web Service Extensions folder in the IIS Manager panel.
Click Web Service Extensions to display information about what Web service extensions are allowed.
Click All Unknown ISAPI Extensions on the right side of the panel.
Click Allow in the middle pane. The status field for the All Unknown ISAPI Extensions changes to Allowed.
NOTE: If you are concerned with allowing all unknown ISAPI extensions because you have other ISAPI extensions on this server, follow the steps in Technote 1168244 to add a new Web service extension for Domino.
Configure the XML file
Now, you need to configure the xml configuration file (From Domino Admin help)
1. Open plugin-cfg.xml in Notepad.
2. Modify the <Transport> element to target the appropriate Domino server. To do this, change the Hostname and Port parameters to the proper values required for the plug-in to reach your back-end server's HTTP task. For example:
<!-- Server groups provide a mechanism of grouping servers together. -->
<ServerGroup Name="default_group">
<Server Name="default_server">
<!-- The transport defines the hostname and port value that the web server
plug-in will use to communicate with the application server. -->
<Transport Hostname="mydomino.server.com" Port="81" Protocol="http"/>
</Server>
</ServerGroup>
3. Add these directives to the top of the <UriGroup> section. These directives specify common URL patterns needed for accessing Domino Web applications.
<UriGroup Name="default_host_URIs">
<Uri Name="/*.nsf"/>
<Uri Name="/icons/*"/>
<Uri Name="/domjava/*"/>
<Uri Name="/execcgi/*"/>
<Uri Name="/cgi-bin/*"/>
<Uri Name="/servlet/*"/>
<Uri Name="/download/*"/>
<Uri Name="/mail/*" />
Note: there are some other things you may want to do!
Certainly, I want URL's with .NSF in the middle of them to be served by domino, so change the line <Uri Name = "/*.nsf"/> to : <Uri Name = "/*.nsf/*"/>
Next up, for DWA and java applets to load, you need to enable the HTML direcectory too. Be careful with this one though, as you may well have a HTML directory in IIS too.
Add the line: <Uri Name = "/html/""/>
Configure Domino
Add the following line the Domino servers' notes.ini
HTTPEnableConnectorHeaders=1
That's it!
Authentication
Next you need to look at authentication. Domino doesn't support Digest authentication. In certain versions of the SUN JVM, there is also a JRE bug with NTLM Authentication (which also affects reverse proxys too). Although the site will authenticate - any java applets (such as view outlines or toolbars) won't without an extra username/password box -
So, we'll start with Basic authentication and then try working up. You should be aware that basic authentication doesn't encrypt the username&password, so you should SSL enable the site too.
For basic authentication (and perhaps others), you will probably want to remove the need to enter domain\username in the user login formm and just use Username / Password. To do this, you can set a default domain.
Right click on the web site
Select Directory Security
Select "Basic authentication - deselect any others (except anonymous, if you wish to allow this)
Enter the AD Domain name in the "Domain" dialog box
Users can now log in using just their AD username and password
Once you've got this working, try using NTLM authentication. The advantage of this is that your IE users won't need to enter any passwords at all - they will be logged in using their existing desktop login ID.
Enable SSL
Next, you'll need to enable SSL on the IIS server. Here's the clever part, you can enable SSL on the IIS server and not on the domino server. IIS will act as a SSL accelerator, taking the load away from Domino (and the need to buy another cetificate).
Setting up SSL on IIS is fairly simple, but if you want to setup a self certiified certificate for testing you do need to install certificate services first. (This is from memory, so may not be exactly correct)
Go to Control Panel add/remove programs and select the windows components.
Add in certiifcation services and let that install.
Open up the Certificate services administrator.
Right click on the server, click Actions\Create certificate (or similar)
Select an enterprise root certificate (top option)
Fill out the details, until you're finished.
Go back into IIS admin and right click the default site
Click on the Directory Security tab
Click on Certificates
Follow the wizard to select a certificate form your local Certificate services, and the self signed SSL certificate will install itself.
User accounts
Finally, you need to configure the user accounts, so that Domino recognises them. IIS passes back the username you have logged into IIS with, telling Domino that you have allready been authenticated. So, you will need to add your AD account name to the "Username" field in Domino. For instance:
Warren.Elsmore
et voila! You should now be able to use a browser to connect to IIS over SSL. IIS will authenticate you against Active Directory, then pass you back on an unencrypted HTTP connection to Domino. Domino web access, authenticated via AD. Easy, eh? <sarcamsm mode off>
Finally
I have encountered one bug using IIS front end servers at present. Within Domino Web Access, you can't edit your welcome page. - UPDATE: According to IBM, this does work, so I've got a PMR open to see why my test rig doesn't work. It's bound to be something simple...
-