Lesson 3:Configuring Authentication for Web Users

 < Day Day Up > 



Active Directory is a perfect way to store credentials for internal users because it can provide single sign-on authentication for a variety of network resources, including Web servers. If your organization provides an internal Web site, the Web site should authenticate users by using their existing Active Directory user accounts. If the Web site accesses information on the user’s behalf, such as querying a database to retrieve confidential benefits information, the Web site should access that information by using the user’s own credentials.

Active Directory is not the ideal way to store credentials for external users. Many organizations invite customers, potential customers, and partners outside the organization to access information, files, and data. Today, information is usually shared with external users by means of a Web site. If the Web site allows anyone on the Internet to access content, these Web users will be considered anonymous. However, the anonymous user’s requests must still be issued in the context of a valid security principal in order to access files and data.

Configuring Anonymous Access for Web Users

Most public Web sites on the Internet allow anonymous access for at least a portion of the site. In other words, the general public can retrieve pages from the Web server without providing credentials. This does not mean that authentication is not taking place, however. Any user or process that accesses a file or other network resource must do so in the context of a security principal (a user, a computer, or a service account). When Internet Information Services (IIS) accesses files to be sent to an anonymous user, it uses a specified user account to access those files. When anonymous access is not allowed, users must provide their own credentials.

As an administrator, you can control which user account IIS uses to access files and other network resources on behalf of anonymous users. By default, this account is automatically created during the IIS installation process and is named IUSR_computername. To specify different user credentials for IIS to use when accessing files and resources on behalf of an anonymous user, first create a new user account, and then follow these steps:

  1. Log on to the computer as an administrator.

  2. Click Start, click Administrative Tools, and then click Internet Information Services Manager.

  3. Expand the computer node, and then expand the Web Sites folder. Right-click the node for the Web site you are editing, and then click Properties.

  4. Click the Directory Security tab. In the Authentication And Access Control grouping, click the Edit button.

  5. The Authentication Methods dialog box appears. Type the user’s credentials in the User Name and Password fields, and then click OK.

  6. Click OK again to return to the Internet Information Services Manager.

Configuring Web Authentication

This chapter has already described three authentication protocols: LM, NTLM, and Kerberos. However, none of these protocols can be used by a Web browser to authenticate a user to a Web server because Web browsers and Web servers can use only Hypertext Transfer Protocol (HTTP) to communicate. Web browsers must authenticate to Web servers using an authentication protocol that is contained within HTTP. Administrators configuring an IIS server have several authentication options that differ in how they pass the credentials to IIS and which browsers support them:

  • Basic Authentication. Selecting this option enables browsers to submit the user’s password in an encoded format that is equivalent to clear text. If the authentication traffic is intercepted, an attacker could easily determine the user’s password. While this authentication method is vulnerable to being intercepted, it is supported by a wide range of browsers. Basic authentication should be chosen only when browser compatibility is required.

  • Digest Authentication For Windows Domain Servers. Selecting this option allows the Web browser to submit the user’s password in an MD5 hash. If digest authentication traffic is intercepted, an attacker would be able to easily determine the user’s password.

    Security Alert 

    Digest authentication functions only if the domain controller has a reversibly encrypted (clear text) copy of the requesting user’s password stored in Active Directory. Using reversible encryption is not recommended. As a result, integrated Windows authentication is recommended over digest authentication.

  • Integrated Windows Authentication. Selecting this option enables Kerberos v5 authentication and NTLM authentication within the Web requests. This allows the Web browser to send the user’s password in the form of a hash without requiring the user’s password to be stored using reversible encryption. Integrated Windows Authentication is supported by Microsoft Internet Explorer but may not be supported by other browsers.

  • .NET Passport Authentication. Select this option if your organization is using the .NET Passport service for authentication. .NET Passport provides a central authentication service that many different organizations can use and allows users to authenticate themselves to many different, unrelated Web sites. Selecting this option will have no effect unless application developers have created a .NET Passport–enabled site.

    Planning 

    If your users will have a recent version of Internet Explorer, use Integrated Windows Authentication. If you can’t mandate a particular browser, enable both Integrated Windows Authentication and Basic Authentication.

Delegated Authentication

Delegated authentication occurs when a network service accepts a request from a user and assumes that user’s identity in order to initiate a new connection to a second network service. Delegated authentication occurs by default when anonymous access is disabled for IIS. A typical architecture in which delegated authentication is used is shown in Figure 1.4.

