Objective 3.3: Designing User Authentication for IIS

Microsoft has done a great job of redesigning IIS to be more reliable and robust. Perhaps the most significant modification is the emphasis on the worker process model . This concept was initially embedded into IIS 4.0 as Running an application in a separate memory space. Let s investigate these modifications in detail.

IIS separates all user code from its WWW service. The user application (different Web sites) functions as a separate Internet Server Application Programming Interface (ISAPI) application. The separate ISAPI workspace is referred as a worker process . IIS 5.0 used to run each Web site within its own inetinfo.exe memory space (inetinfo.exe is the application that implements IIS 5.0). IIS 6.0 worker process Web sites do not run within the inetinfo.exe (WWW services) memory space. Since the worker process runs in an isolated environment from the WWW service, an error in the Web site application code (or malicious attack) will not cause the Web server to shut down. The worker process can also be configured to run on a specified CPU. The worker process model can store application-specific data in its own memory space. IIS 5.0 stored all the application data within the inetinfo.exe memory space. Therefore, we can assign a Web site to run on specific CPUs. This mechanism will enable us to dedicate more resources to popular Web sites. (These resources for a Web site can be bundled as an application pool .) The IIS Web request process is illustrated in Figure 6.1.

Figure 6.1: IIS 6.0 Worker Process Model

The Web request from the user is met by the HTTP listener. This HTTP request listener is referred to as HTTP.Sys. HTTP.Sys analyzes the request and validates authentication on it. An error message will be sent to the user if the request is invalid by HTTP.Sys. The request is passed to Inetinfo.exe or SVCHost.exe if the request is valid. Inetinfo.exe will handle all FTP, NNTP, SMTP, and IIS Admin requests . The

SVCHost.exe will handle all the WWW requests. Both InetInfo.exe and SVCHost.exe will communicate with the metabase to process requests. (The metabase is an XML repository that will hold the configuration settings for the IIS 6.0 server.) All the requests are queued to be processed by a Web site. There are different queues for each worker process. IIS 6.0 will create a new W3wp.exe instance as a worker process if the request refers to new data. All the existing Web sites will have worker processes assign to them. Each worker process will have an application pool for resource management. The request will be processed by one of the worker process models. The response will be channeled by the worker process through either Intetinfo.exe or SVCHost.exe to the user.

Head of the Class
Is the Worker Process Model the Same as IIS 5.0 Isolation Mode?

IIS 6.0 runs the worker process model by default. You can also configure IIS 6.0 to run in IIS 5.0 isolation mode . The worker process model is more flexible than the IIS 5.0 isolation model. The worker process can isolate individual sites, which will minimize the risk of a malicious attack on the WWW service. IIS 5.0 isolation mode still runs within the inetinfo.exe memory space, so an error in the application can bring down the whole server (WWW, NNTP, FTP, and SMTP services). The IIS 5.0 architecture is illustrated in Figure 6.2.

Figure 6.2: IIS 5.0 Isolation Model

This model is similar to the IIS 6.0 model, but less scalable. The incoming requests are met by HTTP.Sys. (HTTP.Sys is a user mode element in IIS 5.0. It is a kernel mode element in IIS 6.0.) HTTP.Sys will forward the request to Inetinfoe.exe. Inetinfo.exe will handle all WWW, FTP, NNTP, and SMTP calls in IIS 5.0. Inetinfo.exe will communicate with the metabase to facilitate the execution of the Web request. (The metabase in IIS 5.0 is implemented as a binary executable. The IIS 6.0 metabase is XML driven.) This will forward all the requests to a single queue. (This is a notable difference in IIS 6.0. IIS 6.0 will have multiple queues for multiple Web sites.) Each Web site will run as an ISAPI extension under DllHost.exe. The generic queue will forward the correct request to the appropriate ISAPI application to process the contents.

IIS 5.0 used ASP as the default scripting mechanism; IIS 6.0 uses ASP.NET. IIS 6.0 can run ASP, and all the code should run smoothly in an upgrade from IIS 5.0 to IIS 6.0. If the ASP code is not compatible, you might have to revert to IIS 5.0 isolation mode.

