Rob's Tech Fun and Games

ISA Server 2006 is a strange, temperamental beast, and often needs to be cajoled into fairly standard functionality.  In order to deploy security so that users can authenticate from both the DMZ Active Directory, and the internal network (with a one way trust between the two) you need to deploy LDAP authentication.  In order to act as a secure front end and logging point, forms based authentication is recommended, particularly if branded authentication pages are important for you.  If you want to use it as a front end to extranet systems, a custom login page is pretty much a necessity, and if you need external users to change their passwords (rather than using code within your extranet or OWA), you’ll need to configure LDAP over SSL (LDAPS).

Before you begin, you’ll need to configure a domain user for ISA server to use to bind to the LDAP server, with rights to make changes if you need password change functionality.

You’ll need to ensure that your active directory domain can support LDAPS.  In order to do this, you need to intall certificate services, and ensure that the domain controllers and your ISA server all have server certificates installed, with the certificates matching their fully qualified domain names correctly. 

You can find a pretty complete guide here:

http://technet.microsoft.com/en-gb/library/bb794854.aspx

I struggled with a few points – its not clear that for password changes to work, for example, you need to use a user account with the right to make AD changes when defining the LDAP server set, and you don’t in order to simply log users onto the domain.  You apparently do in order to change passwords.

You can’t use windows authentication for any domains other than the one that the server is in, even if one way trusts are correctly configured – you really need to use LDAP server sets.  Thats not a problem if all of your internal users will access your secure extranet from the internal domain – you could bypass your ISA server and go straight to the web server.  However, people will want to give demonstrations, and work on the extranets from outside the office – its up to your policy to determine if this will affect the configuration.  Existing SSL VPN solutions might be a better option for your own employees.

Publishing SharePoint via ISA Server is fairly straightforward, even if you use SSL to the reverse proxy, and connect on port 80 to the SharePoint server in order to move the encryption load from your SharePoint box.

However, for some reason, this appears to break Telerik’s RadEditor.  In order to use RadEditor, you need to be able to connect directly to the server in the same format of the initial request, which means in the case of a secured SharePoint site, SSL.   Simply change the bridging rule to redirect requests to the SSL port, and disable redirection to the HTTP port.  This will place more load on your SharePoint servers – every request is encrypted via SSL between the SharePoint server and the proxy – weigh this load up against the editing benefits of RadEditor.