You should know the following facts about remote access:
- The ability to connect to a remote access server is controlled through remote access policies.
- Remote access policies are stored on each remote access server. If you have multiple remote access servers, you must configure each server with the appropriate remote access policies.
- If you have multiple remote access servers, you can centralize policies by using a RADIUS solution. IAS (Internet Authentication Server) is Microsoft's RADIUS solution. With RADIUS:
- Each remote access server is configured as a RADIUS client.
- Remote access policies are configured only on the RADIUS server.
- Remote access servers pass authentication requests on to the RADIUS server.
You should know the following facts about remote access policies:
- Authorization for access to resources is determined by three steps:
- Check the connection for a match in the policy conditions.
- Check either the Active Directory user account or the policy for permissions.
- Check the profile settings for additional restrictions on the connection.
- Incoming connections are compared to the conditions found in a policy.
- If the connection does not match the conditions in the first policy, the next policy in order is checked.
- When a match is found, that policy will be used for the connection (no other policies will be checked).
- If the connection does not match any conditions in any policy, the connection will be refused.
- After a matching policy is found, permissions are checked. If the permissions deny the connection, no other policies are checked.
- Permissions identified in the user account override permissions set in the policy (unless Control access through Remote Access Policy is selected).
- If the permissions grant access, the policy profile is checked for additional conditions.
- If all profile conditions match, the connection is granted. If not, it is refused.
VPN Design Guidelines
If you must allow Internet traffic inside your inner firewall and into the private network, implement a VPN solution. Using a VPN server, only clients that can establish a secure connection with the VPN server can access resources on the private network. The following graphic shows one way to configure a firewall to accomodate VPN traffic.
In this example, the DMZ contains an FTP and DSN server available to the public as well as the VPN server. Allow the following traffic to pass through the external firewall, rejecting all other traffic:
- FTP traffic sent to 135.41.11.1
- DNS traffic sent to 135.41.11.2
- VPN traffic sent to 135.41.11.3 (the protocol type allowed depends on whether L2TP or PPTP is used for the tunneling protocol)
Note: With a VPN connection, incoming VPN traffic is encapsulated and is sent to the VPN server, even if the final destination is on the private network. The outer firewall will inspect the incoming VPN traffic and find it addressed to the VPN sever, not to the private network. For this reason, the outer firewall should not allow incoming traffic directed to network 192.168.1.55.
To complete the configuration, configure the following items on the VPN server.
- Configure the VPN server with the appropriate VPN tunneling protocol.
- Configure addressing on the VPN server for clients. When a VPN connection is initiated, the remote client gets an IP address on the private network so it can communicate with hosts on the private network. You can configure the VPN server to assign IP addresses in one of two ways:
- Configure the VPN server to get IP addresses for clients from a DHCP server on the private network. Wehn using DHCP, DHCP traffic does not pass through the external firewall because all communication between private hosts and the VPN server appears as VPN traffic to the firewall.
- Configure the VPN server with a range of IP addresses that it can assign.
In this example, the VPN server will pass out IP addresses from the 192.168.1.0 network.
- If the private network has more than one subnet, configure static routes on the VPN server. This allows external clients to access all subnets in the private network.
Services Facts
You should know the following facts about auditing:
- To audit a domain controller, you can apply a GPO to the Domain Controller OU. That affects all Domain Controllers in the OU.
- To view audit logs, look at the local Event Viewer logs.
You should know the following facts about DFS:
- DFS roots can be either standalone DFS roots or domain DFS roots. A stand-alone DFS server does not use Active Directory, cannot have root-level replicas, and can have only a single level of DFS links.
- Domain DFS roots integrate DFS with Active Directory, adding fault tolerance and site-awareness. Configure sites to ensure that users get data from local copies of replicas.
- DFS data is automatically replicated to other servers when replicas are created.
You can deploy SUS in the following ways:
- The SUS server approves the updates. Clients contact the SUS server for update approvals then retrieve the updates from the Windows Update server. This requires a great deal of bandwidth.
- The SUS server approves and synchronizes the updates. SUS stores the updates locally for clients to retrieve. Reduces bandwidth demands since only the SUS server contacts the Windows Update server.
- The SUS servers in various locations would be responsible approving and synchronizing updates and then contacting the Windows Update server.