In Windows Server 2003, the HTTP stack is implemented as a kernel mode device driver called HTTP.Sys. All incoming HTTP traffic goes through this kernel process. This kernel process is independent of an application process. IIS 6.0 is an application process and external to HTTP.Sys (application processes run in user mode , and the operating system functions are run in kernel mode ). HTTP.Sys is responsible for the following: connection management (managing the database connections from the ASP.NET pages to databases), caching (reading from a static cache as opposed to recompiling the ASP.NET page), bandwidth throttling (limiting the size of the Web requests to a Web site), and text-based logging (writing IIS information into a text log file).

In IIS 5.0, the HTTP request was consumed by the IIS inetinfo.exe (the incoming HTTP requests were first analyzed by inetinfo.exe process). HTTP.Sys in IIS 6.0 relieves IIS of this responsibility. In doing so, it enhances IIS performance in the following ways:

HTTP.Sys enables caching (referred as flexible caching ) at the kernel level so that static data can be cached for faster response time (independent of the user mode caching). This will be faster than user mode caching. We need to be careful with flexible caching. Since HTTP.Sys is separate from IIS, we can still cache old data after an IIS restart.
HTTP.Sys introduces a mapping concept called application pooling . Application pooling allows Web sites to run together in one or more processes, as long as they share the same pool designation. Web sites that are assigned different application pools never run in the same process. A central
Web site (credit card verification Web site) can be accessed by all the other miscellaneous sites (shopping cart e-commerce sites) by using this method. By using the correct application pool information, HTTP.Sys can route the HTTP traffic to the correct Web site.
HTTP.Sys increases the number of Web sites you can host using the application pool concept. This architecture also increases performance and more controlled access to valuable IIS resources.

Objective 3.3.1: Designing Certificate Authentication

Certificates are a proven mechanism to authenticate users in IIS 6.0. A certificate is a digital fingerprint for a user or for a number of users. This digital fingerprint will provide access information of the user to IIS 6.0. The certificate management is a part of the Secure Sockets Layer (SSL) in IIS. SSL will manage the encrypted communication between the client and the server. The certificate information need to be verified by a Windows user account, a process is referred to as mapping . There are three ways to map a certificate to a Windows user account: Directory Service mapping, one-to-one mapping, and many-to-one mapping. These three mechanisms provide a very flexible certificate mapping mechanism in Windows Server 2003. We are able to map multiple users to single certificate information (using wildcards), and a number of certificates to the same user by using the mapping mechanisms. Let s look at them in more detail.

Directory Service Mapping

Directory Service (DS) mapping uses native Windows Active Directory Service to authenticate users. This is the least popular of the three mapping methods , because of the necessity of an Active Directory and this mechanism does not bring the third-party security vendor support that comes with other certificate mappings. The user will feel more comfortable with VeriSign-issued certificates as opposed to an internal Active Directory user account of the enterprise. (VeriSign is a reputed certificate vendor. Their certificates are used on multiple platforms in various e-commerce implementations. The general public will feel secure dealing with a trusted third party like VeriSign.) DS mapping information is shared across all IIS servers; therefore, we do not need to replicate them in each server. However, it is not as flexible as other methods to perform wildcard matching. We need to be a member of a Windows domain to apply DS mapping. This mapping will suit us best if we want to integrate our Web sites as an intranet within the enterprise. We will not be able to implement one-to-one or many-to-one mapping if we proceed with a DS mapping. This mapping is used in large-scale implementations for internal data sharing.

One-to-One Mapping

One-to-one mapping compares the user certificate to the one stored on the server. The client browser sends the user certificate to the IIS 6.0. The certificate details need to match exactly to proceed with authentication. The server needs to be updated with the new certificate information if the user decides to get a new certificate. This mechanism suits smaller implementations or a small set of users who will have access to sensitive data. One-to-one mapping provides higher security than the other two mappings do. Certificate revocation and usage can be closely monitored in this mapping mechanism. Exercise 6.01 shows us how to implement one-to-one mapping in IIS 6.0.

Exercise 6.01: Implementing One-to-One Mapping

Navigate to Start Administrative Tools IIS Manager .
Select Web Sites and then Default Web site . We will use this Web site for demonstration purposes.
Right-click on the Default Web site and select Properties . Navigate to the Directory Security tab. Your screen should be similar to Figure 6.3.

Figure 6.3: Directory Security Tab of IIS 6.0
Click the Edit button in the Secure communications box. Your screen should be similar to Figure 6.4.

