Starting with the advanced configuration settings used to link the branch office Domain Controller to the main office Domain Controller in intra-domain communications.
In the first five years of a series of how to create a Site-to-Site VPN between the main office ISA Firewall and the branch office, we have focused on issues related to creating and managing the Site-to-VPN VPN connection itself. Site. Now that we have the Site-to-Site VPN connection details created, we can adjust it to get a higher level of security than a regular VPN 'hub' or port 'hard drive'. into virtual private network (VPN gateway).
First we should start with the minimum privilege in configuring the branch office ISA Firewall for branch computers, to support internal communications between the branch office Domain Controller and the main office Domain Controller. The branch office ISA Firewall configuration supports the main office Domain Controller as a good example, because we need some other configuration steps to help the branch office Domain Controller work.
Some of the following steps can be called relatively complete:
Stop DDNS operation on Demand-dial interfaces and Main, Branch Office ISA Firewall machines
You may recall that, in part one or two of this series, we mentioned DDNS downtime on the msfirewall.org forward lookup zone. Perhaps you also remember why we did it? This is because we do not want the ISA Firewall in both the main office and the branch office to register the demand-dial interface IP address on DNS. When the demand-dial interfaces register with the DDNS, it has many problems that will occur, because the client handles the name of the ISA Firewall through the deman-dial interface address instead of the real IP address.
In the first two articles, one question is whether we really need to disable DDNS? Is there a better way, can you help us configure to manually dial-dial interfaces without address registration in DDNS? Because it is quite inconvenient to stop using DDNS on DNS server, it is even unrealistic.
The good news is that we can automatically disconnect the DNS registration process on demand-dial interfaces for both the main office ISA Firewall and the branch office ISA Firewall through the use of the RRAS console. In general, we need to avoid making VPN configuration changes on the ISA Firewall using the RRAS console, since these settings may override changes in RRAS. Fortunately, we can now change the DDNS registration information for the demand dial interface so that they do not override the ISA Firewall VPN configuration.
Follow these steps on the main office ISA Firewall:
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 1
Figure 1
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 2
Figure 2
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 3
Figure 3
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 4
Figure 4
Follow these steps on the branch office ISA Firewall:
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 5
Figure 5
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 6
Figure 6
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 7
Figure 7
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 8
Figure 8
Allows the use of DDNS on msfirewall.org Forward and Reverse Lookup Zone
Now, the problem with the demand-dial interfaces has been resolved, we can allow the use of DDNS on the msfirewall.org domain. DDNS is generally useful, especially in specific areas: automatically registering all branch branch domain domain domains related to DNS records in the main office DNS. We can manually create these 'manual' logs, but there can be many administrative problems and increase the level of danger when causing errors.
Log in to the Domain Controller in the main office and perform the following steps:
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 9
Figure 9
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 10
Figure 10
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 11
Figure 11
Create Intra-domain Communication Access Rule on the Branch Office ISA Firewall
With the above platform, we can now switch to the ISA Firewall configuration. The first thing we need to do is create a rule that allows the branch office Domain Controller to use the internal protocols needed for domain communication to work with other Domain Controllers. In this example we will work with a Domain Controller at the main office.
The table below is a set of Access Rule settings for common local protocols:
DNS
Kerberos-Adm (UDP)
Kerberos-Sec (TCP)
Kerberos-Sec (UDP)
LDAP (TCP)
LDAP (UDP)
LDAP GC (Global Catalog)
RPC (all interfaces)
NTP
Ping
From Branch Office DC To Main Office DC Users All Schedule Always Content Types All content typesTable 1 : Protocols required for intra-regional communications.
One thing to note here is that this method not only allows intra-domain communications from the domain controller at the branch office to the domain controller in the main office. This method also focuses on controlling traffic from branch to headquarters with the assumption that all traffic is allowed to move from the main office to the branch office. This is not the optimal method (we will change the following Access Rule main office), but it is considered the best method for access control: the area is more dangerous than the branch office. Therefore, we will pay much attention to controlling the transition between the branch office and the head office.
On the other hand, you can set up access policies at the headquarters and focus on the main office ISA Firewall, creating an Access Rule there to control what can come from branch offices.
The most appropriate and flexible method for controlling access between the branch office and the main office is to use Enterprise Policies. When creating an Enterprise Policy, you can assign each policy to an array, representing each branch office installation program. This greatly simplifies managing firewall policies for branches. Because you can just make changes once, then they are automatically populated for all branch office arrays.
In this example, we will use an Enterprise Policy to explain how Enterprise Policies work.
The first step is to create a new Enterprise Policy. We need to create a new one because we cannot make any changes on the default Enterprise Policy. Next, create an Access Rule that can be applied to all Enterprise Policy arrays defined. The final step is to connect Enterprise Policy to the branch office ISA Firewall array.
Perform the following steps on the CSS machine to create an Enterprise Policy:
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 12
Figure 12
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 13
Figure 13
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 14
Figure 14
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 15
Figure 15
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 16
Figure 16
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 17
Figure 17
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 18
Figure 18
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 19
Figure 19
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 20
Figure 20
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 21
Figure 21
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 22
Figure 22
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 23
Figure 23
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 24
Figure 24
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 25
Figure 25
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 26
Figure 26
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 27
Figure 27
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 28
Figure 28
Now that the Enterprise Policy is configured, the next step is to mount the Enterprise Policy with the branch array. At the present time, the default Enterprise Policy has been attached to the branch office array. We will change some things so Branch Policy is attached to this array.
Follow these steps:
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 29
Figure 29
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 30
Figure 30
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 31
Figure 31
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 32
Figure 32
Create a Site-to-site VPN on ISA 2006 (Part 6) Picture 33
Figure 33
As you can see on the Enterprise Policy illustration, it is much easier to apply policies to multiple branch offices by making changes once on the Branch Policy Enterprise Policy. These changes will be automatically replicated to all areas associated with the policy. Certainly it is much easier to make changes to each array, especially with about 30 or more domains. For example, if you want to add more Domain Controllers, all you need to do is update Computer Set Branch. Office DCs . This rule will apply to new DCs in the branch.
Summary
In Part 6 of this series on how to use the Site-to-Site Branch Office Connectivity VPN to connect between these branch offices and headquarters, we started with some advanced configuration settings used. in linking the branch office Domain Controller and the Domain Controller main office with intra-domain communications. In this article, I introduced an event that breaks the usual rules, how to create and use Enterprise Policy to streamline policy development and deployment of distributed Enterprise Firewall. In the next article in this series, we will run depromo on the branch office Domain Controller, install Active Directory to integrate the DNS server on the branch office Domain Controller and change DNS settings on the branch office ISA Firewall.
After the Branch Office Domain Controller is installed, the next step is to create firewall policies for branch offices, allowing access to resources at the main office. We will also create an optional group or user based policy that allows users to access Exchange Server resources at the main office, etc. If we have time we will also begin configuring an alternate CSS to make it possible to tolerate errors for the ISA Firewall Enterprise configuration.
Create a Site-to-site VPN on ISA 2006 (Part 7)