Sample Self-Service Account-Administration Application

I've created several sample scripts that you can download and adapt to your environment to create a basic self-service account-administration system. To implement these scripts in your enterprise, you need to meet the following prerequisites:

• You must install the scripts on a Windows 2000 server running Microsoft Internet Information Services (IIS) 5.0 (the default Win2K installation includes Active Directory Service Interfaces—ADSI—2.5 and Microsoft Data Access Components—MDAC—2.5 or later), or on a Windows NT 4.0 server running Internet Information Server (IIS) 4.0, ADSI 2.5, and MDAC 2.1 or later. The system must use NTFS. Ideally, install the scripts on a test machine first, then migrate the server or application into production.
• You must have access to the server console, either physically or through Win2K Server Terminal Services or NT Server 4.0, Terminal Server Edition (WTS).
• You must have Administrative rights on the server.
• You must create a service account with the necessary user domain and Active Directory (AD) rights to reset passwords and unlock accounts in all the organizational units (OUs) you want to manage.

Next, log on to the server console and download the 26696.zip file from http://www.winnetmag.com, InstantDoc ID 26696. Run setup.exe to unpack the sample files onto the server's file system. By default, setup.exe unpacks all files into C:\authenticate. That folder contains the following subdirectories: com_setup, database, site, and source. Then, perform the following steps:

1. Establish a Data Source Name (DSN) for use with the sample database. Create a System DSN called Authenticate to point to C:\authenticate\database\authentication.mdb. You can change the DSN name, but if you do, be sure to change instantiate.inc to include those changes. Likewise, if you choose to place a password on the database—an important step before using these scripts in your production environment—you need to update the connection string in instantiate.inc to include the applicable database user ID (UID) and password. For large enterprises, I suggest you use something more robust than Microsoft Access (e.g., Microsoft SQL Server, Oracle, Sybase).
2. Establish a virtual directory to contain the application's Active Server Pages (ASP) files. You can use the Microsoft Management Console (MMC) Internet Services Manager (ISM) snap-in to create a new virtual directory under the Default Web site, point that directory to the site folder, and create a new Web site to point to the directory. Or, you can move the files into an existing Web site's virtual directory.
3. Navigate to C:\authenticate\com_setup and run setup.exe. By default, this action installs authenticate.dll, which contains all the functions necessary to support the ASP application, in C:\program files\authenticate.
4. To host the DLL, create a new Component Services or Microsoft Transaction Server (MTS) package called Authenticate. Set the package identity to use the service account you created earlier.
5. Select authenticate.dll from the folder in which you installed the setup files (i.e., C:\authenticate\components). Open the package's Properties and disable Authorization Checking for the package.
6. Repeat Step 5 for the Authenticate component. For more information about this process, see "Making the Transition: Multi-Tier Development for System Administrators". The tutorial specifies NT 4.0 and MTS, but the same concepts apply to Win2K Component Services.
7. Establish NTFS security for ASP files. The Anonymous account should have access to the following files: ssa.asp, ssa_confirmation.asp, authenticate.asp, config.inc, and instantiate.inc. Let the Authenticated Users or the Domain Users group access data_collection.asp and confirmation.asp. Don't let the Anonymous account access either of these files.
8. Use the ISM snap-in to set metabase security on ssa.asp, ssa_confirmation.asp, authenticate.asp, config.inc, and instantiate.inc so that IIS uses only the Anonymous Access method for these files. Allow only the NT LAN Manager (NTLM) or Basic authentication scheme (absolutely don't allow Anonymous Access) for data_collection.asp and confirmation.asp. Note that if you use Basic authentication without also using Secure Sockets Layer (SSL), intruders can use Network Monitor to capture the password you use for authentication in clear text.
9. To manage AD, use Notepad (or your favorite text editor) to edit C:\authenticate\site\config.inc according to the instructions included in that file. No changes should be necessary for NT domains.
10. To test the application, open data_collection.asp. You should receive a prompt for a username and password (unless you're using Microsoft Internet Explorer—IE—which might automatically present these credentials if configured to do so). Populate all fields and submit the data. Verify that the database contains the data and that the data is encrypted. Next, try using the self-service application to authenticate the information. Navigate to ssa.asp (this page doesn't require credentials for access), and try unlocking an account and resetting a password.

You can customize the application to suit your needs. You can use this sample application as the basis for a more robust solution for your enterprise. At a minimum, secure the database to prevent users from accessing it directly. Also consider implementing a logging mechanism to audit the activities of users on the site. As an added security precaution to protect the data in the database, you might consider hashing the value with the UID or the primary key for the row to ensure that the data is uniquely encrypted for each user. That way, if two users have the same data, the hashed values would appear unique (i.e., user-specific) in the database.