Self-Service Account Administration

Many calls to corporate Help desks involve Windows 2000 and Windows NT 4.0 account-management tasks that require a systems administrator's intervention, such as recovering a forgotten password. A self-service account-administration model might be just the ticket to improve IT staffing efficiency and reduce costs—significant benefits in today's volatile economy. Such a model capitalizes on the concept of impersonation in COM+ to let users reset their passwords and unlock their AD user accounts. If your high-security environment precludes letting users administer their accounts, you can leverage the same model to increase security by using stored personal data to verify the identity of users who call the Help desk.

How do you create a secure self-service account-administration system? You can purchase a prebuilt system from an Independent Software Vendor (ISV), but in many circumstances, you can use ActiveX Data Objects (ADO), Active Directory Service Interfaces (ADSI), and Active Server Pages (ASP) to develop a basic Web-based solution for less money. In general, such a solution must perform three fundamental activities: data collection, user authentication, and account administration. First, you need a data-collection application that you can use to populate a database with information that uniquely identifies users. Second, you must develop a secure user-authentication mechanism that uses this data rather than traditional username and password credentials. Third, you can extend the authentication mechanism to unlock an account or reset a password on the user's behalf. I've created a complete sample solution (including documented source code) that you can download and adapt to your environment. To download the necessary files, go to http://www.winnetmag.com, InstantDoc ID 26696, and download the 26696.zip file. For information about implementing the applications, see the Web-exclusive sidebar "Sample Self-Service Account-Administration Application" (http://www.winnetmag.com, InstantDoc ID 26695).

Step 1: Data Collection
To determine the data you need to collect, first consider how you can best authenticate users without relying on traditional username and password credentials. Many nontechnical instances of this type of authentication exist. For example, a telephone conversation with a customer-service agent at a financial institution inevitably begins with a few questions that help the agent feel relatively secure about the caller's identity. Some institutions consider knowledge of address and account number sufficient, whereas others ask for personal information such as mother's maiden name or an account password. These basic questions help provide human-to-human authentication. The two parties can then continue with the business at hand, whether it be trading securities or discussing an account balance.

To begin collecting user secrets, develop an NTFS-secured Web page (data_collection.asp in the sample application) that presents four to six personal questions (i.e., challenges), as Figure 1, page 68, shows. These challenges need to meet several criteria. The captured secrets (i.e., responses) should be things that only the user knows, can't be found in corporate databases or public information stores, and can't be socially engineered (i.e., intruders can't discover the answers through guesswork, casual conversation, or observance of the user's physical characteristics). Also, the responses should be static (i.e., the data won't change should the user change job function or location). These criteria preclude questions about such things as the department the user works in, the user's home address, or a telephone number. Coming up with challenges that meet these criteria can be tedious—especially in global organizations, in which some users don't have a social security or driver's license number that you can use.

Almost everyone, however, can provide genealogical information such as parents' anniversary, mother's birth year, or maternal grandfather's name. Such information is difficult to discover through casual acquaintance and therefore can be useful static data. You might also consider challenges that are open to user interpretation, such as a request for a memorable date. Such questions don't specify the type of date, which can be anything from a birth date to an anniversary date to a date of hire. Or, you can let users provide both a question and answer. This method is probably the most secure because imposters would need to discover both the challenge and response. However, deriving challenges that meet all the necessary criteria can be difficult, so leaving the question solely in users' hands might not be the best choice. To ensure that the data is static and difficult to discover, balance user-defined and predefined challenges.

To build the data-collection application, you need to create a three-tier architecture that consists of a database back end, a COM object that interacts with the database, and ASP code that creates the UI. In the sample application, the included database defines two tables: Predefined_Questions and Collected_Data. Predefined_Questions, which Web Table 1 (http://www.winnetmag.com, InstantDoc ID 26696) shows, stores the predefined questions that the script presents to the user (e.g., What is your mother's maiden name?). Collected_Data, which Web Table 2 shows, stores user responses. The sample script uses a Microsoft Access 2000 database, but you can easily modify the COM object's ADO code to use any ODBC-compliant database back end.

The data-collection effort begins when users navigate to data_collection.asp, which contains the code that Web Listing 1 (http://www.winnetmag.com, InstantDoc ID 26696) shows. The script instantiates authenticate.dll through the instantiate.inc include file, which Listing 1 shows.

Data_collection.asp then uses the code at callout A in Listing 2 to call the GetNumberOfPredefinedQuestions method. The script uses this method to determine the number of predefined questions currently stored in the database. As the code at callout B in Listing 2 shows, the script then uses that value in a loop to call the DisplayPredefinedQuestion method and to generate the HTML code that presents the predefined challenges and corresponding response text boxes.

Data_collection.asp also uses the code that Listing 3 shows to present a custom challenge and response pairing. After the user provides the information and submits the form, the script posts the data to confirmation.asp, which Web Listing 2 shows.

   Previous  [1]  2  Next