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.
Recent Comments