I’ve seen a lot of questions lately regarding the password change feature not working properly on the ISA Firewall, most often related to OWA publishing scenarios. I have to admit that I’m partly responsible for this problem. Why? Because I thought that you could enable password changes when the ISA Firewall was a domain member. I know that we were able to do this in previous versions of the ISA Firewall, although we did have to go through a lot of hoops to make it work.
It’s a lot easier to enable password changes on the 2006 ISA Firewall. However, in order to make it work, you have to do more than just make the machine a domain member. In fact, the ISA Firewall doesn’t have to be a domain member in order to make this work. What you do need to do in order to make the password change feature work is to enable LDAP authentication on the ISA Firewall.
This doesn’t mean that the ISA Firewall shouldn’t be a domain member. You can make the ISA Firewall a domain member and use LDAP authentication for your Web Publishing Rules that you want to enable the password change functionality on. That’s what I do in practice: make the ISA Firewall a domain member and then configure the ISA Firewall to support LDAP authentication for password change functionality.
This entire issue came to fore for me when I read a blog post on the ISA Firewall Team Blog. The most important quote here is:
“You must use an LDAPS connection to the LDAP server/dc”
Well, there you go – you can’t get more clear than that!
NOTE:
Well, I thought you couldn’t get more clear than that. Jason Jones informs me that the ISA Firewall doesn’t need to be configured to use an LDAP server if the ISA Firewall is a domain member and the DCs have server certificates installed. This makes sense, as a domain member can use LDAPS when the DC has a server certificate installed. I misinterpreted the ISA Firewall Team blog comment as saying that you needed to use LDAP server authentication. That was incorrect — you just need to enable LDAPS, which can be done by configuring the ISA Firewall to use an LDAP server or by making the ISA Firewall a domain member and configuring the DCs with server certificates. Thanks to Jason Jones for the info! That said, the rest of the article will still be interesting to you as it provides information on how to configure the ISA Firewall to use an LDAP server for pre-authentication. Thanks! –Tom
In this article I’ll show you how to configure the ISA Firewall to support LDAP authentication so that your users will be able to change their passwords.
Configuring the ISA Firewall to Support LDAP Authentication
In order to use LDAP authentication, you need to configure the ISA Firewall with the names of the LDAP servers you want to use to pre-authenticate the incoming connections. There are two procedures involved in setting up LDAP Servers for the ISA Firewall to use for pre-authentication:
- Define sets of LDAP servers that the ISA Firewall can query to authenticate user credentials
- Define login expressions that the ISA Firewall can use to determine how to route the LDAP query. The login expressions determine what LDAP server is responsible for a particular authentication request.
To set up the LDAP servers, open the ISA Firewall console and expand the Arrays node (if you’re using ISA Enterprise Edition) and then expand the array name. Expand the Configuration node and click the General node. In the middle pane, click the Specify RADIUS and LDAP Servers link.
Figure 1
Click the LDAP Servers tab in the Authentication Servers dialog box. Click the Add button next to the list of LDAP Server Sets.
In the Add LDAP Server Set dialog box, enter a name for the LDAP Server set. In this example we’ll create an LDAP Server Set for the msfirewall.org domain, so we’ll put MSFIREWALL in the LDAP server set name text box.
Click the Add button in the Add LDAP Server Set dialog box. In the Add LDAP Server dialog box, enter the FQDN of the msfirewall.org domain controller. In this example, the name of the DC for the msfirewall.org domain controller is exchange2003be.msfirewall.org, so we enter that into the Server name text box. The Server description field is optional, and you can leave the Time-out (seconds) value as it is, unless you have networking issues that might require that you increase this value.
Figure 2
Click OK in the Add LDAP Server dialog box.
Notice that we entered an FQDN for the server name. We need to do this because we will use LDAPS certificate authentication when the ISA Firewall communicates with the domain controller. If you had entered an IP address in the Server name text box, the LDAPS authentication would fail because the value in the Server name text box must match the common/subject name on the server certificate installed on the DC. Since we installed an enterprise CA on the DC, a self-signed machine certificate was automatically generated on each of the domain controllers. If we had not installed an enterprise CA on the DC, we would need to create the machine certificates manually.
Note:
Pay very close attention to the last sentence in the last paragraph. It’s important that it not to be taken lightly. The assignment of a server certificate for the DCs in the enterprise CA scenario is very easy because we installed an enterprise CA on the DC. If you have not installed an enterprise CA on all your DCs, then you must install a machine certificate on each of the DCs. The best way to do this is to install an enterprise CA somewhere in your environment and then configure Group Policy for machine certificate autoenrollment. Detailed instructions on autoenrollment are beyond the scope of this article. For excellent coverage of how to configure autoenrollment (and all other certificate deployment scenarios) please see the ISA Server 2000 VPN Deployment Kit.
In the Type the Active Directory domain name (use the fully-qualified domain name) text box, enter the FQDN of the Active Directory domain name used by the LDAP Server set. In this example, we’re creating a set for the msfirewall.org domain, so we enter that value into the text box.
Figure 3
In order to support user password changes using LDAP pre-authentication at the ISA Firewall, we must enable LDAPS support. In order for LDAPS to work, you must install a machine certificate on the Domain controllers with the correct common/subject name on the certificates. The easiest way to do this is to use an enterprise CA and enable autoenrollment via Group Policy, as mentioned in the note above.
The ISA Firewall needs the CA certificate of the issuing CA installed in it’s own Trusted Root Certification Authorities machine certificate store (not the user or service store), so that it will trust the certificates installed on the DCs. We have already installed the CA certificates on the ISA Firewall when we installed the Web site certificates into the ISA Firewall’s machine certificate store. In addition, if the ISA Firewall is a domain member and you’re using an enterprise CA in your environment, the ISA Firewall will automatically install the root CA certificate in its Trusted Root Certificate Authorities machine certificate store.
When LDAPS authentication is enabled, the Use Global Catalog option must be disabled, and you must enter the FQDN of the Active Directory domain name in the Type the Active Directory domain name (use the fully-qualified domain name) text box. If you don’t want to enable password management, then you could check the Use Global Catalog (GC) option and leave the Active Directory domain name blank.
Since we do want to support password changes for remote users, we must also provide user credentials that can be used to access the Active Directory to verify user account status and change account passwords. This can be any user in the Active Directory, and it does not require domain admin credentials. Enter the user name in the User name text box and the Password in the password text box. In this example we’ll use the domain name user account, as seen in the figure above.
Note:
You do not need to use a domain admin account. You can use a regular user account to connect to the Active Directory. I am using the Active Directory domain admin account in this example because I’m too lazy to create a new user.
Click OK in the Add LDAP Server Set dialog box to complete the configuration of the msfirewall.org LDAP Server set.
Now suppose you want to enable LDAP authentication for another domain. This would be useful if you have multiple domains without trusts between them but still want the ISA Firewall to provide pre-authentication and password change ability. We can do this by creating a second LDAP server set.
Let’s create a second LDAP Server Set for the example domain, pixkiller.net. Create the second server set using the information provided in the figure below.
Figure 4
Warning:
If you create a second LDAP server set, make sure you have server certificates installed on the DCs for that domain and that the ISA Firewall has the root CA certificate for that domain in its Trusted Root Certification Authorities machine certificate store. In the case of the second domain where the ISA Firewall isn’t a member of that domain, you will need to manually install the root CA certificates onto the ISA Firewall – autoenrollment for the root CA certificate only works for the domain that the ISA Firewall belongs to.
We have completed the first step, which was to create the LDAP Server Sets. The second step is to create rules that the ISA Firewall can use to forward the authentication requests to the correct authentication server. These rules are based on elements of the users’ log on strings.
For example, users could log into the two OWA sites using log on strings such as:
MSFIREWALL\user
PIXKILLER\user
Based on this information, we can create rules based on wildcards and elements of these authentication strings so that the ISA Firewall forwards the authentication attempt to the correct domain controller. For example:
*@msfirewall.org
MSFIREWALL\*
Authentication attempts containing these strings would be forwarded to the MSFIREWALL LDAP Server Set. Another example:
*@pixkiller.net
PIXKILLTER\*
Authentication attempts containing these strings would be forwarded to the PIXKILLER LDAP Server Set.
To create these rules, click the New button that sits to the right of the Define the login expressions ISA Server will use to match the user login strings list. In the New LDAP Server Mapping dialog box, enter the logon expression MSFIREWALL\* in the Login expression text box. In the LDAP server set drop down list box, select the MSFIREWALL entry. Click OK.
Figure 5
Click New again and create a second LDAP Server mapping. This time, make the Login expression as *@msfirewall.org and select the MSFIREWALL entry from the LDAP server set drop down list.
Figure 6
Click New again to create a third LDAP Server mapping. This time, enter PIXKILLER\* in the Login expression text box and select the PIXKILLER entry from the LDAP server set drop down list box. Click OK.
Figure 7
Click New to create the last LDAP Server mapping. Enter *@pixkiller.net in the Login expression text box. Select PIXKILLER from the LDAP server set drop down list box. Click OK.
Figure 8
The figure below shows the list of login expressions. Notice that you can use the up and down arrows to change the order of the rules (although at the time of this writing, I can’t think of a scenario where placement in the list would be an issue). Click Apply and then click OK. Click Apply to save the changes and update the firewall policy and click OK in the Apply New Configuration dialog box.
Figure 9
At this point you can create Web Publishing Rules that use LDAP user groups and users will be able to change their passwords in the form provided by the ISA Firewall.
If things aren’t working for you, consider the following for troubleshooting:
- Failure because no certificate is installed.
You require a server certificate whether you are using LDAPS or Windows authentication. - Client logon is slow when running the ISA Firewall on a computer with Windows Server 2003 SP2 or the Scalable Networking Pack installed.
Take a look at KB 555958 for a solution. - Client logon is slow when server certificates are configured with default purpose settings of “Server Authentication” and “Client Authentication”.
When Windows Server 2003 detects the default purpose setting of “Client Authentication” on a certificate, it attempts to perform TLS with mutual authentication. The mutual authentication process requires ISA Server to have access to the private key of the certificate, and ISA Server does not have (and should not have) this access. To solve this issue, remove the “Client Authentication” purpose setting from the certificate properties. - Users authenticating against an LDAP server receive an Error page 500 message.
Users may be entering credentials for which a logon expression does not exist. Users must either log on using the format domain\name, or you must create a logon expression to handle the user logon format. Add one or more logon expressions to the LDAP server set. For example, when you create a logon expression *@contoso.com, a user entering credentials in the format [email protected] will log on successfully. - Password change error.
The default domain policy may have a value of 1 or greater set for the minimum password age. If you want users to be able to change password more than once a day, set the minimum password age to 0. This is an important consideration when testing the password functionality in the lab. I ran into this a number of times until I figured out that it was a group policy issue. - After changing the password, users are still able to authenticate using their old password.
Active Directory allows both the old password and the new one to be used for one hour, to allow for replication. To confirm that this is not an ISA Server issue, log off and then log on again using the old password. For information about a registry key to customize the time, see KB 906305. This is a very interesting fact and not something that I was aware of when testing my password change configurations in the lab!
Summary
In this article we looked at the issue of enabling password changes in Web Publishing Rules on the ISA Firewall. We saw that LDAP authentication is required and then went on to show the details of how the ISA Firewall is configured to support LDAP authentication. One critical issue that you must keep in mind is that you must use LDAPS to support password changes. That means all of your LDAPS servers (all of your domain controllers) must have server certificates installed on them and the root CA certificate of each of the issuing CAs must be installed into the ISA Firewall’s Trusted Root Certification Authorities machine certificate store. Pay close attention to the names on the certificates. Make sure the ISA Firewall can resolve these names. We finished up with a troubleshooting section that contained some very helpful tips courtesy of the ISA Firewall Team.