Figure 6.4: Enable Secure Communication
Click the Enable client certificate mapping option box and click the Edit button. You should be presented with the Account Mapping screen (see Figure 6.5). Select the 1-to-1 tab. You can view the existing certificate mappings (it is not a good practice to map a certificate using the Administrator account). You can select these existing mappings and the details will appear in the Subject and Issuer group boxes.
Click the Add button and you will be presented with the dialog box to navigate to the certificate. Select the certificate and click the Open button. You will be asked to enter the credentials to add the mapping. It is good practice to use an account with fewer privileges. We are trying to create a mapping to the IIS 6.0 server; therefore, we will use the IUSR_ComputerName account in this case. (The machine name is DEVSRV2; therefore, the account will be IUSR_DEVSVR2.) Your screen should be similar to Figure 6.6. Click OK to return to the Account Mapping screen.

Figure 6.5: One-to-One Mapping Screen
Click Apply button to apply the certificate mappings.

Many-to-One Mapping

Many-to-many matching does not compare the complete certificate information; it only compares specific information (for example, the issuer or the subject) using wildcards. Therefore, the user certificate information does not need to match exactly to proceed with authentication. It only needs to adhere to certain criteria set by the enterprise domain administrators. The users will be able to authenticate even if they update their certificates (provided that they do not alter the wildcard criteria). Many-to-one mapping is popular with large-scale implementations. We can create one or more matching rules to correspond to one or more Windows accounts. Administration of the mapping process is also easier compared to the other two.

Many-to-many implementations can also be used to leverage the IIS 6.0 anonymous IUSR_ComputerName account. The entire pool of certificates can be matched with wildcards to the IUSR_ComputerName account to be authenticated. This mechanism can also be used on certificates issued by certificate authorities (CAs). We can define rules that will seamlessly map the certificate information to user accounts in this way. Let s look at the many-to-many mapping process in Windows Server 2003 IIS 6.0.

Figure 6.6: Select Credentials for Mapping

Exercise 6.02: Implement Many-to-One Mapping

Follow steps 1 through 5 in Exercise 6.01.
Select the Many-to-1 tab from the Account Mapping screen. Make sure the Enable wildcard client certificate matching option box is checked. You can also see the existing mapping in this screen. Click the Add button to create a new many-to-one mapping. Your screen should be similar to Figure 6.7.

Figure 6.7: Add a Wildcard Rule
Enter a name for the new rule in the text box. We will enter New Demo wildcard rule for demonstration purposes. Click the Next button to navigate to Figure 6.8.

Figure 6.8: The Rules Window
Click the New button to create a new rule. You will be presented with Figure 6.9 to configure the rule.

Figure 6.9: Enter Rule Information
This screen will let you define the rule. We will try to define a rule that will inspect the Subject field of the certificate to inspect the contents of the organization sub field. We will enter the wildcard Micro* as the filter. Therefore, any Microsoft certificate will be able to authenticate using this setting. Click the OK button when finished. You will be asked to enter the credentials for the mapping. We will use the same IUSR_DEVSVR2 account in this exercise. Your screen should be similar to Figure 6.10.

Figure 6.10: Enter Credentials for Many-to-One Mapping
Click the Finish button to end the wizard and apply the changes.

This process will implement an IIS 6.0 certificate authorization on IIS 6.0 server. The client browser will be equipped to handle this authorization mechanism. (All the major browsers are capable of handling certificates and they are built in to the browser functionalities.) This client browser will communicate with the server to provide the certificate information to be validated by the IIS 6.0 server. This process is detailed in Chapter 10 Securing Network Clients .

Objective 3.3.2: Designing Windows Logon Authentication

There are several Windows logon authentication mechanisms available in Windows Server 2003. Windows accounts can be used to authenticate users to gain access to Web and FTP content. These authentication methods are anonymous access, basic authentication, digest authentication, and Windows integrated authentication. Let s look at each in detail.

Anonymous Authentication

The anonymous authentication method is the least secure of the Windows Server 2003 authentication options, and is used on Web content that does not require any security (the content is available for public consumption). We do not need to provide credentials to view Web content using this authentication. Therefore, IIS 6.0 will provide public access to Web and FTP sites without prompting for a username or a password.

