If your Identity Server must communicate through a firewall, you must either set up a hole in your firewall for TCP ports 8080 or 8443 (default ports used respectively for non secure and secure communication with Identity Server), or configure the Identity Server service to use TCP port 80 or 443.
On a Windows Identity Server, you need to set the port in the Base URL and save the changes. You then need to modify the Tomcat server.xml file located in the \Program Files\Novell\Tomcat\conf directory. Change the ports from 8080 and 8443 to 80 and 443, then restart the Tomcat service.
On a Linux Identity Server, the steps are more complicated. The Identity Server service (hosted on Tomcat) runs as a non-privileged user on Linux and cannot therefore bind to ports below 1024. In order to allow requests to port 80/443 while Tomcat is listening on 8080/8443, the preferred approach is to use iptables to perform a port translation. Port translation allows the base URL of the Identity Server to be configured for port 433 and to listen on this port, and the iptables translates it to port 8443 when communicating with Tomcat.
If you have disabled the SLES 10 firewall and do not have any other Access Manager components installed on the Identity Server, you can use a simple iptables script to translate the ports. See Section 12.4.1, A Simple Redirect Script.
If you have configured the SLES 10 firewall or have installed other Access Manager components on the Identity Server, you use a custom rule script that allows for multiple port translations. See Section 12.4.2, Configuring iptables for Multiple Components.
These sections describe two solutions out of the myriad of possible solutions. For more information about iptables, see the following:
This simple solution only works if you are not using iptables to translate ports of other applications or Access Manager components. For a solution that works with multiple components, see Section 12.4.2, Configuring iptables for Multiple Components.
In the Administration Console, click > > , and configure the base URL with HTTPS as protocol, and the TCP Port as 443.
Update the Identity Server.
At a terminal window, log in as the root user.
Create a file to hold the iptables rule and place it in the /etc/init.d directory.
For example, /etc/init.d/AM_IDP_Redirect. Ensure it has execute rights. You can use CHMOD as appropriate.
An example of a redirect startup file for this purpose might be:
#!/bin/sh # Copyright (c) 2008 Novell, Inc. # All rights reserved. # #! /bin/sh #! /etc/init.d/idp_8443_redirect # ### BEGIN INIT INFO # Provides: idp_8443_redirect # Required-Start: # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Description: Redirect 8443 to 443 for Novell IDP ### END INIT INFO # # Environment-specific variables. IPT_BIN=/usr/sbin/iptables INTF=eth0 ADDR=10.10.0.1 . /etc/rc.status
# First reset status of this service
rc_reset
case "$1" in
start)
echo -n "Starting IP Port redirection"
$IPT_BIN -t nat --flush
$IPT_BIN -t nat -A PREROUTING -i $INTF -p tcp --dport 80 -j DNAT --to ${ADDR}:8080
$IPT_BIN -t nat -A PREROUTING -i $INTF -p tcp --dport 443 -j DNAT --to ${ADDR}:8443
$IPT_BIN -t nat -A OUTPUT -p tcp -d $ADDR --dport 443 -j DNAT --to ${ADDR}:8443
$IPT_BIN -t nat -A OUTPUT -p tcp -d $ADDR --dport 80 -j DNAT --to ${ADDR}:8080
rc_status -v
;;
stop)
echo -n "Flushing all IP Port redirection rules"
$IPT_BIN -t nat --flush
rc_status -v
;;
restart)
$0 stop
$0 start
rc_status
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
;;
esac
rc_exit
For more information about init scripts in SUSE Linux Enterprise Server, see 20.2.2 Init Scripts in the SUSE Linux Enterprise Server 10 Installation and Administration Guide.
Modify the environment-specific variables found in the following lines:
# Environment-specific variables. IPT_BIN=/usr/sbin/iptables INTF=eth0 ADDR=10.10.0.1
To ensure that the iptables rule is active after rebooting, start YaST, click , > , select , select the file you created, enable runlevels boot, 3 and 5 for the file, then start the service.
To verify that your script is running, enter the following command:
ls /etc/init.d/rc3.d | grep -i AM_IDP_Redirect
Reboot the Identity Server machine.
After rebooting, verify that port 443 is being routed to the Identity Server by entering the following command:
iptables -t nat -nvL
You should see an entry similar to the following:
pkts bytes target prot opt in out source destination 17 748 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:10.10.0.1:8443
This entry states that eth0 is routing TCP port 443 to IP address 10.10.0.1.
(Conditional) If your Identity Server cluster configuration contains more than one Identity Server, repeat these steps on each server in the cluster.
If you need to use iptables for multiple components (the host machine, the Identity Server, or the SSL VPN server), you need to centralize the commands into one manageable location. The following sections explain how to use the SuSEFirewall2 option in YaST to centralize the commands.
The Identity Server and the SSL VPN server use different routing methods, so their commands are different. The Identity Server requires pre-routing commands, and the SSL VPN server uses post-routing commands.
In the Administration Console, click > > , and configure the base URL with HTTPS as protocol, and the TCP Port as 443.
Update the Identity Server.
On the Identity Server, edit the /etc/sysconfig/SuSEfirewall2 file.
Change the FW_CUSTOMRULES="" line to the following:
FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
Save the changes and exit.
Open the /etc/sysconfig/scripts/SuSEfirewall2-custom file in an editor.
This is the custom rules file you specified in Step 3.
Add the following lines under the fw_custom_before_port_handling() section:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to 10.10.0.1:8443 iptables -t nat -A OUTPUT -p tcp -o eth0 --dport 443 -j DNAT --to 10.10.0.1:8443 true
The first command rewrites all incoming requests with a destination TCP port of 443 to TCP port 8443 on the 10.10.0.1 IP address for eth0. Modify the IP address to match the IP address of your Identity Server.
The second command rewrites the health checks.
Select one of the following:
If you need to add commands for the SSL VPN server, continue with Adding the SSL VPN Commands.
If you don’t need to add any more commands, save the file, then continue with Step 7.
At the system console, restart the firewall by executing the following command:
/etc/init.d/SuSEfirewall2_setup restart
After rebooting, verify that port 433 is being routed to the Identity Server by entering the following command:
iptables -t nat -nvL
You should see an entry similar to the following:
pkts bytes target prot opt in out source destination 17 748 DNAT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:10.10.0.1:8443
This entry states that eth0 is routing TCP port 443 to IP address 10.10.0.1:8443.
(Conditional) If your Identity Server cluster configuration contains more than one Identity Server, repeat these steps on each server in the cluster.
These steps assume that you have completed at least Step 3 in Adding the Identity Server Commands.
Add the following lines to the fw_custom_before_masq section of the /etc/sysconfig/scripts/SuSEfirewall2-custom file.
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -j SNAT --to 10.1.1.1
The 10.8.0.0/16 address is configured as a tunnel subnet, and the 10.1.1.1 address is your private interface.
Add the following lines to the fw_custom_before_denyall section.
iptables -A $chain -j ACCEPT -s 10.8.0.0/22 iptables -A $chain -j ACCEPT -d 10.8.0.0/22
The file should look similar to the following:
fw_custom_before_masq() {
iptables -t nat -A POSTROUTING -s 10.8.0.0/16 -j SNAT --to 10.1.1.1
true
}
fw_custom_before_denyall() {
for chain in input_ext input_dmz input_int forward_int forward_ext forward_dmz; do
iptables -A $chain -j ACCEPT -s 10.8.0.0/22
iptables -A $chain -j ACCEPT -d 10.8.0.0/22
done
true
}
Save the file.
Restart the firewall by executing the following command:
/etc/init.d/SuSEfirewall2_setup restart
Verify that the post SSL VPN routing iptables filters have been registered correctly by issuing the following command:
iptables -t nat -nvL
You should see information similar to the following if the filters have been registered correctly:
Chain POSTROUTING (policy ACCEPT 20987 packets, 1266K bytes) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * * 10.8.0.0/16 0.0.0.0/0 to:10.1.1.1