Cannot Logon to the Domain or Contact Other Servers After the ISA Server Installation

[LEFT][CODE]http://www.isaserver.org/tutorials/2004cannotlogon.html[/CODE]


I am sure we have all either encountered or heard of this "problem" one time or another if the ISA Server is part of the Active Directory Domain. Is it a problem? No, it is by design. To block all unnecessary traffic is the job of the firewall. I know Domain Controller traffic is not unnecessary unreachable traffic, but we have to "explain" to the ISA Server that DC traffic is reachable.

[FONT=Verdana][B] [CENTER]Cannot Logon to the Domain or Contact Other Servers
After the ISA Server Installation
By Santhosh Sivarajan[/CENTER]
[/B] I am sure we have all either encountered or heard of this "problem" one time or another if the ISA Server is part of the Active Directory Domain. Is it a problem? No, it is by design. To block all unnecessary traffic is the job of the firewall. I know Domain Controller traffic is not unnecessary unreachable traffic, but we have to "explain" to the ISA Server that DC traffic is reachable.
How can we do this? This can be accomplished by adding all the trusted subnets to the Windows Routing Table (WRT) because the ISA Server thinks only the information available in the WRT can be trusted.
Here is my lab scenario to explain this situation.
[IMG]http://www.isaserver.org/img/upl/2004ca11114176369513.gif[/IMG]
In the above example, you can see that the ISA Server’s Internal Network (10.10.1.X), Active Directory Domain Controllers (10.10.2.X), Exchange Back-End Machines (10.10.3.X) and Exchange Front-End Machines (10.10.4.X) are on different subnets. I know it is a complicated network but I have worked with a similar network structure at several of my client sites.
If you install ISA Server 2004, by default you will lose all the connectivity to the Active Directory Domain Controllers, Exchange Back-End Machines and Exchange Front-End Machines because they are not part of ISA’s Internal network (10.10.1.X). By default, the ISA Server will only consider 10.10.1.X as the internal and reachable network because the 10.10.1.X network is the only network information present in the WRT. Everything else is considered an external network.
What needs to be done during installation to make sure the ISA Server can contact the DCs, Exchange BEs and Exchange FEs? The simple answer to this question is you must manually add each route to reachable networks to the WRT using the "Route Add –P" command before the ISA Server installation.
In the following screen shot you will see I am manually adding 10.10.2.0 (DCs), 10.10.3.0 (Exchange BEs) and 10.10.4.0 (Exchange FEs) to the WRT using the "Route Add" command:
[IMG]http://www.isaserver.org/img/upl/2004ca21114176369513.gif[/IMG]
The next screen shot, will display all the routing information that is part of WRT. You can use the "Route Print" command to display the Windows Routing Table.
[IMG]http://www.isaserver.org/img/upl/2004ca31114176369529.gif[/IMG]
During the ISA Server 2004 installation, the ISA Server looks for the WRT to "learn" the internal and other reachable networks. If the DCs or any other subnet are not in the Windows Routing Table, the ISA Server will think it is located on the default External Network and deny the traffic using the Default Rule. If it is in the WRT, it will automatically add the DC subnet to the Internal network.
In the above scenario, the ISA Server will automatically add the following subnets to its Internal Network:
[/FONT][FONT=Courier New] 10.10.1.0 – 10.10.1.255
10.10.2.0 – 10.10.2.255
10.10.3.0 – 10.10.3.255
10.10.4.0 – 10.10.4.255
[/FONT][FONT=Verdana] [/FONT] [FONT=Verdana][/FONT][FONT=Verdana][B]Note:[/B]
If you go to the properties of the [B]Internal Network[/B], sometimes you will see a "Domain Controller" name in the network list. During the ISA Server setup, it will discover the ISA Server’s "Logon Server" and add it to the Internal Network as a "Domain Controller". You cannot modify this entry. [/FONT]
[FONT=Verdana] [/FONT][FONT=Verdana]Let’s say you forgot to add a route to your Domain Controller or other trusted subnet information, what will happen after the ISA Server installation? Of course, you cannot logon to the Domain or contact any other servers on the trusted network. [/FONT]
[FONT=Verdana]The following section will explain how to resolve this issue:[/FONT]

[LIST=1][FONT=Verdana][*]Logon to the ISA Server using the Local Administrator account (logon locally)[*]Go to the [B]Command Prompt[/B], add the appropriate route using the [B]Route Add –P[/B] command[*]Open the [B]ISA Server Management[/B] Console[*]Go to the [B]Properties[/B] of the [B]Internal Network [/B][*]Add the DC subnets and all other required subnet information[*]Click [B]OK[/B] and close the [B]ISA Server Management[/B] Console[*]Restart the [B]Microsoft Firewall[/B] Service.[*]Log off from the machine and try to logon to the Domain.[/FONT][/LIST]
[FONT=Verdana]The rule of thumb is, if the servers are on different networks than the ISA’s Default Internal subnet and you want to communicate to any other subnet other than the ISA Server’s Default Internal subnet, it must be added to the Windows Routing Table. [/FONT]
[FONT=Verdana]If it is difficult to manually add the route to the ISA Servers, a group policy can be used to add those entries. Keep in mind that those registry entries won’t be added to the WRT until you restart the machine. [/FONT]
[FONT=Verdana]As you can see the design to block all "unnecessary traffic" makes total sense. I hope this article will provide a better understanding of ISA’s Internal and External networks, as well as a work around solution. If you have any questions regarding this article, feel free to email me or post a comment on the newsgroup. [/FONT]
[FONT=Verdana]-------------------------------------------------------------[/FONT]
[FONT=Verdana]About the Author, [B]Santhosh Sivarajan
Santhosh Sivarajan[/B] is an Infrastructure and Security Architect in Houston, Texas. His certifications include MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, and Network+. He has worked for large networking project companies for the past 10 years. His expertise includes Active Directory, Exchange, Migrations, Microsoft Security, ISA Server, etc. [/FONT]



[/LEFT]