IIS 6.0 impersonates a user account to assign a connection. This user account is automatically created at the installation. The name format for this account is IUSR_ComputerNam e (for example, if the server name is devsvr01, the account will be IUSR_devsvr01). The account is added to the Guest user group at installation. Therefore, NTFS account permissions can be configured on the Guest group to protect the IIS server. Let s see how to enable anonymous authentication on IIS 6.0.

Exercise 6.03: Configure Anonymous Authentication

Open IIS Manager ( Start All Programs Administrative Tools IIS Manager ).
Navigate to the correct Web site and right-click on Properties . We will choose the Default Web Site for demonstration purposes.
Select the Directory Security tab.
Click the Edit button of the Authentication and access control group box.
Select the Enable anonymous access option from the Authentication Methods window. We can also change the anonymous account by clicking the Browse button. The screen should be similar to Figure 6.11.

Figure 6.11: Enable Anonymous Access

We are using a machine called devsvr01; therefore, the default anonymous account is IUSR_DEVSVR01.

IIS 6.0 will impersonate the IUSR_ComputerName account when a request is received. IIS 6.0 is aware of this account and its password (since it was automatically generated during installation). IIS will inquire about the NTFS permissions on the IUSR_ComputerName account before any code is executed. The code will be executed if the permissions are granted. IIS will prompt the user to try another authentication method if the permissions are denied. If no other authentication method is configured, IIS will return an HTTP 403 Access Denied error.

Test Day Tip

You can enable multiple authentication options on a Web site. However, anonymous access will be executed before the other authentication methods. We can alter the account for anonymous access at the Web server level or at the virtual directory level. (The default account is IUSR_ComputerName. This can be changed to any account you prefer.) We do not need to have logon locally access in Windows Server 2003. The default logon type in IIS 6.0 is clear text. (We need to have logon locally access in previous IIS versions.) Therefore, the username and password will be communicated using clear text. You can also change the permissions of the IUSR_ComputerName account using the Group Policy Manager Microsoft Management Console (MMC).

Head of the Class...
Sub-Authentication Component

The sub-authentication component was used in IIS 5.0 to manage the passwords of anonymous accounts. This was a security risk in IIS 5.0. An intruder can gain access to the sub-authentication component and modify the passwords. This will have an adverse effect on the Web servers. IIS 6.0 on Windows Server 2003 does not configure the sub-authentication account by default. This will protect IIS 6.0 from intruders modifying the passwords. We need to apply the following steps to configure the sub-authentication component.

Register the sub-authentication component (use a command prompt window and type rundll32 %windir%\system32\iissuba.dll,RegisterIISSUBA ).
All worker processes that uses anonymous authentication should run as LocalSystem . (The worker process uses the LocalSystem account to communicate with the operating system. The user impersonates the IUSR_ComputerName account to communicate with IIS 6.0.)
The Metabase property AnonymousPasswordSyn should be set to true . This could be done by editing the metabase XML file.

Basic Authentication

Basic authentication is widely used by all Web servers. The browser will request the user s username and password. The user will enter the details into the Web browser. The collection of username and password details is referred to as credentials . The Web browser will send the credentials to the Web server to authenticate. The credentials will be base-64 encoded before they are sent to the Web servers, and are not encrypted. Therefore, anyone snooping into the network can obtain these details.

The credentials should match to a Windows account on the Web server. A connection will be established if the credentials are authenticated. The user will be allowed three attempts to connect. An error message will be displayed if the user exceeds three attempts.

Basic authentication is included in the HTTP specification; therefore, it is supported by most browsers. This has a wider appeal than integrated and digest authentication. The only issue is the insecure transmission of the credentials. An intruder can easily intercept the communication and obtain the username and password. The remedy for this is the application of SSL; therefore, the Web browser and the Web server should exchange the basic authentication credentials over an SSL connection. Exercise 6.04 shows us how to configure basic authentication.

Exercise 6.04: Configure Basic Authentication

Open IIS Manager and navigate to the Authentication Methods window (refer to steps 1 through 4 in Exercise 6.03).
Select the Basic authentication (password is sent in clear text) option. You will get a warning to illustrate the limitations of basic authentication. The screen will be similar to Figure 6.12. Click Yes to proceed.

Figure 6.12: Basic Authentication Warning
Type the domain name of the network to which you are attached. We can also select the domain by clicking the Select button. The current IIS domain name will be taken if the field is kept empty. We will use MyDomain for demonstration purposes.
You can also configure an optional Realm property. This will appear in the browser window when the user tries to authenticate. We will enter test Realm for demonstration purposes. The screen should be similar to Figure 6.13.

