Presentation on theme: "Module 9: Providing Secure Access to Remote Users."— Presentation transcript:
Module 9: Providing Secure Access to Remote Users
Overview Identifying the Risks of Providing Remote Access Designing Security for Dial-Up Connections Designing Security for VPN Connections Centralizing Remote Access Security Settings
When you provide access to your network from remote locations, you must ensure that resources are protected from unauthorized access and that information cannot be intercepted during transmission. Microsoft® Windows® 2000 includes remote access security features that allow you to protect your network while providing secure access for remote users. In addition, Windows 2000 includes features that allow centralized administration and management of remote connections.
At the end of this module, you will be able to: Identify the risks associated with providing network access to remote users. Design a secure network for remote users who access the network by using dial-up connections. Design a secure network for remote users who access the network by using virtual private network (VPN) connections. Design a secure network for remote users by centralizing the security configuration of remote access servers.
Identifying the Risks of Providing Remote Access Remote Access Server Modem Password Cracking Data Capture Impersonation Security Weaknesses Password Cracking Data Capture Impersonation Security Weaknesses Unauthorized Remote Access Client
To provide secure remote access to your organization's network, you must manage the risks that are inherent in remote access connections. You must identify and address the risks so that you can permit legitimate users to access your network while keeping out intruders who may try to gain access to your network. Intruders may use a variety of techniques to attempt to break in to your network system to simply explore the network, to steal information, or to deliberately cause damage.
Password Cracking Password cracking describes an attempt by an intruder to determine the password for a known account by using a dictionary attack. A dictionary attack is an attempt by an unauthorized user to discover a password by using a known user name and a list of common words as the password.
You can defeat password cracking attempts by: Avoiding passwords (especially administrative passwords) that can be found in the dictionary. Requiring that all users create passwords consisting of uppercase and lowercase characters, numbers, and punctuation. Configuring the user account lockout features to disable a user account after a specified number of unsuccessful passwords has been attempted.
Network Data Capture Network data captured by an intruder can be used to obtain confidential information, such as passwords and corporate data. Data capture, typically called network sniffing, is achieved by using a network data analysis tool or program, such as Network Monitor in Windows 2000 Server. You can secure network data by: Implementing a strong authentication method to protect the password. Encrypting all information that is transmitted between a remote client and a remote access server.
Impersonation Impersonation describes an attempt by an intruder to convince a legitimate user to disclose information that will allow the intruder unauthorized access to the network. The intruder then uses the information obtained from the legitimate user to impersonate that user.
You can defeat impersonation intrusions by: Implementing callback or caller ID systems to restrict the telephone numbers that can be used to dial up your network. Installing a third-party security host that requires two- factor authentication, or one-time passwords. Two- factor authentication describes the use of two pieces of information to validate a user's credentials, such as a smart card and a password. One-time passwords are passwords that are only valid for a brief period of time. Configuring remote access policies to allow access only when the user is connecting from authorized Internet Protocol (IP) addresses and calling station identifiers.
Security Weaknesses Administrators or users can unwittingly provide security weaknesses in remote access connections that an intruder can exploit.
You can reduce security weaknesses by: Removing analog telephone lines wherever possible to prevent users from installing unauthorized remote access connections. Creating a centralized remote access security policy for all remote access servers, thereby preventing inconsistent settings and security weaknesses from being configured on an individual remote access server. Eliminating unnecessary resource access and dial-up permissions for users who never have the need for remote access capabilities. Implementing corporate policies that define the acceptable usage of modems within the corporate network.
Designing Security for Dial-Up Connections Authenticating and Permitting Remote Access Authorizing Remote Access Connections Using Remote Access Policies Selecting a Remote Access Policy Model Supporting Windows NT 4.0–based Remote Access Servers Defining Standard Dial-Up Security Settings
To provide dial-up networking capabilities to remote users, organizations must install and maintain communication devices, such as modems and remote access servers. Windows 2000 provides a number of features for securing these devices. By using these features, you can provide secure access for dial-up connections.
To design a secure network for dial-up connections, you need to: Determine the methods of authenticating and permitting remote access. Determine the methods for authorizing remote access connections. Use remote access policies for administering remote access security. Select a remote access policy. Support the use of Microsoft Windows NT® version 4.0- based remote access servers. Define standard configuration settings for dial-up users.
Authentication guarantees that the user attempting a dial-up connection has been authorized to access the network from a remote location. Remote access permissions are used to specify whether the user is permitted to use a remote access connection to access the network. You can use Windows 2000 to configure an appropriate authentication method and security options, depending on the required level of security.
Authenticating Remote Access Users There are several ways in which you can authenticate remote access users on your network, including the use of smart cards and remote access authentication protocols.
Smart Cards Smart cards provide a secure means of user authentication and logon capabilities for dial-up users. To be authenticated, the user inserts the smart card into a smart card reader attached to the dial-up client.
Authentication Protocols Windows 2000 supports several different authentication protocols for dial-up users. You select the protocols according to the type of operating system that the dial- up client uses, and by the level of security that the dial- up client requires.
The following table describes the authentication protocols and their encryption levels ProtocolSupports Encryption Level Microsoft Challenge Handshake Authentication Protocol (MSCHAP). Uses challenge response authentication. All Windows-based operating systems for VPN and dial-up connections. Medium Microsoft Challenge Handshake Authentication Protocol version 2 (MS- CHAP v2). Uses stronger data encryption keys and different encryption keys for sending and receiving. All Windows-based operating systems for VPN connections. Windows 2000 and Windows NT operating systems for dial-up connections. High CHAP Uses industry-standard Message Digest 5 (MD5). All Microsoft-based operating systems and many non-Microsoft- based operating systems. Medium Extensible Authentication Protocol (EAP). Supports a framework for highly secure authentication plug-in components. Windows 2000 operating systems and some non-Microsoft-based operating systems. High Password Authentication Protocol (PAP).Uses plain text passwords. All Microsoft-based operating systems and many non-Microsoft- based operating systems Low
Permitting Access to Remote Users You can specify configuration settings for permitting and controlling remote access. You can specify dial-up permissions to control which users are permitted dial- up access to your network. You can also use remote access lockout to control access.
Dial-Up Permissions In a domain environment, you can grant permissions by modifying the domain user's account in the Dial-in tab of the User Properties box. On a stand-alone remote access server, you can grant permissions by modifying the user's account on the local server.
Remote Access Account Lockout Account lockout is a security feature that denies remote access to a user account after a pre-configured number of failed password attempts. Account lockout is designed to help prevent dictionary attacks. Account lockout is disabled by default. Note: To configure the remote access account lockout feature, you must change the settings in the Windows 2000 registry on the server that provides authentication. For more information, see remote access account lockout in the Windows 2000 Help files.
If your organization requires security levels beyond the standard authentication methods, you can use Windows 2000 remote dial-up authorization features. These authorization features must be supported by the telephone system that the caller uses, the telephone system between the caller and the remote access server, and all communications hardware used to complete the call.
ANI/CLI Use Automatic Number Identification/Calling Line Identification (ANI/CLI) when you want to restrict the telephone number that the dial-up client must use when dialing in to the remote access server. ANI/CLI uses the dial-up user's telephone number to authenticate the user's connection. If the user does not call from the specific telephone number, the connection attempt is rejected. Note: ANI/CLI is often referred to as caller ID security.
Callback Use the callback feature when the telephone system does not support ANI/CLI, or when you do not want the dial-up user to be responsible for telephone charges. Use callback with a pre-defined telephone number when you want to restrict the telephone number that a dial-up client can use to connect to the remote access server. Because callback telephone numbers can be logged, use callback with user-specified telephone numbers when you want to identify the telephone numbers used to make a connection. When using callback, the remote access server disconnects the telephone call and then calls back the remote access client on a negotiated or pre- assigned callback number. Warning: Using call forwarding can circumvent callback security. Even though the callback is sent to a pre-configured telephone number, that telephone number can be call forwarded to an unapproved telephone number.
DNIS Use Dialed Number Identification Service (DNIS) when you provide multiple telephone lines for your dial-up users, and you want to apply remote access policies that are based on the telephone number dialed. You can use DNIS in situations in which you want to assign different remote access policies to specific classes of users. The remote access server can authorize the connection and assigned remote access policy based on the telephone number that the dial-up user dialed. The telephone system must support the DNIS.
Third-Party Security Host Use a third-party security host when you want to augment the security that a remote access server provides. Frequently, a security host is a device that is located between the dial-up modem and the remote access server. For example, a security host can require that a dial-up user have a security card to be authenticated. The security card provides authentication by generating an access code that changes each time the user connects. Changing the access code with each use prevents an unauthorized user from intercepting and re-using a given code.
Using Remote Access Policies Remote Access Client Remote Access Policy Remote Access Server Permit Access to Specific Groups Define Days and Times Configure Authentication Methods Configure Encryption Settings Specify Maximum Session Times Restrict Subnets
You can use remote access policies to disallow connections that do not meet your organization's requirements for authentication, encryption, or any other connection conditions. Remote access policies provide you with precise control when configuring the security of dial-up connections, because you can use them to specify connection authorization conditions and restrictions.
You can use multiple remote access policies to apply different sets of conditions to different classes of remote access clients. You can also use remote access policies so that different requirements can be applied to the same remote access client, based on the parameters of the connection attempt.
You can use remote access policies to: Allow or deny connections if the user account belongs to a specific group. Define different days and times for different user accounts based on group membership. Configure different authentication methods for dial-up and VPN remote access clients. Configure different authentication or encryption settings for Point- to-Point Tunneling Protocol (PPTP) or Layer Two Tunneling Protocol (L2TP) connections. Configure different maximum session times for different user accounts based on group membership. Apply IP filters to limit the subnets that a remote user can access.
Selecting a Remote Access Policy Model Access by User Access by Policy in a Windows 2000 Native-mode Domain Access by Policy in a Windows 2000 Mixed-mode Domain
Selecting a Remote Access Policy Model Windows 2000 provides three different remote access policy models for administering remote access permissions and connection settings. Which model you select will depend on your requirements for administering dial-up permissions and the configuration of your Active Directory™ directory service domain.
Access by User In the access by user administrative model, the dial-in permission on the user account determines remote access permissions. You enable or disable remote access permission on a per-user basis by setting the user's dial-in permissions to either allow access or deny access. The remote access permission setting on the remote access policy is ignored if the user's remote access permission is set to either allow access or deny access. Even though the permission settings in remote access policies are ignored, you can still use remote access policy conditions and profile properties to enforce connection settings, such as encryption settings.
Access by Policy in a Windows 2000 Native-mode Domain In the access by policy administrative model for a Windows 2000 native-mode domain, you use the remote access permission setting on the remote access policy as the determining factor to allow or deny remote access. You configure access by policy by setting every user account to Control access through remote access policy.
Access by Policy in a Windows 2000 Mixed-mode Domain In the access by policy administrative model for a Windows 2000 mixed-mode domain, remote access permissions are granted if the properties of a connection match a remote access policy. In a Windows 2000-based remote access server that is a member of a mixed-mode domain, the Control access through remote access policy option is not available. In this case, if a connection attempt matches the conditions of a policy, the connection is accepted. To use this model, you must: Set the remote access permission on every user account to Allow access. Delete the default remote access policy. Create separate remote access policies and define the types of connections that are allowed.
Supporting Windows NT 4.0–based Remote Access Servers Null Session Pre-Windows Compatible Access Remote Access Client Windows NT 4.0 Remote Access Server Windows 2000 Domain Controller Everyone Server Uses Null Session Add Everyone to Pre-Windows Compatible Access Security Group
When your network includes Windows NT 4.0-based remote access servers that are not backup domain controllers, these servers will retrieve the domain user's dial-up properties by using a NULL session to connect to a Windows 2000 domain controller. A NULL session is a connection that does not require a user name or password. A NULL session requires that default Windows 2000 permissions be reduced to allow the Windows NT 4.0-based remote access servers to connect. Reducing the permissions can potentially weaken access security on the domain controller. Note: Windows NT 4.0-based remote access servers that are domain controllers have a local copy of the domain database, and therefore do not connect by using a NULL session.
To support the Windows NT 4.0-based remote access servers, you must set the Permissions compatible with pre-Windows 2000 server option. You can set this option during the installation of Active Directory by using the Active Directory Installation wizard. This option adds the Everyone group to the local group named Pre-Windows 2000 Compatible Access. Important: The Permissions compatible with pre- Windows 2000 server option allows full access to certain Active Directory objects. Use this option only after evaluating its impact on your Active Directory security. As an alternative to this option, consider upgrading the remote access servers to Windows 2000.
When you want to simplify the configuration of security settings for a large number of remote access users, you can use the Connection Manager Administration Kit (CMAK). You can use CMAK to define a highly secure configuration for remote access users, and it eliminates the need for the user to determine the appropriate security settings for the connection. You can create separate packages for specific types of connection, such as dial-up user and VPN connections.
You can use CMAK to create a distributable Connection Manager package that contains preset security options, such as: Single Sign-On. Enables a user to log on to both an Internet service provider (ISP) and your organization's network by using a single user name and password. Automatic VPN Connection. Configures the client to automatically start a VPN connection after a dial-up connection is established. Preset Security Configuration. Configures additional security settings, such as the appropriate authentication protocol and encryption level for dial-up and VPN connections. Disconnect Options. Configures the client to disconnect from the network after a specified amount of idle time has passed. Connection Phonebook. Provides the client with a list of a telephone numbers that can be used to dial in to the network. Note: For more information on CMAK, see the Windows 2000 Help files and the Windows 2000 Server Resource Kit.
Designing Security for VPN Connections Identifying Benefits of VPN Connections Selecting a Tunneling Protocol
VPN connections enable remote access clients to securely connect to a network. VPN connections provide secure authentication and data encryption. Remote users can establish a VPN connection by either dialing in to a network or by using a dedicated connection.
When planning VPN connections for remote access clients, you must: Identify the benefits of using VPN connections. Select the appropriate tunneling protocol to secure a VPN connection.
Identifying Benefits of VPN Connections Tunnel Outsourced Dial-Up Support Reduced Telephone Charges Increased Connection Speed ISP ISP Internet Internal Network
When a VPN connection is established, a tunnel is created between the remote access client and the remote access server. Typically, a remote access client dials in to a local ISP and then establishes a VPN connection to the organization's network. The benefits of using VPN connections established through a local ISP include: Outsourced dial-up support. The ISP is responsible for providing and maintaining all modems and Internet connections. Reduced telephone charges. Because the user connects to the Internet through a local ISP, no long-distance charges are incurred. Increased connection speed. Technologies available to home users, such as a digital subscriber line (DSL) and cable modems, provide faster methods for accessing private networks.
Selecting a Tunneling ProtocolRequirementsRequirements Tunneling Protocol PPTP L2TP/IPSec Computer Authentication Multi-Protocol Support X X X X X X Strong Security X X Non-Windows 2000 Client Support X X Network Address Translation Support X X
Selecting a Tunneling Protocol PPTP and Layer Two Tunneling Protocol over Internet Protocol Security (L2TP/IPSec) are two standard, interoperable authentication and encryption protocols. VPN connections use these protocols to protect data that is transmitted over public or private networks. You select one of these tunneling protocols based on the type of remote access clients and servers used and the level of security required to protect the data.
PPTP PPTP tunnels use Microsoft Point-to-Point Encryption (MPPE) to encrypt transmitted data. MPPE can use 40- bit, 56-bit, or 128-bit encryption keys. The 40-bit key provides compatibility with client computers that are running earlier Microsoft operating systems than Windows 2000.
Specify PPTP for the VPN connection when: Data transmissions must pass through a network address translation (NAT) server. Remote access clients run Windows NT 4.0 or Microsoft Windows 98. Network routers do not support L2TP/IPSec. User-based authentication is sufficient, and you do not require the added security of computer-based authentication. A computer-based certificate infrastructure, such as Kerberos version 5 or Public Key Infrastructure (PKI), does not exist. Note: 128-bit encryption is subject to import and export laws that can vary by country. For more information, refer to your country's regulations on the import and distribution of encryption technologies.
L2TP over IPSec L2TP tunnels can use L2TP/IPSec protocols to encrypt transmitted data. IPSec can use 40-bit Data Encryption Standard (DES), 56-bit DES, or Triple DES (3DES) encryption algorithms. IPSec can use Kerberos V5 authentication, public key certificates, or a secret shared key to establish a secure connection between two computers.
Specify L2TP/IPSec for the VPN connection when: You need stronger security than PPTP provides. You require the added security of computer-based authentication. Note: 3DES provides the strongest level of security; however, using this encryption algorithm can increase the processing requirements for all computers that are configured to 3DES. 3DES is subject to the same import and export laws as 128-bit encryption. For more information, refer to your country's regulations on the import and distribution of encryption technologies.
Centralizing Remote Access Security Settings Using RADIUS Providing Single Sign-On Capability Centralizing Remote Access Policies Centralizing Auditing and Accounting
Windows 2000 supports centralized security configuration for multiple remote access servers by using the industry-standard Remote Authentication Dial- In User Service (RADIUS) protocol. RADIUS can be used for centralizing authentication, authorization, and accounting for dial-up and VPN connections. RADIUS can be used in conjunction with Active Directory to provide users with single sign-on. To ensure consistent security configurations, you can enforce security settings by using remote access policies. You can centralize these policies so that they are consistent across all remote access servers in your organization. You can also centralize auditing and accounting, which will allow you to monitor security and usage information for remote access connections.
In this lesson you will learn about the following topics: Using RADIUS Providing single sign-on capability Centralizing remote access policies Centralizing auditing and accounting
Using RADIUS Radius Client (Remote Access Server) Radius Server (IAS) Dial-Up Clients Authentication, authorization, and accounting Receives authentication requests Radius Server (IAS) Radius Proxy Forwards authentication requests to appropriate RADIUS server
You use a RADIUS server to centralize authentication, and to allow users to connect to your organization with an ISP that uses single sign-on. You can install and configure a RADIUS server by installing the Internet Authentication Service (IAS) on a remote access server.
A RADIUS environment consists of: A RADIUS server A RADIUS client Dial-up client A RADIUS proxy
A RADIUS server A server that provides remote access user authentication, authorization, and accounting data maintained in a central location rather than on each network access server. The IAS in Windows 2000 is the Microsoft implementation of the RADIUS server.
A RADIUS client A network access server (NAS) that receives RADIUS authentication requests from remote access clients and forwards them to a RADIUS server. Routing and Remote Access in Windows 2000 can be configured as a RADIUS client.
Dial-up client A remote access client that uses dial-up or VPN connections to access the network.
A RADIUS proxy A service that forwards RADIUS authentication requests to an appropriate RADIUS server. For example, if an ISP is receiving authentication requests from more than one organization, the RADIUS proxy can forward RADIUS requests to the appropriate organization's RADIUS server, based on the domain name that the organization uses.
Providing Single Sign-On Capability Remote Access Server Dial-Up Client Domain Controller IAS ISP’s NAS ISP’s RADIUS Proxy Dial-Up Client
One of the advantages of using RADIUS for authentication is that you can provide single sign-on capabilities to your remote access clients. Single sign- on enables the remote access user to supply a single set of credentials, which both the ISP and Active Directory can use to authenticate the user.
The RADIUS client forwards authentication requests to the RADIUS server. The RADIUS client can be a remote access server connected to the network, or a remote access server that an ISP maintains.
When implementing RADIUS to provide secure single sign-on capabilities for remote access, you must: Ensure that the strongest possible method of authentication is used between a RADIUS client and a RADIUS server. Enable remote access account lockout to limit the number of failed password attempts allowed before dial- up access is revoked. Ensure that your ISP uses a RADIUS proxy to forward RADIUS authentication requests to your RADIUS Note: Windows 2000 does not provide RADIUS proxy service. For RADIUS proxy capabilities, you will need to use a third-party RADIUS server.
You can centralize the management of remote access policies to enforce the configuration of the required security settings on all remote access servers. Centralizing remote access policies eliminates the need to configure each individual remote access server and ensures that a single set of remote access policies is used.
You can centralize remote access policies by: Configuring a Windows 2000-based server as an IAS server. Creating the central set of policies on the IAS server. Configuring each remote access server as a RADIUS client to the IAS server.
The RADIUS client will be configured with the policies on the RADIUS server; any local remote access policies will no longer be used. Note: You can still configure local policies on the remote access server, when the server is configured as a RADIUS client, however, these policies will be ignored.
Centralizing Auditing and Accounting IAS IAS Log Remote Access Servers Auditing and Accounting Information
You can centralize auditing and accounting information to eliminate the need to collect the information from each remote access server. You configure centralized auditing and accounting by configuring all of the remote access servers to forward the information to a log file on the IAS server. The auditing information includes information, such as all authentications that have been accepted and rejected. The accounting information includes usage information, such as all logon and logoff records. Tip: In some situations, you may not want to centralize auditing and accounting. For example, if your remote access servers are separated from the IAS server over a low-bandwidth connection, you may prefer to periodically retrieve the information from the remote access servers.
Lab A: Using RADIUS Authentication
Objectives After completing this lab, you will be able to: Plan security configuration for remote access by using RADIUS. Plan the appropriate tunneling protocol to be used for a given scenario.
Prerequisites Before working on this lab, you must have: Knowledge of how RADIUS is used to authenticate dial- up clients. Knowledge of how to install a Terminal Client, IAS, and Routing and Remote Access.
Scenario Contoso, Ltd., a multimedia game developer located in Melbourne, Australia, has several employees who work remotely from client offices. Contoso, Ltd. wants these employees to connect to the Internet by using the same credentials that they use to access the Contoso, Ltd. Windows 2000 network.
Exercise 1: Designing a Remote Access Solution for Contoso, Ltd. Goal In this exercise, you will design a remote access solution for Contoso, Ltd. that will provide secure dial- up network access for remote employees.
Scenario Contoso, Ltd. wants to provide remote access to the corporate network for employees who work at client sites or from home offices. Corporate headquarters are located in Melbourne, Australia, but employees work from client sites worldwide. The remote access solution must meet the following requirements: Reduce long-distance charges associated with connecting to the corporate network by having users dial up to a local ISP. Support both direct connected Internet users and dial-up users. Have users connect to the Internet by providing the same credentials that they use to connect to the corporate network. Centralize management of remote access security in the central Information Technology (IT) department in Melbourne.
Exercise 2: Installing the Dial-up Client Scenario Each computer used for remote access by a Contoso, Ltd. employee requires a Network and Dial-up Connection to connect to the Internet.
Goal In this exercise, a dial-up connection will be configured at the dial-up client computer. This dial-up connection will connect to the IP address of the dial-up server. Online Demo
Exercise 3: Configuring the Internet Authentication Service Scenario Contoso, Ltd. wants to manage all remote access to the network from its centralized IT department in Melbourne, Australia, thereby ensuring that a consistent remote access policy is applied to all users who remotely connect to the network.
Goal In this exercise, the dial-up client computer will use Terminal Services to configure the dial-up server as a RADIUS client of the Melbourne IAS server. Online Demo
Exercise 4: Installing Routing and Remote Access Service Scenario The ISP must configure its NASs to function as RADIUS clients of the Melbourne RADIUS server. This configuration is required to ensure that Contoso, Ltd. remote users can access the Internet by using their Contoso, Ltd. network credentials.
Goal In this exercise, you will configure the VPN server as a RADIUS client of the Melbourne server. Online Simulation
Exercise 5: Authenticating a Dial-up Connection Using RADIUS Goal In this exercise, the remote access configuration will be tested to ensure that the dial-up client can connect to the VPN server by using credentials from a different forest. Online Demo
Exercise 6: Centralizing Management of Remote Access Policy Scenario Due to a computer virus attack at Contoso, Ltd.'s headquarters, all remote access to the network must be temporarily stopped.
Goal In this exercise, all remote access connections will be prevented to allow the dial-up clients to attempt to reconnect to the VPN server. Online Demo
Exercise 7: Disabling Routing and Remote Access Scenario The ISP has decided to redeploy the NAS at your location. You must disable Routing and Remote Access for the server before taking the server offline.
Goal In this exercise, Routing and Remote Access will be disabled on the server. Online Demo