Microsoft TMG Integration
From Swivel Knowledgebase Wiki
Contents |
Microsoft Threat Management Gateway Integration
This guide describes how to integrate PINsafe with Microsoft Forefront Threat Management Gateway using RADIUS authentication. No additional software is required.
If you want more control over authentication, with support for restricting PINsafe to certain hostnames and allowing non-PINsafe users to authenticate, we now have a version of the ISA filter that is compatible with TMG. See the ISA filter documentation for more information.
Configuring PINsafe
- Log on to the PINsafe Admin Console
- Under RADIUS -> Server, make sure that the server is enabled. All the other settings can be left as default.
- Under RADIUS -> NAS, enter a name in the blank identifier box (e.g. “TMG”). Enter the name or IP address of the TMG server, and a chosen secret. Remember what you enter in the Secret box, as you will need it later.
- Click Apply.
Configuring Firewall Rules
It is assumed that you already have a firewall rule set up to support the website you need to protect. If not, use the appropriate wizard under Firewall Policy Tasks to set up the rule.
Modifying the Website Access Rule
To support PINsafe authentication, all you need to do is to right-click on the Listener for the rule and select Properties. On the Authentication tab, select HTML Form Authentication, if it is not already selected.
Under most circumstances, you will need to authenticate to Windows Active Directory as well as to PINsafe. Configure both AD and PINsafe as authentication servers. To use Windows and PINsafe authentication, check the box marked “Collect additional delegation credentials in the form”. Make sure “RADIUS OTP” is selected in the lower box, then click on “Configure Validation Servers”. On the RADIUS Servers tab, click Add. Enter the IP or name of the PINsafe server and the shared secret that you entered earlier for the PINsafe NAS.
If you only want to use PINsafe to authenticate, and no other method, then leave the option for additional delegation credentials unchecked and select either RADIUS or RADIUS OTP. You can only select RADIUS OTP if the Authentication Delegation option on the main rule is No Delegation.
NOTE: As described below, you may choose to create a new set of custom login pages, rather than replacing the existing ones. If you do, you will need to check the option to use custom HTML forms (on the Forms tab), and enter the name of the custom forms set.
Proxying the TURing Image
In order to allow PINsafe to deliver a TURing image to the end user without exposing the PINsafe server to the internet, it is necessary to create a firewall rule to proxy it. If you are using dual channel only, except for dual channel on demand, you can skip this step.
- Click on Publish Web Sites.
- Call the rule PINsafe Image, or whatever you like.
- Accept the defaults for the first few steps.
- Under internal site name, enter the name of the PINsafe server. Note that this name must match the name of the SSL certificate on the PINsafe server, since SSL requests through this rule must not generate any errors. Alternatively, you can configure PINsafe not to use HTTPS.
- For Path, enter /proxy/SCImage (assuming this is an appliance, or /pinsafe/SCImage if not). For dual channel on demand, change SCImage to DCMessage.
- Select Any domain name.
- Create a new Listener. Call it TURing, or whatever you like.
- Require SSL (if you don't have an SSL certificate installed, select non-SSL)
- Select External networks only
- Select an SSL certificate if required
- Select No Authentication
- The remaining Listener options do not require configuration
- Back on the publishing wizard, accept the defaults for the remaining options.
- Once the rule is complete, right-click and select Properties
- On the Bridging tab, choose to redirect to port 8443 for context /proxy, or 8080 for context /pinsafe.
Customising Login Pages
If you are using dual channel authentication in PINsafe, and do not require an embedded TURing image in your login page, you do not need to customise the login pages. This does not apply to dual-channel on-demand, for which the customisation IS required.
You can choose either to customise the default login pages, or to create a custom set of pages. If you are not using PINsafe for all authentication rules on this TMG, you must create a custom set.
To create a custom set of rules:
- In Explorer, go to the TMG root folder: under a default installation, this is C:\Program Files\Microsoft Forefront Threat Management Gateway.
- Select the Templates sub-folder
- Select the CookieAuthTemplates sub-folder.
- Make a copy of one of the folders you find underneath here: for an Exchange firewall rule, select Exchange, and for other rules select ISA.
- Give the folder an appropriate name. NOTE: remember to change the custom forms option on the listener to specify the name of this folder.
If you choose to replace the existing login pages, select the CookieAuthTemplates folder as described above, then select either the ISA sub-folder, or the Exchange sub-folder, depending on whether or not you are customising Exchange access. If you have created a custom set, select that. Select the HTML sub-folder.
NOTE: if you are replacing existing standard login pages, make sure you take backup copies of any files you replace.
There are 3 files you might need to replace, depending on which authentication option you selected:
- For RADIUS authentication only, replace usr_pwd.htm
- For RADIUS OTP authentication only, replace usr_pcode.htm
- For dual Windows and RADIUS OTP authentication, replace usr_pwd_pcode.htm
The custom pages can be found here.
You will need to edit the file(s), and change the value of imageUrl to the appropriate external URL for the TURing image, as determined by the firewall rule you created earlier.
Troubleshooting
The thing you are most likely to have problems with in this integration is SSL certificates. When linking to a server that requires SSL, the TMG will fail if there are any errors in SSL handshaking. The guidelines here should help.
NOTE: to import a certificate from a PINsafe appliance into a TMG to use as a proxy for the PINsafe server, you must generate the private key with the argument -keyalg RSA. This is NOT the default when using the CMI options, so the certificate must be generated from the command line.
If you create SSL certificates using an internal Windows certificate authority, and generate the certificate request from the web interface, be aware that certificates generated using the Web Server template are not exportable. You need to create a new template for exportable web server certificates, as detailed here. Also, TMG does not support CNG / Windows 2008 certificates, so when creating the new template, make sure you select Windows 2003 compatibility. For the same reason, if you generate a new certificate request using the certificates MMC plug-in (details not given here), make sure you select Legacy rather than CNG. Our recommendation, however, is to use Keystore Explorer (see SSL Solutions article) and to generate the certificate request with that.
As a last resort, particularly if the PINsafe Appliance is not to be visible on the internet, you can simply disable HTTPS on the PINsafe server. See the appliance documentation for details on this. Note that if you do disable https, you must alter the TURing Listener to match the settings.
If users are allowed to authenticate without PINsafe authentication ensure 'Require all users to authenticate' option is checked.