click to expand
Figure 1.4: Typical delegated authentication architecture

Using delegated authentication increases the security of back-end network services. Without the use of delegated authentication, a back-end database must grant the Web server access to all data that any user would potentially need to access. In essence, without delegated authentication, the database must rely entirely on the Web server to authenticate and authorize users.

With delegated authentication, the Web server presents the end user’s credentials when accessing data from the back-end database. The database can then determine whether the user should be able to access the requested piece of information. In the case of a human resources database, the database administrators could configure the database to allow employees to only view the names and locations of users. However, employees working in the human resources department could be granted access to view and update specific rows and columns in the database that should not be accessible to all users.

To delegate this right, assign the Enable Computer And User Accounts To Be Trusted For Delegation user right to the selected individuals. By default, Administrators have this right. Users who are assigned the right to enable delegated authentication can then edit the properties of computer accounts in the Active Directory Users And Computers console, select the Delegation tab, and click one of the two Trust This Computer For Delegation options. This setting should be specified for computer and service accounts that are used to provide users information that is stored on back-end servers and must be accessed securely.

Security Alert 

Misuse of this user right, or of the Trusted For Delegation setting, could make the network vulnerable to sophisticated attacks such as Trojan horse programs that impersonate incoming clients and use their credentials to gain access to network resources. As a result, you should set the Account Cannot Be Delegated option on accounts that are sensitive.

By enabling delegated authentication, you can prevent an attacker who gains control of a server from accessing data stored on other servers that require user credentials to access. By requiring that all data be accessed by means of credentials that are delegated to the server for use on the client’s behalf, you ensure that the server cannot be compromised and then used to gain access to sensitive information on other servers. However, if the server itself was given access to information stored on other servers, an attacker who gains control of a server would be able to access the information stored on the other servers.

Important 

If you enable Encrypting File System (EFS) on a file server, that server must be trusted for delegation to obtain certificates on behalf of a user to encrypt and decrypt files.

When you enable delegated authentication for a computer account by selecting the Trust This Computer For Delegation To Any Service option, delegation is automatically enabled for all services on that computer. Constrained delegation allows administrators to specify particular services from which a computer that is trusted for delegation can request resources. By using constrained delegation, you can prevent attackers who compromise a server from accessing resources that are not intended to be accessed by that server. Specify constrained delegation by selecting the Trust This Computer For Delegation To Specified Services Only option, specifying the available authentication protocols, and then selecting the services, as shown in Figure 1.5.

click to expand
Figure 1.5: Computer account properties dialog box

Practice: Configuring Anonymous Authentication

In this practice, you will install the Application Server role on Computer1.cohowinery.com. You will then configure it so that it does not allow anonymous Web requests, and verify that it is configured correctly by issuing a request from Computer2.cohovineyard.com.

Exercise 1: Installing the Application Server Role

In this exercise, you install the Application Server role. While this exercise is not directly significant to the material covered on the exam, the Application Server role must be available for future exercises that relate directly to configuring authentication for Web users.

Warning 

It is critical that your server is not connected to a public network during this exercise. Installing the Application Server role may introduce security vulnerabilities.

  1. Log on to the cohowinery.com domain on Computer1 by using the Administrator account.

  2. Click Start, click Administrative Tools, and then click Manage Your Server.

  3. Click Add Or Remove A Role.

  4. On the Preliminary Steps page of the Configure Your Server Wizard, click Next.

  5. On the Server Role page, click Application Server, and then click Next.

  6. On the Application Server Options page, select Enable ASP.NET, and then click Next.

  7. On the Summary Of Selections page, click Next.

  8. Follow the instructions provided by the wizard. When the installation has completed, click Finish.

Exercise 2: Verifying Anonymous Access

In this exercise, you verify that anonymous access to Web pages is enabled by default by issuing an anonymous request from Computer2.cohovineyard.com.

  1. Log on to the cohovineyard.com domain on Computer2 by using the Administrator account.

  2. Click Start, click All Programs, and then click Internet Explorer. Close any warnings that appear.

  3. In the Address field of Internet Explorer, type http://computer1.cohowinery.com, and then click Go.

    An Under Construction page will appear. While this resembles an error page produced by Internet Explorer, the page titled Under Construction is an HTML page located at C:\Inetpub\wwwroot\iisstart.htm on Computer1. The page was successfully retrieved by Internet Explorer because anonymous access is currently enabled in IIS. IIS accessed the file using the IUSR_Computer1 user account.