Figure 6.13: Basic Authentication Settings

Digest Authentication

Digest authentication is similar to basic authentication. The limitation of basic authentication is that the transportation of the credentials as clear text. Digest authentication overcomes this issue by having MD5 hashed encrypted credentials. This MD5 hash or Message Digest cannot be deciphered from the hash. Digest authentication is only available on directories that support WebDAV (Web Distributed Authoring and Versioning). Exercise 6.05 illustrates how to enable digest authentication on IIS 6.0.

Exercise 6.05: Configure Digest Authentication

Open IIS Manager and navigate to the Authentication Methods window (refer to steps 1 through 4 in Exercise 6.03).
Select the Digest Authentication for Windows domain servers option. You will be informed about the Active Directory involvement in digest authentication. The screen will be similar to Figure 6.14. Click Yes to proceed.

Figure 6.14: Digest Authentication Warning
You can also configure an optional Realm property. This will appear in the browser window when the user tries to authenticate. We will enter test Realm for demonstration purposes. The screen should be similar to Figure 6.13 with the digest authentication option turned on.

Let s look at the digest authentication process. The user will issue a Web request to the IIS 6.0 server using Internet Explorer 5.0 or later. The IIS 6.0 server will inform the user that digest security is enabled and provide realm details. Internet Explorer will ask the user to enter the username and password details (credentials). Internet Explorer will combine the credentials and realm to create the MD5 hash.

This MD5 hash will be sent to the IIS 6.0 server. IIS 6.0 will send the MD5 hash to the domain controller (DC) for verification. The DC will refer to the Active Directory to compare the credentials and authenticate the user.

Exam Warning

There are several requirements to implement digest security. Digest security is only supported on Internet Explorer 5.0 and later. Therefore, all the client browsers in the enterprise should meet these criteria. The users also must have a valid Active Directory account to compare the credentials when we authenticate. We do not need any additional software to support digest authentication. However, digest authentication uses HTTP 1.1. Not all browsers support HTTP 1.1; therefore, non-HTTP 1.1 browsers will not be able to use digest security in Windows Server 2003.

Test Day Tip

The user and the Web server should have two trust relationships to implement digest security. (The server and the client might belong to two different networks. Therefore, the two networks need to trust each other in order for them to communicate. A two-way trust will enable both server trusting the client and client trusting the server. Therefore, information can flow both ways.) The DC should be Windows 2000 or later. We need to use the sub-authentication component of IIS 6.0 to communicate with a Windows 2000 DC. We also need to use the LocalSystem account if the IIS 6.0 server operates in worker process isolation mode.

Integrated Windows Authentication

Integrated Windows authentication is the default authentication mechanism in IIS 6.0.This was formerly called NTLM or Windows NT Challenge/Response method. Integrated Windows authentication uses a hashed algorithm to encrypt the credentials; therefore, it is a safe authentication method. It uses Kerberos V5 and NTLM authentication to implement integrated Windows authentication.

Exam Warning

NTLM and Kerberos have different features. Kerberos can pass through proxy servers; however, it is terminated by firewalls. Most corporate firewalls will stop Kerberos from entering their system. These corporate firewalls will let NTLM pass through to the system. However, NTLM is stopped at the proxy servers of the enterprise. Enterprise Web applications will not be able to use either Kerberos or NTLM. A combination of both can deliver a secure authentication mechanism, which we refer to as integrated Windows authentication . However, both the client and server need to have a trusted connection to the Key Distribution Center (KDC) and Active Directory to implement Kerberos v5.

Let s see how this authentication is implemented. The client browser does not request the username and password from the user (however, Internet Explorer 4.0 and later can be configured to request the username and password in integrated Windows authentication). The client logged on user credentials (on the client computer) are used initially. This information is passed to the IIS 6.0 server. The user is prompted to supply the credentials if the information is invalid. The user can retry the credentials until he or she is authenticated.

This authentication mechanism has its limitations. Integrated Windows authentication will not work over HTTP proxies. We also need to have Internet Explorer 2.0 or later to implement this authentication method. Therefore, it is more suited to an intranet environment that can be tightly controlled by the system administrators. Exercise 6.06 shows us how to configure IIS 6.0 to implement integrated Windows authentication.

