Derek Schauland explores the ways you can improve authentication for remote locations via WAN links if your organization is still using Windows 2003 Server and Active Directory.
Some organizations have multiple locations, and not all of them have Domain Controllers (DC)s to allow for local authentication. For those of you whose organizations have Windows 2008 deployed, you might consider Read Only Domain Controllers to improve the authentication process in your Active Directory environment. With the coming of Windows 7 there will also be additional features to aid in WAN link management; read about branch caching here.For organizations still running Windows Server 2003 Active Directory (AD), WAN authentication can be a bit of an issue. If you belong in this group, I'll go over a couple of ways that you can improve authentication for remote locations via WAN links.
There are two concerns with authentication over a WAN link: bandwidth usage and location. Having a high-bandwidth solution between locations within the same town might be a great way to ensure fast authentication, but the locations that are far away might need to rely on other means to ensure they can authenticate with AD. You should examine the needs of the remote locations and determine if more bandwidth to the Internet would be a true fix, and you could also consider extending your AD environment into the remote locations as possible solutions to your problem.
Using multiple sites with AD
Active Directory supports the use of sites to allow replication of infrastructure data between locations. To configure AD to use multiple sites, you will need to place a DC in each remote location that is to be considered its own site and then configure AD to view these locations as separate entities within the same domain or forest. The connection between sites should be fairly high speed to ensure that replication can be completed in a reasonable period of time.
To create a site in AD, complete the following steps:
- Start the Active Directory Sites and Services from the Administrative Tools menu.
- Right-click the sites container and select New Site.
- Enter a descriptive name for the site.
- Choose the site link that will be used to connect the new site to other sites. (Keep in mind that the links needed to link to other sites cannot be created until the sites exist. You will need to create each site before you can link to it.)
- Once you have entered a new site and chosen a link to another site (or sites), click OK. You will see a prompt detailing steps needed to complete the configuration of the site. Click OK again.
- Create links from your new site to other sites. Remember both sites used in a link must exist before the link can be established.
- Create a subnet for the site. This will associate the site and computers on that subnet within AD.
To create a subnet and associate it with a site, complete the following:
- Open Active Directory Sites and Services from the Administrative Tools menu.
- Right-click the Subnets container in the left pane of the console.
- Select New Subnet.
- Enter the network address for the subnet in the address field, which will typically have 0 as the last octet.
- Enter the mask value for the subnet.
- Select the site that the subnet should be associated with.
Considering bandwidthWhen authentication occurs over a WAN link from a remote location to the home office, the bandwidth on both ends is crucial to ensuring that the process is timely. If the user authenticating has to wait 15 minutes to authenticate to the domain because the remote location is using dial-up, it may be a worthy investment to consider upgrading the location's connection. Note: Using dial-up for single user authentication while traveling can be a great way to save money, but using dial-up to allow an entire site or office location to access the network would not be efficient in that the connection would need to be constantly available and in use to work well.
Best solutionBecause a remote site can have few or no users or equipment all the time, it is not always feasible to place a DC in the remote site. For example, my organization has remote sales staff people who work out of their home offices. The bandwidth into these locations is a 6+ Mbps connection, but there is only one user in each location needing to authenticate. This would not be an ideal situation for a DC to be placed in these remote locations. Simply providing VPN access to the user from their office has proven to be effective. However, in another location there are several users working with the AD environment, and constant traffic across the WAN link at the home office from this location might not be ideal. In this situation, a DC has been installed along with a high-bandwidth Internet connection to improve log-on times and allow efficient use of resources. Reviewing your organization's environment and implementing the most cost effective and workable solution for the remote users will be the best way to decide how your company should handle WAN authentication.
What's the catch?
Because the remote authentication scenarios discussed above involve the Internet, there may be times when the WAN link is unavailable. In times when this happens, and for most organizations, it will happen on occasion, there are several things to watch out for.Windows 2003 Server caches user log-on and domain information, allowing authentication to continue in the event that the WAN link goes down. Once cached, domain resources that do not require domain authentication will be available. Resources that require domain authentication, such as network shares or e-mail, will not be available if the WAN link is down. Windows will cache 10 log-on entries by default, when enabled, and the maximum cache size is 50 entries. This can help mitigate the downtime associated with WAN links and reduce the number of errors that appear when the domain is unavailable.
Hopefully, the items discussed here will help you make the best use of WAN links and Active Directory in your organization.