Exercise 3: Removing Anonymous Access

In this exercise, you remove anonymous access and verify that anonymous requests are rejected.

  1. Log on to the cohowinery.com domain on Computer1 by using the Administrator account.

  2. Click Start, click Administrative Tools, and then click Internet Information Services Manager.

  3. Expand the Computer1 node, and then expand the Web Sites folder. Right-click Default Web Site, and then click Properties. The Default Web Site Properties dialog box appears.

  4. Click the Directory Security tab. In the Authentication And Access Control grouping, click the Edit button. The Authentication Methods dialog box appears, as shown in Figure 1.6.

    click to expand
    Figure 1.6: Authentication Methods dialog box

    Notice that Enable Anonymous access is currently selected. IUSR_COMPUTER1 appears in the User Name field. Any resources that anonymous users attempt to access through IIS will be accessed by the IUSR_COMPUTER1 account. The IUSR_computername account is automatically created when the Application Server role is added to the computer.

  5. Clear Enable Anonymous Access, and then click OK. Click OK again to close the Default Web Site Properties dialog box.

  6. Return to Computer2. In Internet Explorer, click the View menu, and then click Refresh.

    After you click Refresh, Internet Explorer sends another anonymous request for the iisstart.htm file that it is currently displaying. However, this time IIS will not return the page. Instead, IIS will return an access denied error, also known as a Hypertext Transfer Protocol (HTTP) 401 error.

  7. Because the anonymous request was denied by IIS, Internet Explorer opens the Connect To Computer1.cohowinery.com dialog to prompt you for a user name and password, as shown in Figure 1.7. Click Cancel.


    Figure 1.7: Internet Explorer prompt for credentials

    Internet Explorer displays a friendly description of the access denied error. This is the default error that users receive when they are either not adequately authenticated or not authorized to access content. Web application developers can customize the error message.

  8. In Internet Explorer, on the View menu, click Refresh. You will again be prompted to provide credentials to access the page.

  9. In the User Name field, type Administrator. In the Password field, type the Computer1 administrator password. Click OK.

    Internet Explorer successfully displays the Under Construction page because you provided credentials that were authorized to access the requested file. Note that you did not directly retrieve the iisstart.htm file from the file system. Instead, IIS retrieved the file on your behalf using the Administrator credentials you provided, and then returned the page to Internet Explorer.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

  1. Which of the following authentication methods should be chosen for a Web site on a public Internet with minimal security requirements, where administrators have no control over which browser a client uses?

    1. Basic Authentication

    2. Digest Authentication For Windows Domain Servers

    3. Integrated Windows Authentication

    4. .NET Passport Authentication

  2. Which of the following authentication methods should be chosen for a high-security, internal Web site in an Active Directory environment where single sign-on is a requirement?

    1. Basic Authentication

    2. Digest Authentication For Windows Domain Servers

    3. Integrated Windows Authentication

    4. .NET Passport Authentication

  3. Which of the following scenarios requires delegated authentication?

    1. A public Web site from which all content should be anonymously accessed.

    2. An internal Web site from which all content should be anonymously accessed.

    3. An internal Web site containing simple Hypertext Markup Language (HTML) documents that only managers should be able to access.

    4. An internal Web site that accesses a back-end server containing data that only specific users should be able to access.

Lesson Summary

  • Web users have special authentication considerations. Specifically, you must choose whether anonymous access will be allowed, and what account will be used to access resources on behalf of anonymous users. If anonymous access is not allowed, you will be making use of delegated authentication.

  • Web users have four choices for Web authentication methods: Basic Authentication, Digest Authentication For Windows Domain Servers, Integrated Windows Authentication, and .NET Passport Authentication.

  • Use delegated authentication, and the more granular constrained delegation, when front-end servers must access back-end services on behalf of authenticated users.



 < Day Day Up > 



MCSA(s)MCSE Self-Paced Training Kit Exam 70-299 (c) Implementing and Administering Security in a M[.  .. ]twork
MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)
ISBN: 073562061X
EAN: 2147483647
Year: 2004
Pages: 217

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net