In my previous article I explained the use of one-time passwords with Forefront Threat Management Gateway (TMG). Today, I will discuss an alternative to this method that leverages smart cards and Public Key Infrastructure (PKI). I will describe how to use certificates that are published on the TMG.

For this to work, you don’t’ have to deploy an Enterprise Certification Authority. You can use any certificate issued by a public or private CA. Two things are required for this:

1. The CA that issued the user certificate has to be added to the Certificate trust list (CTL) on the TMG Listener
2. The user certificate has to be mapped to the user’s Active Directory credentials

First, locate the Listener from our previous articles.

TMG Web Listener

Next, click the Toolbox tab, and then Network Objects.

Now, right click on the listener that you created before and select the “Authentication” tab.

SSL Client Certificate Authentication

Select “SSL Client Certificate Authentication” from the dropdown menu. You can only choose “Windows Active Directory” to validate the credentials.

Click on “Advanced”, and then select the Client Certificate Trust list. You have two options here:

SSL Client Certificate Authentication – Advanced Authentication Options

You can either allow certificates from all issuers that are trusted on the TMG, or select only specific trusted certificates. I suggest accepting certificates only from those CAs that your users will actually use. If you want to accept certificates from a public CA that is not in the Trust List, you must also add the CA Root certificate to the TMG.

You can map a certificate to a user account using Active Directory, but first you need the user’s exported public key. Open Active Directory Users and Computers, select “View” and click on “Advanced Features”.

SSL Client Certificate Authentication – Active Directory Advanced Features

Now, navigate to the user account, right click the user name and select “Name Mappings”,

SSL Client Certificate Authentication – Name Mappings

Click “Add” and point to the CER file that contains the user’s public key. This user can now be authenticated on the TMG Listener.

SSL Client Certificate Authentication – Security Identity Mapping

Do not confuse this method with smart card authentication on workstations; you will still require specific certificates for smart card logins. I strongly recommend that you allow only user certificates that are stored on smart cards. As far as I know, this can’t be enforced on the TMG.

When a user accesses Outlook Web Access (OWA), he will be asked to provide a certificate and a smart card PIN. Once he authenticated successfully to the TMG, he will be automatically logged on to OWA.

• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)
• FREE: GFI WebMonitor – Web filtering for ISA Server (3)

In the previous article of this Kerberos Delegation series, you learned how to configure Kerberos Constrained Delegation. Today, I will discuss pre-authentication methods that are not based on Active Directory. Users can pre-authenticate using Windows Active Directory authentication, RADIUS OTP authentication, Certificate authentication or LDAP authentication, and even with PKI certificates.

In the example here, we will use a one-time password solution that provides a simple, user friendly and very secure solution that is ideal for securing access to corporate resources when used with Microsoft (TMG) and Kerberos Constrained Delegation. I will describe how Protocol Transition works with TMG, i.e. how you can authenticate users with one method and then pass the credentials to the backend using Kerberos.

So how is the end-user experience when multiple pre-authentication methods are used without Credential Delegation? If you were to use RADIUS One-Time Password pre-authentication on the TMG Listener, a user would have to enter his OTP credentials first and then provide his Windows credentials for access to the web server.

Why is this not good? You expose critical security information (Domain username and password, which are static) when a user has to enter Domain credentials on a machine that doesn’t belong to your corporate network. This is especially problematic in a “hostile” environment such as internet cafes or the “mother-in-law” computer (I heard this term at a Microsoft presentation for UAG and I just had to use it). You can probably imagine the variety of threats in those environments. Such a machine could run key logging malware that collects static passwords and other information that could be used in a subsequent attack.

How can a security minded administrator make sure that users would enter only OTP credentials when accessing backend HTTP/HTTPS based services? It’s obvious that you can’t achieve this by using Basic Credential Delegation which means passing username and password from the TMG server to the backend server. For working with OTP credentials, Kerberos Constrained Delegation and Protocol Transition is required.

