Changes in Windows Vista Affecting SDI

With all the changes in the firewall and IPsec implementation in Windows Vista, it stands to reason that the way you implement SDI has also changed a bit.

AuthIP

We discussed in Chapter 11 how IPsec now supports IPsec user authentication (called AuthIP). AuthIP enables a number of new scenarios that were simply not possible with only computer-based authentication. One of them is the oft-requested client-to-DC IPsec we discussed earlier.

Client-to-DC IPsec

Recall that the primary issue with client-to-DC IPsec was that systems that are not joined to the domain cannot negotiate IPsec with the DC. This now works in pure Windows Longhorn Server domains with Windows Vista clients. When an administrator attempts to join a system to the domain, the administrator is prompted for a user account with rights to access the DC and join the system to the domain. The IPsec communication is negotiated using the NTLMv2 protocol and the user credentials. This resolves the boot-strapping issue that was the primary blocker of IPsec between clients and DCs.

Authentication with Multiple Credentials

One problem with the typical IPsec-based server isolation scenario is that the connection is not restricted to legitimate users. If an attacker manages to take over a trusted computer the attacker can do anything that any user on that computer can do. Using AuthIP, you can restrict a connection not only to a particular computer, but also to a particular user. We showed this in Figure 11-12 in the previous chapter, which is repeated here as Figure 12-1.

Figure 12-1: You can restrict connections to only particular users.

Keep in mind that Figure 12-1 shows an inbound rule setting out requirements only. The directional rules do not, as we pointed out in Chapter 11, actually configure the IPsec rules. To do that you have to provide a connection rule that actually secures the traffic.

Improved Negotiation Flow

With IPsec there is typically no fall-back of authentication methods. However, in Windows Vista, a computer can try several protocols during an IPsec negotiation. This permits you to specify which protocols you prefer, as well as which you would allow if the ones you prefer fail. You can specify the protocol preference order both for user and computer authentication, as shown in Figure 12-2.

Figure 12-2: You can now specify which authentication protocols are preferred.

Falling back to less preferred protocols is a great feature for computers that may not have been completely configured yet. The perfect example is a computer that is not yet domain joined. By using NTLMv2, which, by the way, is a new protocol for IPsec purposes that is not supported in prior versions of Windows, a non-domain joined computer can negotiate IPsec to a domain controller.

Vastly Improved Configuration User Interface

Perhaps the biggest change of all with respect to SDI is the vastly improved configuration interface. Figure 12-3 shows a portion of the many "wizards" used to build an IPsec rule in previous versions of Windows.

Figure 12-3: Configuring IPsec rules in prior versions of Windows was anything but easy.

The user interface has been improved in more ways than just usability in Windows Vista. It has also been extended to include pre-canned "wizards" for SDI rules. When you start building a connection rule-a rule that specifies how a permitted connection must be secured-in Windows Vista, you start out with the screen shown in Figure 12-4.

Figure 12-4: The initial screen on the connection security rule wizard asks you to select a rule type.

Domain Isolation Rules

Isolation rules are the rules that restrict connections based on various criteria, such as domain membership. Building a rule to allow inbound connections only from domain members is actually quite simple with this wizard. Make sure Isolation is selected, as shown in Figure 12-4, and click Next to get the window in Figure 12-5.

Figure 12-5: First you define which connections you require authentication on.

In Figure 12-5, you get to define whether you want to require or request authentication, and on which types of connections. If you are building a domain isolation rule for clients, you probably want to require authentication on inbound connections, as clients should not be servers-but only request it on outbound connections as not all servers may support IPsec. With prior versions of Windows, it was paramount to also have a large number of exceptions that did not require authentication. The reason was that the fall-back to clear when a client requested authentication and the server did not support it was longer than the reset interval on most connections. The result was that even if a computer was set up to request but not require authentication, all outbound connections configured this way failed. This was fixed in Windows Vista by changing the fall-back to clear time-out value when a computer requests authentication. A computer will now fall back to clear text much faster, making it possible to request encryption in scenarios where the request may be ignored. Previously such requests would almost invariable result in failed connections. This change was also back-ported to down-level platforms. See Microsoft Knowledge Base article 914841 for more details.

