Securing Wireless LANs with PEAP and Passwords
Chapter 3: Preparing Your Environment
On This PageOverviewThis chapter helps you to prepare your information technology (IT) environment for the deployment of the security infrastructure for your wireless local area network (WLAN). The principal tasks in preparing the environment include:
Chapter PrerequisitesBefore proceeding with this chapter, you should have a thorough understanding of the architecture and design of this solution, which is described in Chapter 2, “Planning a Wireless LAN Security Implementation.“ In addition, you should be familiar with the installation and administration of Microsoft Windows 2000 Server or Microsoft Windows Server™ 2003. Familiarity with the following topics will also be helpful:
IT Infrastructure Prerequisites and AssumptionsThis chapter and the remaining chapters of this guide are based on the following assumptions about your IT infrastructure; although some of these may be implemented as part of this solution. Many of these assumptions are not rigid requirements; where valid alternative configurations exist, they are indicated in the guidance.
Though the solution has been built to this specific profile, the basic design can adapt to many other configurations, such as branch offices with local domain controllers, or installation into multidomain forests. The impact of alternative valid configurations, wherever applicable, is noted in the guidance. Preparing for ImplementationPermissions NeededTo carry out the procedures given in this chapter you must use an account that is a member of the Administrators group for the domain that contains the servers. By default, the built–in Administrator account of the domain is a member of the Administrators group, however, you can use any other account that is a member of this group. Note: This guidance is based on the assumption that you are installing Certificate Services and IAS on a domain controller. If you are installing these on servers other than domain controllers, the account that you use need only be member of the local Administrators group on each of the servers. Tools NeededYou need the following tools to carry out the procedures given in this chapter: Table 3.1: Tools Needed
Installing the Solution ToolsA number of scripts and tools are supplied with this guidance to help simplify configuration and operation of this solution. You must install these scripts and tools on each of the IAS servers. Some of these scripts are required during ongoing operations (as described in Chapter 8, “Maintaining the Secure Wireless LAN Solution”); therefore, you should not delete them after completing the installation. By default, the scripts are installed into the C:\Program Files\Microsoft\Microsoft WLAN-PEAP Tools folder. To install the scripts and tools on each server
To enable easier access to these scripts, you can create a shortcut to open a command shell in the folder where the scripts are stored. To create a shortcut to the MSS WLAN tools
Using the ScriptsThe scripts are written in Windows Scripting Host using the VBScript language. All the scripts work in a similar way. They should be run by using the two batch files (MSSSetup.cmd and MSSTools.cmd) rather than executing them directly. The batch files simplify the syntax of the scripts. Most of the scripts take a single parameter, which specifies the function to be performed. Some scripts take additional parameters (these are explained in the guidance as required). The scripts are run from the folder in which they are installed; that is, from a command shell with the current working directory set to the tools installation folder. The scripts produce the following different types of outputs:
Setting up Your Network and Directory InfrastructureConfiguring the NetworkYou should connect the components to the network as shown in the following figure or according to the specific requirements of your network. This figure shows the simplest configuration possible where the IAS servers, the APs, and the rest of your internal network are connected to the same LAN. In larger installations, the network is, typically, segmented into multiple virtual LANs (VLAN) that are connected using routers or layer 3 switches. The precise configuration will vary enormously depending on your organization's individual requirements; a detailed discussion of this topic is outside the scope of this guidance. For more information on the network configuration for a WLAN infrastructure, see the “Deploying Wireless LANs” chapter of the Windows Server 2003 Deployment Kit. Configuring the IP NetworkThe solution is largely independent of the VLAN and subnet arrangement. As discussed in Chapter 2, “Planning a Wireless LAN Security Implementation,” you can choose to have your wireless clients on a different VLAN from the rest of the network. However, this solution has only been tested for the simplest case; that is for a given site, the wireless clients are placed on the same LAN as the rest of the network and share the same IP subnet. If you choose to have your wireless clients on a separate VLAN, you must allocate a separate IP subnet for the wireless clients and link the wireless VLAN to the rest of your network using a router or a layer 3 switch. For more complex environments, there are advantages to configuring separate subnets for your WLAN clients at each physical site. These advantages include:
DHCPIP addresses and IP network information need to be allocated to the WLAN clients. This solution uses the Windows DHCP service to do this; therefore a DHCP service must be available for use by the WLAN clients. You need to allocate a separate DHCP scope for each subnet where you will be deploying clients. For example, if you have two separate sites with a routed wide area network (WAN) connection between them, you must create a DHCP scope for each subnet. If you are allocating separate subnets for your WLAN and wired LAN clients, you need to configure a separate scope for each WLAN subnet. Moreover, if you have routed connections between your APs and DHCP servers, you need to configure DHCP relay agents on the routers or install the Windows DHCP Relay Agent on a server on the same subnet as the APs. For higher availability, you should consider a resilient DHCP configuration using split-scopes, clustered DHCP, or standby DHCP configurations. For more information about these, see the “Deploying DHCP” chapter of the Windows Server 2003 Deployment Kit. DNSActive Directory depends on a properly functioning Domain Name System (DNS) service. This solution is based on the assumption that such a service is in place and operational. You will have installed DNS as part of the Active Directory installation process or have configured it separately. Active DirectoryThis solution has been designed and tested using the following Active Directory configuration:
In many cases, it is possible to use other configurations of Active Directory; for example, using multiple domains or using Windows 2000 domain controllers. Where these configurations are supported by Microsoft, additional guidance on using these is given in the text. However, these alterative configurations do not form part of the core, tested solution. Requirements for All Versions of Active DirectoryA native mode domain allows you to create Active Directory universal security groups. Using universal groups makes managing multidomain network access policies easier. However, for single domain deployments, this setting is academic. The installation scripts check whether the domain is in native mode or not. If the domain is in native mode, the script will make use of universal groups but otherwise it will only use global groups. Active Directory must have a Windows Server 2003 schema. This is needed to support the Wireless Network Policies GPO Settings. There is no requirement for a specific Active Directory forest functionality level. In this solution, the default Windows 2000 forest functionality level is assumed. For more information about the concepts of domain and forest mode, see the references at the end of this chapter. Using Windows 2000 Domain ControllersIn this solution, IAS and Certificate Services are installed on Windows Server 2003 systems. No guidance is given for using the Windows 2000 versions of these components. If you are using Windows 2000 domain controllers and are not planning to upgrade any of them to Windows Server 2003 you must upgrade the schema to Windows 2003 level. For more information about upgrading your schema, see the reference at the end of the chapter. If this solution is to be used in a domain or forest using Windows 2000 domain controllers, you must ensure that these domain controllers have Windows 2000 Service Pack 3 (SP3) or later applied. The service pack is required to ensure that the domain controllers support Lightweight Directory Access Protocol (LDAP) signing. This is a security enhancement required by Windows Server 2003 CAs and Windows XP clients that use automatic certificate enrollment. Verifying the Security of the Domain Account PoliciesThis solution relies on user and computer passwords for authenticating users and computers to the WLAN. It is, therefore, extremely important that you do not allow use of weak or blank passwords. Easily predictable passwords will make it simple for an attacker to break on to your WLAN. Because the same passwords are used to authenticate the user or computer to the domain, this will allow the attacker access to all your network resources as well. The easiest way of eliminating weak passwords is to set strong password policies in the Default Domain Policy GPO. You should also enforce periodic expiry of passwords, minimum password age, and password history check (to ensure that users are not reusing the same password). Warning: You should warn your users and administrators before changing the domain password policy. To avoid frustration and confusion among your users, it is a good idea to inform them early about the new password policy that you plan to adopt, together with instructions on choosing good passwords. For recommendations on best practices for your domain password policy, see the Windows Server 2003 Security Guide. Reference for this document is provided at the end of this chapter. Creating Security GroupsUse the procedure given later in this section to create security groups in Active Directory for use in this solution. The groups created are listed in the following table and, where indicated, their membership is populated. By default, these groups are created in the Users container. Table 3.2: Security Groups and Memberships
To create and populate security groups
Preparing Your ServersThis section covers server–specific configuration. You need to perform most of the following procedures for each server that you plan to install as IAS server. The procedure in the "Server Security Configuration" section is the only exception because, even though the security settings are applied to each server, this procedure has to be executed only once per domain. The settings are then automatically applied to others servers in the domain. Operating Systems SupportedThis solution has been built and tested using Windows Server 2003, Standard Edition for all server components. However, the guidance and installation scripts are the same for Windows Server 2003, Enterprise Edition. You should read the "Using Windows Server Standard or Enterprise Edition" section in Chapter 2, "Planning a Wireless LAN Security Implementation" before deciding whether you need to use Windows Server 2003, Enterprise Edition or not. Use of Windows Server 2003, Standard Edition places limitations on the functionality of Certificate Services and the number of wireless APs that IAS can support, either or both of which may be unacceptable for large organizations. This solution has not been designed to support earlier versions of Windows Server and has not been tested with any of them. The Windows 2000 Server versions of IAS and Certificate Services may work for some or all of the server roles in this solution but guidance on how to do this is outside the scope of this documentation. Hardware GuidelinesThe first server that you install will run Certificate Services as well as IAS. Certificate Services requires minimal resources in this solution. However, you should ensure that the load that IAS places on the server does not negatively affect the performance of the domain controller functions of the server. This is unlikely to be the case in any but the very largest IAS implementations. If necessary, you should add an additional domain controller to the same Active Directory site to compensate for this. If you plan to enable RADIUS logging, you should allocate a separate physical disk for the logs. Table 3.3: Recommended Minimum Hardware for IAS Server
You should read the "IAS Software and Hardware Requirements" section in Chapter 2, ”Planning a Wireless LAN Security Implementation,” for a further discussion of hardware performance requirements. Obtaining and Installing Supporting SoftwareThis section lists the additional software needed on your servers. It also describes how to obtain and install the software. Group Policy Management ConsoleGroup Policy Management Console (GPMC) is used to install and configure the Group Policy Objects (GPOs) used by the solution. The GPMC only needs to be installed on the first server on which IAS is installed; its installation on subsequent IAS servers is optional. Note: Installation of the GPMC changes the user interface of Active Directory Users and Computers slightly on the server on which GPMC is installed. For more information on using the GPMC and downloading, see the reference at the end of this chapter. To install the Group Policy Management Console
Windows Server 2003 Support ToolsSome of the Windows Support Tools are used by the configuration scripts and procedures in this solution. You should install these from the Windows Server 2003 installation media. These are needed by the CA installation and configuration scripts so you must install them on the on the server on which Certificate Services is to be installed. They are not required on the other servers although you may wish to install them there. To install the Windows Server 2003 support tools
CAPICOMCAPICOM is a scriptable interface to a set of Windows security functions known as the CryptoAPI (CAPI). CAPICOM is needed for the Certificate Services health monitoring scripts and to generate the RADIUS secrets used to authenticate the wireless APs. You should install CAPICOM version 2.0 or later on all IAS servers in your organization. You can find the latest version CAPICOM 2.0 at the Microsoft Download Center (see the "References" section at the end of this chapter). The CAPICOM distribution file does not contain an automated setup; therefore you should use the batch script, InstCAPICOM.cmd (supplied with this solution). If you wish to perform these steps manually, you can copy the commands from the batch script. To install CAPICOM
Microsoft Baseline Security Analyzer (MBSA)This tool is required to verify that the operating system security updates are current and to detect possible problems with the security configuration of the servers. You need to use version 1.1.1 or later of MBSA to scan Windows Server 2003 systems. You can find the latest version of MBSA at the Microsoft Download Center. To install MBSA
Server Security ConfigurationThis section describes how to apply security policies and other security measures to Windows Server 2003 prior to installing IAS and Certificate Services. This solution is designed to be installed on existing servers (typically domain controllers). The security settings used in this section are intentionally conservative because of the danger of security settings conflicting with installed applications and services that may be already running on the server. Using the Windows Server 2003 Security GuideWindows Server 2003 has strong default security settings. For most organizations, these settings provide good protection for their systems if combined with an effective update maintenance process (for more details on update maintenance, see the "Server Security Updates" section later in this chapter). However, you should also consider the recommendations described in the Windows Server 2003 Security Guide. This guide defines security settings appropriate for different server roles. Servers used in this solution carry out several of server roles defined in the Security Guide; the "Domain Controller" and "RADIUS Server" roles for most servers; and, in the case of the first server, the "Certification Authority" role as well. For each role, the guide defines a security template with all the security settings appropriate to that role. For a server with multiple roles, you must therefore apply a combination of the security templates corresponding each of the server's separate roles. On your servers, you may also have other infrastructure services such as DNS, DHCP, and Windows Internet Naming Service (WINS), in which case you need to include the security templates appropriate to these roles as well. For instructions on how to do this, see the Windows Server 2003 Security Guide. Warning: The security setting templates in the Windows Server 2003 Security Guide explicitly disable a number of services not required by the defined server roles. If you have any other applications or services running on the servers, you must test these applications to ensure that the security templates do not disable services or change any security settings on which your applications or services are dependent. Instructions on combining roles and changing settings to accommodate other applications are also included in the Windows Server 2003 Security Guide. Applying Security SettingsUnlike most of the other procedures in the "Preparing Your Servers" section of this chapter, this procedure does not need to be carried out on each server. Instead, the settings are imported into a GPO in Active Directory and then applied globally to all the servers. There are only two types of security settings applied in this solution. The first type is applied to configure all required services to start automatically (in case these are stopped or disabled by any other security policy applied to the computer). The second type is applied to change the audit policy so that audit failures for common events (such as logon) are also captured to the security log. The following table lists the services set to start automatically. Table 3.4: Windows Services Enabled by Policy
The following table lists the audit categories where failure auditing is enabled in addition to the default success auditing. Table 3.5: Audit Policy Settings
Enabling the audit settings shown in the table will increase the storage requirements for the security log. You should ensure that the event logs are set to adequate sizes on your domain controllers. The default size of event log for Windows Server 2003 are more than adequate but Windows 2000 used default sizes that were normally far too small for practical use (these settings may still be in effect if you have upgraded from Windows 2000). In Chapter 5, “Building the Wireless LAN Security Infrastructure,” you will see how the IAS servers are configured to log all successful and failed WLAN connections to the Windows system log. You should ensure that security and system logs are set to adequate sizes on all domain controllers. Windows Server 2003 uses 16 MB for the system and application logs and 128 MB for the security log: these are appropriate values for this solution. Importing the Security Settings GPOThe following procedure imports the settings described in the previous section into the domain but does not apply them to any server. To install the security settings GPO into your domain
Applying Security Settings to All Domain ControllersIn this procedure the security settings are applied to all the domain controllers (with or without IAS installed). This should not have an adverse effect on domain controller functions or any other applications or services running on them because there are no settings in the GPO that disable any functionality. If you do not want to apply these settings to all of you domain controllers see the procedure immediately following this one. To apply the settings to all domain controllers, you need to link the imported GPO to the Domain Controllers organizational unit (OU). GPO is linked manually because of the danger of overwriting GPO settings already configured in your domain. To apply the security settings to all domain controllers
Applying Security Settings Only to IAS ServersIf you do not want the security settings to be applied to all domain controllers (or if you have chosen not to install IAS on the domain controllers), you can create a separate OU for IAS servers and then apply the GPO to that OU. If you are not installing IAS on domain controllers, you should create the IAS servers OU in some other part of the domain. To apply the security settings only to the IAS servers
Verifying the Security SettingsTo verify that the security settings have been applied
Server Security UpdatesIn contrast to the GPO security settings, you need to check and apply security updates on every server. If you have relatively few servers to manage, you can use manual procedures. If you have many servers and do not already have an automated update maintenance system, manually checking for and applying updates on all servers will be an extremely tedious task. Instead, you should consider automating the application of security updates using Microsoft Software Update Service (SUS) or Microsoft Systems Management Server (SMS) 2003. For more information on the use of these to manage security updates, see the Microsoft Guide to Security Patch Management. Checking Current Security UpdatesThere are two main ways of checking the currency of the security updates on your server, namely Windows Update and MBSA. There are also tools, which perform similar functions, from vendors other than Microsoft. Windows UpdateWindows Update is an online service designed primarily for use by small businesses and home users (there is, however, no restriction on who can use this service). Because Windows Update requires a live connection to the Internet, you must not use this service without protecting your server with a firewall. For more information on Windows Update, see the references at the end of this chapter. Microsoft Baseline Security AnalyzerMBSA is a security evaluation tool, which checks systems for a variety of security problems including missing updates. For more information on MBSA, see the references at the end of this chapter To check installed security updates using MBSA
Using MBSA to Check Other Security IssuesApart from checking that security updates are current, you should use MBSA to check for other potential security problems on your server. To do this, run the graphical version (from the Start menu), perform a scan of the server, and act on any warnings. In particular, you should watch for any user accounts detected as having blank, weak, or nonexpiring passwords. However, do not alter the settings of any built-in accounts such as krbtgt. Unless you have changed the default Internet Explorer security zone settings on your servers, you can ignore MBSA warnings about nonstandard settings. The default settings for Windows Server 2003 are stronger than the Internet Explorer zones settings which MBSA is checking against. The procedure given in this chapter only covers running MBSA to scan the local machine, procedure for running it to scan computers over the network is beyond the scope of this guidance. For further details on the use of MBSA, see the reference at the end of the chapter. Managing and Installing Updates on Your ServersComprehensive coverage of automated on–going updates management is beyond the scope of this guidance. However, you should be aware of the three main ways in which you can perform ongoing management of system updates using Microsoft technology. AutoUpdateAutoUpdate is a service built into Windows servers and clients that allows each computer to check for and download any important security hotfixes as they are released by Microsoft. You have the option to have the updates automatically installed. This requires that each computer has Web (HTTP) access. The earlier caution about ensuring that you have adequate firewall protection in place for each device (see the “Windows Update” section) applies here as well. For more information about AutoUpdate, see the reference at the end of this chapter. Software Update ServiceSoftware Update Service (SUS) builds on the AutoUpdate service. It removes the requirement for each computer to connect to the Internet, by centralizing the update checking and downloading functionality in one or more central computers. The administrator can then approve or reject downloaded updates at the SUS server(s). All approved updates are retrieved by all the other computers in the organization. These computers use the AutoUpdate service to check and download updates from the SUS server(s) instead of the Windows Update site. For guidance on how to deploy SUS, see Patch Management Using Microsoft Software Update Services. The URL to obtain this document is given at the end of this chapter. Update Management with Microsoft Systems Management ServerUsing Microsoft SMS 2003, you can completely automate the delivery of service packs, security updates, and software updates. Using SMS 2000 with the Software Update Services Feature Pack integrates the features of SUS with the wider capabilities of SMS. Both SMS 2000 and SMS 2003 include the ability to schedule MBSA scans of your organization's computers. For more information about the use of SMS, see the following papers:
URLs to obtain these documents are provided at the end of the chapter. SummaryThis chapter provided guidance on preparing your network, Active Directory, domain controllers, and other elements of your environment for the installation of a secure WLAN infrastructure. The scripts used to configure this solution were installed together with a number of supporting tools. Security groups used by this solution were created in the domain, and security settings were imported and applied to your servers. Finally, the currency of security updates on the servers was examined and, if necessary, corrected. The next chapter covers installation of Certificate Services on the first server installed to create the network CA. ReferencesThis section provides references to important supplementary information or other background material relevant to the content of this chapter.
|
In This Article
|