In my previous article, I already explained how to configure Kerberos Constrained Delegation in a Publishing rule. In this post, I will describe how to configure the Listener to use OTP and PKI pre-authentication. But first we have to configure TMG to query an authentication server. We will do this by defining a RADIUS server with TMG. First select “Tasks” in the TMG console.

TMG – Configure Authentication

Locate “Configure Authentication Server settings”

A new window will pop up, click “add” and enter the relevant information (IP, Shared Secret And Port). Also be aware, that if your RADIUS server uses a port other than 1812, you will have to allow it independently.

TMG – Authentication Servers

I continue by reconfiguring the Listener on the TMG from the previous article. Select “Toolbox” and then click on “Network Objects” in the TMG Console.

TMG – Web Listeners

Locate and open the “Web Listener” dialog at the bottom and right click the Listener that you created in the previous article.

Authentication Validation Method

Now select “RADIUS OTP” authentication in the Authentication settings tab. You can then use this Listener in a Publishing Rule. The Publishing Rule from the previous article can be used without reconfiguration. Click OK and Apply.

How would an end user experience this? When a user first accesses the URL of the published web application, he will be asked to enter his OTP credentials. The TMG would then authenticate him to the backend application using a Kerberos Token by delegating the credentials. The user has successfully logged in using only his OTP credentials without being asked to enter his domain credentials. In the next article, I will explain how to use Smart Cards and PKI credentials to access published resources.

• How to configure TMG for SSL Client Certificate Authentication (0)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)
• FREE: GFI WebMonitor – Web filtering for ISA Server (3)

As Alex already explained in a previous article, TMG secures backend servers as a proxy by reducing the attack surface. Primarily it reduces the number of ports that are accessible from the Internet and it allows only authenticated traffic to access backend servers running Outlook Web Access, Sharepoint and other Web Servers and applications.

Kerberos Constrained Delegation vs. Basic Delegation

TMG contains a mechanism that is called credential delegation, the simplest one being Basic delegation. Basic authentication is enabled on the TMG listener and the credentials that the user provides are simply forwarded to the published backend server, which also has to use Basic Authentication. If the Backend server is configured with Integrated Authentication, it will not work. Basic Delegation is simple and effective.

The alternative to Basic Delegation is Kerberos Constrained Delegation, where the TMG server impersonates the user account to the backend server with a Kerberos Token. Kerberos is a token based authentication protocol which is used by default for authentication in Windows networks since Windows 2000. It improves security significantly because it reduces that passwords are intercepted.

Requirements for Kerberos Constrained Delegation

• For Kerberos Constrained Delegation to work with Forefront TMG you will need the following:
• Windows Server 2003 domain controllers or higher
• Domain set to Windows 2003 functional level
• The backend Web application (OWA) must use Windows Integrated authentication and not Forms based or Basic authentication
• The TMG, ISA2006 or ISA2004 SP2 Server must be allowed to delegate to the backend application server within Active Directory where both machines have to be domain members

Active Directory configuration

1. Open Active Directory Users and Computers and find the TMG server object:
2. Right click the TMG object and select “Properties” from the dropdown menu
3. Click on the “Delegation” tab
4. Click on the Radio Button next to “Allow this computer to delegate to specified services only” and select “Use Any Authentication protocol”
5. Click on “Add” and find the Server that is running the published application, which is a server named “Exchange” in our case
6. Select the appropriate SPN or Service Principal Name. You should use http://exchange.domain.local. This applies only if the service on the backend server runs under Network Service, Local System or Local Service accounts
7. Click OK

Now remember, if your application runs under a different domain account, i.e. if you are publishing a web farm, a NLB site or the application pool Identity is different, you should first check whether the account already has an assigned SPN. The easiest way to do this, is by using the setspn tool. Launch the command prompt and type:

Setspn –L domain\account

This will return a list of all SPNs for this account. If the account does not have a SPN, you can add it, but you have to be careful because you will encounter problems if you add a SPN that is already assigned to a different username or machine as an account can have multiple SPNs, but a SPN can only be assigned to a single account. In the following example we will add the http/webfarm.domain.local SPN to the domain service account. You can do this this with the following command:

Setspn –A http/webfarm.domain.local domain\accountname

When you add a new SPN to a domain service account (domain\accountname) you then have to allow TMG to delegate credentials to that account. You have to go back to steps 5-7 in the previous paragraph to first search for the account and select the target SPN that you created (http/webfarm.domain.local).

Forefront TMG configuration

To create a listener and a publishing rule on the TMG you can follow Alex’s procedures. With one exception: At the Credential delegation tab on the Publishing rule where he selected “Basic Delegation” you have to select “Kerberos Constrained Delegation” in the publishing rule, and at the bottom you have to enter the SPN from the previous steps (http/exchange.domain.local or http/webfarm.domain.local). You must also make sure that the backend website is using Integrated Authentication. Right Click on the publishing rule and select “properties” and then click the “Authentication Delegation” tab.

When you access the TMG protected page of Outlook Web Access, the user experience will be the same as before with Basic Delegation. However, in the background a Kerberos token will be passed from the TMG to the backend server instead of username and password. An authentication event in the security event log would look like the one below on your backend server.

In the Transited Services section you should see the FQDN of your TMG server.

In the next article I will show you how to use KCD with Two-factor Authentication, which will demonstrate the flexibility of this mechanism.

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)
• FREE: GFI WebMonitor – Web filtering for ISA Server (3)

In my last post I introduced Forefront TMG’s functionality to secure Exchange 2010. Today, I will show you how to configure Exchange and Forefront to work together.

Install the SSL-Certificate

1. Open the „Exchange Management Console“ and export under „Server Configuration – > Exchange Certificate“ the Exchange certificate by right clicking „Export Exchange certificate“.
2. Name the certificate, enter a password and save it as a *.pfx file.
3. Copy the file to your Forefront TMG server.
4. Open a „Microsoft Management Console“ on the Forefront TMG Server by typing “mmc” in the Command Shell.
5. Add the Certificate Snap-in by „File -> Add/Remove Snap-In“ and choose the “local Computer” in the „Computer account“ dialog.
6. Open the certificate-tree (Local Computer) and select „Personal“.
7. Right click on the „Personal“-folder and select „All Tasks -> Import…“
8. Import the *.pfx file. You have to choose *.pfx as the file-type instead of the default *.cer. In the next dialogs keep the default settings.

Create a Web Listener

1. Open the „Forefront TMG Management Console“. On the right column choose the tab „Toolbox -> Network Objects“. Create a „Weblistener“ by using the “New” option.
2. Now you have to name the Listener. In the next dialog keep the default setting https.
3. Allocate the external network to the Web Listener. If you want to use preauthentication for your internal network, too, you have to add the internal network.
4. In the dialog „Listener SSL Certificates“ choose the certificate you copied to the Forefront Server in the previous step.
5. Under „Authentication Settings“ choose „HTML Form Authentication“. By this choice you make sure that web-based Authentication is used for OWA and that the „Basic Authentication“ is used for Outlook Anywhere and Exchange ActiveSync. To force the user to authenticate click the „Advanced“-Button and select the option „Require all users to authenticate“.
6. If you want to use „Single Sign On“, provide the address .contoso.com.
7. Close the dialog by clicking on „Next“ and „Finish“.

Create a Web Farm

1. Create a new „Server Farm“ in the Forefront TMG Management Console. You can do this by choosing „Network Objects“ in the right column and open the menu „New“.
2. Name the Server Farm „Exchange Client Access Server“ and add your Client Access Server on the next page.
3. To configure the „Server Farm Connectivity Monitoring“ properly you must change the entry under „Send an HTTP/HTTPS GET request“ to „HTTPS://*/OWA/“.

The Exchange „Publishing Rule“