Exercise 6.06: Configure Integrated Windows Authentication

Open IIS Manager ( Start All Programs Administrative Tools IIS Manager ).
Navigate to the correct Web site and right-click on Properties . We will choose the Default Web Site for demonstration purposes.
Select Directory Security tab.
Click the Edit button of the Authentication and access control group box.
Select Integrated Windows Authentication .

Test Day Tip

The Kerberos service needs to be registered before we use integrated Windows authentication. (Kerberos runs as a service that can be turned on and off from Control Panel of Windows Server 2003.) We should be careful with the user account under which this service runs. We need to alter the settings of the service account if the account is modified. The service must be referring to one service account object. Each application pool will use this account to implement Kerberos in IIS 6.0. Since an IIS 6.0 application pool will facilitate multiple Web sites and virtual directories, it will be difficult to isolate Web sites form each other. However, we can isolate each site at the domain name level; for example, www.stiA.com, www.siteB.com, and so forth.

Objective 3.3.3: Designing RADIUS Authentication

There are multiple network options for organizations. Technical advances enable us to use Internet, virtual private networks (VPNs), and wireless access to the same resources. These multiple implementations add another level of complexity to our enterprise. We do not want to have different authorization and authentication mechanisms to access different resources (for example, we should be able to log on to our wireless devices using our VPN credentials). The Remote Authentication Dial-In User Service (RADIUS) is a protocol that defines single sign-on access to multiple network resources. The implementation of RADIUS in Windows Server 2003 is referred to as Internet Authentication Server (IAS).

IAS in Windows Server 2003 implements a RADIUS server and a RADIUS proxy. The RADIUS server will provide centralized connection for authentication, authorization, and accounting functions for networks that include wireless access, VPN remote access, Internet access, extranet business partner access, and router-to-router connections. IAS proxy functions are different from these server functions, and includes forwarding IAS authorization and accounting information to other IAS servers. The Microsoft IAS is built on the standard RADIUS protocol specification that is published by the Internet Engineering Task Force (IETF). The RADIUS authentication as a server and a proxy is illustrated in Figure 6.15.

Figure 6.15: RADIUS Architecture in Windows Server 2003

There are several remote access methods in an enterprise: dial-in client desktops, VPN clients, and wireless devices in our demonstration. The dial-in clients will connect to a dial-in server. The VPN clients will connect to a VPN server. The wireless devices will access the network through a wireless access server. All three servers will connect to a Windows Server 2003 RADIUS IAS proxy machine. This proxy will channel the requests to the IAS server. The IAS server will communicate with the DC and the Active Directory to perform authentication duties . Let s look more closely at using the IAS server.

Using the Internet Authentication Server

IAS is installed as an optional server in Windows Server 2003, and is not installed by default. Therefore, we need to add IAS manually to our Windows Server 2003. Exercise 6.07 shows the steps to install IAS to implement RADIUS authentication on IIS 6.0.

Exercise 6.07: Install Internet Authentication Server

Navigate to Start Control Panel Add Remove Programs .
Click the Add /Remove Windows Component button.
Navigate to Network Services and click the Details button. Your screen should be similar to Figure 6.16.

Figure 6.16: Select Network Services
Select Internet Authentication Service and click OK . This screen should be similar to Figure 6.17.

Figure 6.17: Select Internet Authentication Service
The installation will start and you will be notified with an information message at the end of the setup.

These steps will install IAS on your server. The installation will add the Internet Authentication Service program item under Start Administrative Tools to navigate to the service. The service can be managed by an MMC snap-in. The IAS MMC snap-in will be similar to Figure 6.18.

Figure 6.18: IAS MMC Snap-In

The MMC snap-in supports several IAS functions. We will be able to keep track of all RADIUS clients using the RADIUS Clients snap-in item. All the logging for remote access will be documented in the Remote Access Logging snap-in item. We can also define policies under the Remote Access Policies item. These policies for remote access can be different form one enterprise to another. There are two default policies created by the installation: Connections to Microsoft routing and remote servers and Connection to other servers . We can change these policies by selecting them and double-clicking on them. Let s now investigate the policy to handle Microsoft routers and remote access. Double-click on Connections to Microsoft routing and remote access server and you will be presented with Figure 6.19.