The next step is to decide which type of authentication to use. Figure 12-6 shows the screen for this. The default selection, somewhat surprisingly, is "Default."

Figure 12-6: You can customize authentication protocols.

On this screen you may notice that the option for pre-shared keys has been removed. Pre-shared key IPsec authentication is still supported, under the Advanced option, but is highly discouraged. Not only are pre-shared keys an absolutely nightmare to manage, but they are also stored in clear-text in the registry, making them notoriously insecure. The default option uses whichever authentication options are configured via Group Policy for the firewall itself. The defaults can be configured in the firewall properties, as shown in Figure 12-7.

Figure 12-7: Set the default authentication options in the firewall properties.

Paradoxically, the dialog box in Figure 12-7 that you use to configure the default authentication options also has a default option. In other words, the default is to use default, which defaults to default. Fortunately, the default is "Computer (using Kerberos v5)," which is probably what you want anyway, if you haven't become so confused by now you have given up entirely. (By default, it is actually not as confusing as the defaults may seem.) Leave it alone and you get computer authentication using Kerberos v5.

The only thing left after Figure 12-7 is to configure which profiles you want this rule used in. You may not want it in all profiles. If it is a domain isolation rule, for instance, and it uses Kerberos as the authentication protocol, it would be quite meaningless to allow it to be used when the computer is in the public profile.

It is also important that you create the appropriate exceptions using directional rules to allow the IPsec secured traffic to make it through. Remember from Chapter 11 that when sorting out precedence for firewall rules the most restrictive rule wins. In other words, if you have a connection security rule that allows some traffic, but there is no inbound rule that permits it, the traffic is blocked because the inbound firewall will block it before the IPsec filter even comes into play. However, if you have a directional rule that allows the traffic if it is secure, the connection security rule will take effect and allow traffic that meets its requirements.

For this reason, we recommend that you create an inbound rule in the firewall that allows all traffic from domain members if it is secure. This creates a blanket IPsec bypass that permits all traffic that matches the conditions of one or more connection security rules. If no connection security rules permit the connection, it will be blocked at the IPsec layer.

Server Isolation Rules

Server Isolation rules are also much simpler to build in Windows Vista than in earlier versions of Windows. First, go back to the screen shown in Figure 12-4 and select a server-to-server rule. Next, select which computers are in the two endpoints. This is shown in Figure 12-8.

Figure 12-8: Select end-points for a server-to-server rule by IP address.

As you can see in Figure 12-8, you can configure server isolation rules for ranges of IP addresses. However, you cannot configure them for hostnames. In other words, server-to-server isolation rules can be difficult to build for clients where you typically use DHCP. However, if you simply want to permit inbound connections from one or a few systems, such as a management station, the problem can be solved by ensuring that the management station(s) have predefined IP addresses. In that case, you would simply specify one of the endpoints as "Any IP address." As far as IPsec is concerned, there is no concept of "my IP address." IPsec does not consider the direction traffic was sent in the same way a firewall does. Therefore, either endpoint 1 or endpoint 2 can be "Any IP address." It makes no difference either way.

Once you have selected the endpoints, the rest of the rule configuration proceeds exactly like a domain isolation rule, with selecting the connection requirements authentication, which profiles the rule applies in, and so forth. Oddly enough, the Domain member authentication options do not appear in the authentication dialog box for server-to-server rules. You have to select Advanced and then Customize … to select Computer (Kerberos v5) to use Kerberos for authentication. Stranger still, the Preshared key option is shown in this dialog box. There may be some solid reasoning behind this dialog box design, but it could also be that Microsoft did not complete the UI design for connection security rules.