1. In the Forefront TMG Management Console open the context menu of the „Firewall Policy“. You can find the node „Firewall Policy“ in the left column. Create a new access rule by choosing „New->Exchange Web Client Access Publishing Rule“.
2. Name the rule „Exchange Outlook Web App“.
3. On the first page of the dialog select the Exchange version „Exchange 2010“. Choose „Outlook Web Access“ as the corresponding protocol.
4. In the next dialog choose „Publish a server farm of load balanced Web servers“. You should select this option even if you have currently only one Client Access Server, because you can easily add another server to the rule later on.
5. On the next page choose SSL.
6. Under „Internal Publishing Details“ enter the URL mail.contoso.com.
7. In the next step choose the Server Farm you created before.
8. In the selection list „Accept requests for“ you should keep the option „This domain name (type below)“. The „Public name“ is mail.contoso.com.
9. In the next dialog choose the Web Listener you created before.
10. As the authentication method select „Basic authentication“. Make sure that the Client Access Server is supporting this authentication method. Otherwise you have to change the configuration of your Client Access Server.
11. On the last page you can give access rights to specific users. If everybody should be able to use OWA keep the option „All Authenticated Users“. Never use the option „All Users“ because the users won’t see an authentication dialog then and therefore can’t connect.
12. Close the wizard.

For now only OWA has been configured for secure access. If you want to secure Exchange ActiveSync and Outlook Anywhere you have to create “Publishing Rules” for them, too. You can do this by following the steps as listed above. The only difference is in step three. There you have to choose the corresponding service.

To use Autodiscover you have to add the Autodiscover URL to the Outlook Anywhere Publishing Rule.

1. Open the „Properties“ dialogue of the rule.
2. Under the tab „Public Name“ add via „New“ the Autodiscover URL (e.g. autodiscover.contoso.com).

Last but not least you have to change your DNS entries. They have to point to the external IP address of Forefront TMG. Be careful when changing them, though. If the FQDN of your MX-entry is the same as the FQDN of the Client Access Server you have to create a new MX-entry and A-record. Otherwise the SMTP-requests are directed to the external IP of the Forefront TMG and not to your Exchange Server.

When you access OWA now you should see the following screen:

On the first glance it looks similar to before, but perhaps you have noticed the line “Secured by Forefront Threat Management Gateway” already. After you tested everything thoroughly you should delete the old firewall rules. Now it’s time to lean back and relax, because you have severely increased the security of your Exchange installation.

• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)
• eDiscovery in Exchange – Part 5: Export and search (0)

An essential part of an Exchange 2010 deployment is the availability of e-mail everywhere at any time. For your users, this feature eases work; for you as an administrator, it means more work, because you have to secure the Exchange Server against attacks from outside your corporate network.

I often see that Exchange 2010 is published directly to the internet by allowing access to the various ports from the internet. However, this approach undermines most of the security features of Forefront TMG. Forefront supports Preauthentication, which means the users do not authenticate with the Exchange Server but with Forefront. Forefront then passes the privileges to the Exchange Server.

This improves security in various ways; one of them is that you do not have to publish Exchange to the internet. Another security feature of Forefront is that it can act as a web proxy. Here the protection mechanism is the same as with Preauthentication. From the Internet, nobody sees your Exchange Server. It is completely hidden behind the firewall.

Forefront also supports web filters and e-mail filters. When the access to Exchange is secured by SSL, which is absolutely needed to have at least some basic protection, and only passed through the firewall to Exchange, these filters cannot work because all they see is the encrypted stream of bytes. Forefront can bridge SSL. This means that the users still use SSL to access their e-mail, but Forefront TMG can inspect the network traffic.

When SSL is bridged, the user establishes a SSL connection with Forefront TMG and Forefront TMG establishes a SSL connection with Exchange. Thus, the tunnel is interrupted and Forefront can inspect the traffic. However, even though the SSL tunnel does not directly connect the user with Exchange, all network traffic is still secured by SSL.

Before I write about the actual configuration steps, I want to provide you with a picture of the network topology and list the prerequisites of this guide. The network topology is pretty simple in my case, but it can be even simpler. The Exchange 2010 Client Access Server and the Mailbox Server can reside on the same server. There is no need for them to be installed on separate machines.