Figure 6.19: Properties of Remote Access Policies

This screen will specify the protocol to communicate to other Microsoft servers in the enterprise. The connection to enterprise is enabled if this policy is met. We can also edit the policy by clicking the Edit Profile button. The screen should be similar to Figure 6.20.

Windows Server 2003 s IAS server is highly configurable for remote access policy. We can configure the policy on dial-in connection properties. We can restrict access according to time and session length. We can also restrict the port times that remote access is granted (for example, Token Ring or wireless access). We can use the IP tab of the Dial-in Profile window to restrict machine access by IP address. We can also grant or deny encryption algorithms by using the Encryption tab. The Authentication tab will enable to you to configure the appropriate authentication algorithms for remote access to the enterprise. Let s investigate the security measures that will enable us to secure the IAS server on the enterprise.

Securing the RADIUS Implementation

RADIUS servers will be hosted in a server room with other enterprise software servers. These servers need to be physically protected from intruders. This will include locked doors, security alarm systems and dedicated server space for the IAS servers. We can also make some configuration changes to protect the servers from intruders.

Figure 6.20: Edit the Default Policy Settings

Exam Warning

We should test all RADIUS clients using local authentication methods before we make them enterprise RADIUS clients. This will enable us to troubleshoot problems more efficiently . We should not install a Windows Server 2003 IAS server on the same partition as a Windows 2000 IAS server. Both IAS servers use the same Program Files directory to store remote policies and logging details of each IAS implementation. Consequently, Windows Server 2003 IAS data will override the Windows 2000 IAS data. We should also avoid adding a Windows Server 2003 IAS implementation into a Windows NT 4.0 domain that will read the user accounts on a Windows Server 2003 DC. This situation will restrict the Lightweight Directory Access Protocol (LDAP) to query the IAS on Windows Server 2003.

Head of the Class
Security Issues with IAS Access

We should not send sensitive information (for example, passwords and shared secrets of the enterprise) as plain text on the enterprise network. Intruders might use packet snooping software to listen to the communication between the servers and the clients. Therefore, we should take steps to encrypt the data communication. The data encryption mechanisms will protect the data if the intruders get hold of it. Intruders need to decrypt the data to obtain the information. There are two ways to combat this problem:

Use Terminal Services to access the IAS server Terminal Services offers 128-bit encrypted communication between the client and the server. This mechanism will encrypt the sensitive information in the network. Terminal servers send the desktop image to the Terminal Services clients. The clients will collect the mouseclicks and screen information and send it to the server. There will be no processing of information at the client end. The server will process the mouseclicks and the screen data to determine the user action at the client end. Therefore, all the processing is done at the terminal server end (the client will only provide the mouseclick information). This is an additional security measure on top of the encryption process.
Use IPSec to encrypt communication between the RADIUS server and the client IPSec can be used to encrypt the communication between the two machines. We need to install the Windows Server 2003 Administration Tool Pack on the client machine to enable this.

It is also a good practice to enable logging at the IAS server. This will enable an audit trial if the servers are compromised. There are two logging facilities that we can use to enable logging on IAS:

Event log entries in the event log This is used primarily for connection attempts to the IAS servers for auditing and troubleshooting purposes. The entries will be logged in the System log.
Log user authentication and accounting requests This is primarily used for billing purposes and connection analysis. The entries could be written to a text file or SQL Server database for reference on demand.

We need to make sure that we have sufficient storage capacity to accommodate logging on the server. We also need to back up the log files regularly, because they cannot be duplicated if they are damaged. It is also advisable to accommodate a fail-over server should the SQL Server log machine fails. This could be achieved by creating a duplicate SQL Server machine on the different subnet of the network.

We should also consider some good practices to implement IAS in a large enterprise. It is a good practice to add the users to logical groups in the enterprise. These groups should be small in number, and the only groups allowed access to the IAS server. This mechanism is preferred over adding every user to gain access to the IAS server.

Test Day Tip

You can also make some Registry modification to increase the performance of the IAS server. If the IAS server is not a DC and it is receiving a large number of requests, we can change the HKEY_LOCAL_MACHINE\_SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. We need to add a new attribute called MaxConcurrentApi. We can modify the value from 2 to 5 in this new entry. We need to be little cautious about this attribute; a higher number can impose more burdens on the DC of the network.