Prerequisites for securing Exchange 2010 with Forefront TMG

1. A working Exchange 2010 and Forefront TMG installation.
2. You have to have Split-DNS configured, which means you use the same domain name for your internal and external network. I use the name contoso.com.
3. Outlook Web APP (OWA), Outlook Anywhere, and Exchange ActiveSync use the FQDN mail.contoso.com.
4. You need a valid certificate. mail.contoso.com must be the certificates principal and autodiscover.contoso.com has to be listed under “Subject Alternative Name”.

If you can fulfill these prerequisites, you can follow the step-by-step guide to secure your Exchange 2010 Server in my next article.

• Troubleshooting Exchange eDiscovery: Errors due to lack of Full Access permission (0)
• Troubleshoot Exchange eDiscovery: This mailbox exceeded the maximum number of corrupted items (0)
• Exchange ActiveSync Mailbox Policies and Exchange Remote Wipe (1)
• How to change the allowable message size in Exchange 2010 (0)
• eDiscovery in Exchange – Part 5: Export and search (0)

GFI WebMonitor Freeware

• Poll: Are you currently using a monitoring solution? (11)
• SCOM 2012 review – Part 8: Dashboards (0)
• SCOM 2012 review – Part 7: Linux and JEE monitoring (4)
• Notifications and Custom Commands in Nagwin/Nrpe (0)
• SCOM 2012 review – Part 6: Application Performance Monitoring (APM) (1)

You probably know that Windows distinguishes between Public, Home, and Work networks. Whenever you connect to a new network, Windows will ask what type of network it is. Each network has its own firewall profile, which allows you to configure different firewall rules depending on the security requirements of the user’s locations. You can use the Windows Firewall with Advanced Security’s snap-in filter to display only rules for specific locations. The corresponding firewall rule sets are Public (Public), Private (Home / Work), and Domain (when a domain-joined workstation detects  a domain controller) (see comment below).

This works fine as long as you are only connected to one network at a time. As a matter of fact, more and more users now have their own networks at home. The problem is that once they connect to the corpnet, the Domain firewall rule set becomes active, which will break homegroup connections. The solution to this problem seems to be to work with multiple NICs. However, in Windows Vista, only one profile can be active on the computer at a time. Windows Sever 2008 machines that are connected to multiple networks suffer the same problem. In this case, the profile with the most restrictive settings is applied to all adapters on the computer.

Windows 7′s multiple active firewall profiles are the solution to this problem. It is now possible to assign each firewall profile to specific NICs. You can configure this feature in the Windows Firewall properties (right click on the root folder Windows Firewall with Advanced Security snap-in). This allows you to work with a different firewall profile for each network interface. If the computer is connected to multiple networks at a time, Windows Firewall will use the different rule sets for each NIC.

Note that this feature can’t be configured via Group Policy. At least the Group Policy settings of Windows Server 2008 R2 Beta don’t offer a corresponding option. The problem is that you can’t know in advance, for all external computers, which NIC is connected to the home network and which to the domain network. I guess that’s why you will have to configure this manually for each computer.

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

• Bill Gates signals end of the computer mouse and the keyboard. Of course this means that we need fatter desktops. http://snurl.com/2brbe #
• ISA Server 2006 SP1 Features: Configuration Change Tracking, Web Publishing Rule Test Button, Traffic Simulator… http://snurl.com/2atkv #
• Interesting video interview with Mary Joe Foley and Ed Bott about Windows 7 http://snurl.com/2awhu #
• It seems there is a growing demand for IT admins in Germany. I wonder when Nicholas Carr’s prediction will come true. http://snurl.com/2awjf #
• I didn’t see this multi touch demo before. Hopefully, this feature really makes it into the Windows 7. http://snurl.com/2br9j #

Thank goodness, it was only a backup system. Meanwhile there is a solution for this problem. However, this incident also significantly increased my respect for this Service Pack. Especially this new “lazy Interrupt Request Level (IRQL) handler” seems to have some bad influence on otherwise diligent servers. Hence, we won’t be too hasty to deploy it to our servers. We will wait for some weeks to see what other bugs it contains.

If you deploy service packs with WSUS, you don’t have to worry that it will be installed on your servers without approval. You have to explicitly accept the SP2 Eula. You can make sure that the service pack is not accidently installed by using the SP2 blocker tool to “temporarily block delivery of Windows Server 2003 Service Pack 2“.

If you want to deploy it anyway, check out the Windows Server 2003 Service Pack 2 application compatibility list first. I am not sure, though, how much you can trust this list. ISA 2004 was tested, too! It seems they didn’t test it on multiprocessors systems. Maybe they thought that this “lazy handler” wouldn’t affect the more vigorous servers, anyway.

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

Improved log viewer: There is a new pane showing detailed information about each log entry. I always found it quite complicated to scroll to the left to view more details of an entry. Now, you just have to click on it to access all important information with one look.

Different colors for log entries: You can now specify the colors of log entries depending on their type. For instance, in the default color scheme, red means denied connections while green means allowed connections. If you have to analyze log files often, this is probably a must-have feature for you.

Save protocol filters: I really wonder why Microsoft introduced this feature only now. Filters are essential if you have to analyze log files and usually you need similar filters. The feature alone is worth installing the update. There are also some new filtering options: “Not One Of” and “One of”.

Diagnostic logging: You can now log connections in the Windows Eventlog made to or thru ISA. Tom Shinder writes “you can actually get real insight into how the ISA Firewall evaluates each rule and component of the connection”. Sounds quite interesting, too. He dedicated an article to this feature.

Integration with ISA Firewall BPA: The ISA Firewall Best Practices Analyzer is separate tool you can download from Microsoft. It gives you a detailed report about your ISA configuration, helping you find common configuration errors.

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

First of all, you might ask, why a server needs a personal firewall, if all your servers are behind a gateway firewall, anyway. It seems superfluous to have another firewall running on the servers.

It is interesting to note that the firewall in Windows Server 2008 is activated by default. Only an upgraded Windows Server 2003 will maintain its operational state. It seems that Microsoft’s software engineers are thinking that Windows Firewall brings some extra security on servers, too.

I fully agree! Think of it as another line of defense. The more barriers you have, the more secure your network is. This corresponds to the general trend to enforce security inside the perimeter network. Please, check out a former discussion on 4sysops about the pro and contra for personal firewalls.

A disadvantage certainly is when one of your applications fails to work due to an incorrectly configured Windows firewall. However, this applies to all security measures. They make your network more complicated, therefore, more prone to errors.

Windows Server 2008 firewall has a nice feature which alleviates this problem. Whenever you add a new role to your server, the firewall is automatically configured, accordingly. For instance, if you configure your Windows server as a domain controller, the corresponding ports are opened automatically.

If you run third party applications on your servers, you have to configure the firewall yourself. For this, you have to use the “Windows Firewall with Advanced Security MMC snap-in“. You can launch it by typing “firewall” on the Start search prompt. You’ll also see the “simple” Windows Firewall tool from the Control Panel. This tool can only be used to disable the firewall and to enable exceptions for Windows programs.

It is also possible to remotely manage the firewall settings using the MMC snap-in on a Vista machine. But if you try to connect remotely to change the firewall settings, you’ll get the message “The Windows Firewall with advanced Security snap-in failed to load. Restart the Windows Firewall service on the computer that you are managing. Error code: 0X6D9“. Well, restarting the firewall service won’t help. What you really have to do is enable remote management:

Open a command prompt with admin privileges and enter: netsh advfirewall set allprofiles settings remotemanagement enable. This should also work on a Server Core system. It allows you to manage the firewall settings with much more comfort than on the command shell.

Like in Vista, the Windows Server 2008 firewall offers three different profiles: Domain, Private and Public. If a computer is a domain member, the location type is set automatically to Domain. It is not possible to change this setting. Only the firewall rules for the Domain profile apply then. If a computer is not in any domain, you can choose between the Private and the Public location types. You can change the location type in the Network and Sharing Center if you click on “Customize” beside the network connection.

The default setting for a Windows 2008 domain controller is “Public” and domain members can only use the Domain location type. Thus, on the domain controller, you will usually configure Public rules for third party applications and on domain members you will work with Domain rules. The difference between Private and Public doesn’t matter for servers in my view. I doubt that you will grab one of your servers and connect it at Starbucks to download some patches during your coffee break. You’ll find more information about the differences between the location types in the help file of Windows Firewall.

To disable or change other general settings of the firewall for a certain profile, you have to right click on “Windows Firewall with Advanced Security on Local Computer” and then choose “Properties”. Of course, you also can use Group Policy to configure Windows Firewall.

Like Vista, Windows Server 2008 also supports outbound filtering. By default, outbound connections are allowed, though. It probably is too much hassle to configure outbound filtering manually on server systems. Another change compared to the firewall in Windows Server 2003 SP1 is that IPsec rules can now be configured with the same snap-in. This certainly makes sense because it reduces the risk of conflicting settings.

• Microsoft Exam 70-640 – DNS Zones – Overview (2)
• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)

The argument against the use of personal firewalls is that malware can disable the personal firewall or leverage another program to access the internet. Malware often uses the Internet Explorer to phone home since it is usually allowed to access the internet.

In my view, both arguments are wrong with regards to standard users in the case of Vista’s desktop firewall. The first argument can easily be refuted. If users don’t have administrator privileges on their desktops (which I strongly recommend), then the malware will simply not have enough rights to disable Windows Firewall or to change its setting.

However, if you logged on as admin, it is indeed possible for malware to change the settings. The strange thing is that in my test this could be done without getting User Account Control (UAC) involved. I configured the Windows Firewall with the Local Security Policy tool (just enter the name on the Program Search Prompt). When I start this tool, I didn’t get an UAC prompt. I tried the same on another machine which belongs to a Windows domain and there I got an UAC pop-up.

Anyway, if you logged on as an Administrator and the malware is smart enough to change the firewall settings before connecting to the internet, then it could indeed be possible that Windows Firewall is useless in this case.

To investigate the second argument, which assumes that malware always can use another program to access the internet, I installed the IE Tab add-on for Firefox. This plug-in allows you to use Internet Explorer to load web pages within Firefox.

First, I changed the policy for outbound filtering for the Windows Firewall. You can do this by right clicking on “Windows Firewall” in the Local Security Policy tool (or Group Policy Editor) There, you can set outbound filtering to “block” for the different profiles (domain, private, public). Then, I added an outbound rule allowing IE to access the internet.

I was able to load web pages when I started IE, but internet access was blocked when I started IE within Firefox. This doesn’t prove that IE can’t be leveraged by malware to access the internet, but it shows, at least, that it wont be easy.

Next, I wanted to know if it is possible to trick Windows Firewall by exchanging exe files. In my test, I allowed Firefox to access the internet, then exchanged firefox.exe with putty.exe. I was indeed able to establish an internet connection with putty afterwards. Well, this is really disappointing. Most personal firewalls use hash codes to identify applications. Windows Firewall only uses file name and path.

Now, you might argue, what is the use of outbound filtering if it can be outsmarted so easily. The point is, standard users are not allowed to make any changes with the Program Files folder. So if a user starts a malware program, it won’t be able to use this trick. I, therefore, conclude that outbound filtering with Windows Firewalls makes sense for standard users, but not for administrators.

• FREE: Microsoft Standalone System Sweeper – Standalone antivirus software (0)
• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• FREE: Kaspersky Rescue Disk – Offline antivirus tool (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

iptables is a tool for packet filtering and NAT. You can use it to setup a firewall with shell scripts. A shell script with just a few lines is enough to block an IP address attempting to establish too many connection within a certain time frame.

PAM (Pluggable Authentication Modules) is an API used by many Unix systems for authentication. Marius described how to use PAM to block the IP address of an attacker after three failed logon attempts on a ssh server.

fail2ban can be used to update firewall rules based on log files scans. Marius demonstrated how to secure an ssh server with fail2ban using iptables.

The last two options are certainly more sophisticated than the mere iptables solution. Unfortunately, it takes more time to configure them as you might have to install the tools first.

My favorite solution is fail2ban since you can use it with almost any application, plus there are packages for most Linux distributions. PAM is more difficult to setup as you probably will have to install it from sources.

Marius described the installation and configuration of all three options in detail:

Using iptables to Block Brute Force Attacks Using PAM to Block Brute Force Attacks Using fail2ban to Block Brute Force Attacks

• FREE: PhoneFactor – Mobile phone based two-factor authentication (1)
• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)

Strange, isn’t it? The release candidate of its successor, ISA Server 2006, is now available for download. While downloading I checked Microsoft’s FAQ about the new version. Of course, I wanted to know first its new features. The text above is just the negation of Microsoft’s answer to the question “What’s new in Microsoft ISA Server 2006?”. Since this is all new, the predecessor, ISA Server 2004, lacks all these features, right?

So what does Microsoft want to tell us? I think those marketing guys are so much used to worshiping their products that they don’t realize how much they torture us with these texts. I’ve been working with ISA Server since it came out in 1999. I’ve been publishing an article about ISA Server 2000 and one about ISA Server 2004. So I think I know this product well. After reading this text I have absolutely no idea what’s new in ISA Server 2006.

Why do they these marketing guys steal my time? Do they really think that IT professionals buy all this fuss? I hope, I didn’t steal your time now with my silly because useless complaints. But I have to let this out every now and then. Anyway, if you really want to know about the new features of ISA Server 2006, you can check out this article at isaserver.org.

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

Michael Kleef, for example, thinks that other security measures should be used to prevent malware from infecting the computer in the first place. He listed several new technologies of Windows Vista, like User Access Protection, Windows Defender and Sandbox of IE7, that should do the job.

I think, this is not a good argument. The more lines of defences you have, the better it is. If the malware manages to get around one defence line, there is still the next in line which stops the malicious program from causing more damage. So, enumerating other features of software to explain away a security weakness is not convincing.

A second argument, which was also put forward by Mitch Tulloch, is that outbound filtering is not important anyway since clever malware can simply use another open port like port 80 to connect to other computers in the network.

There is a big difference between personal firewalls and gateway firewalls. Good personal firewalls don’t just filter ports; they also allow you to specify which desktop applications can connect to the internet. This is very important in corporate networks. If a user starts an application which is infected by a virus or other malware from his USB stick, for example, it can’t infect other computers in the network even if it uses port 80 since the personal firewall will block this application. I wonder, if the firewall of Windows Visa has this feature?

In my view it only makes sense for the home edition of Windows Vista to disable outbound filtering by default. Usually, the configuration is too complicated and time consuming that most users would just turn off the firewall, anyway. This way usability does improve security since security software that is too complicated to handle will simply not be used. So the overall security of the internet wouldn’t be improved.

However, in a corporate environment outbound filtering is very useful even if there is gateway firewall. As network administrators can do the configuration, usability is not an issue here.

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

Today, I installed the beta of ISA Server 2006 on my testing system with an ISA Server 2004. The setup program complained that I have the Firewall Client Share installed. After uninstalling it the setup program complained again that I need Service Pack 1 for Windows Server 2003. Eventually I succeeded upgrading the ISA Server 2004. As expected all my previous settings were transferred to my new installation.

Actually, at first I was wondering if I really upgraded because the user interface looked exactly the same as before. This is good news as I really liked the one of ISA Server 2004. There are certainly many new features, but I think the upgrade is not as significant as the one from ISA Server 2000. At least this was my first impression after reading about its new features. However, I am only at the beginning of my testing. So stay tuned!

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)