Wednesday, July 23, 2008

Active Directory 2008 by way of Internet Explorer


As I blabbered about earlier, I finally had a few minutes to finish up my stripped-down version of the "Active Directory Web Administrator" for home use. "ADWA" for short. This version uses Microsoft Access 2007, ASP on Windows Server 2008 (IIS7) and pretty much any web browser.


The hardware requirements for this are embarrassingly minimal, so you could EASILY host this entire beast (or puppy dog, as it were) inside VirtualPC, VMware or almost any other flavor of virtualized wonder.

The user accounts you see in the examples are my four kids (aka "tax breaks", "forced labor", "indentured servants"). Whom I built this for making it possible for my wife to be able to jerk their chain when they disobey her commands, leaving me free to focus on my day job (and keeping my cell phone quieter).

More screen shots of the app "in action"...



The basics are this:

An intranet web portal which presents a list of user accounts, their current status (enabled/disabled) and options to toggle them. The site uses integrated authentication to validate access to selected users, and relies upon the Access database to provide the queueing of requests. The requests reside in table rows in the database and are processed by a scheduled task running under a privileged services account.

Whereas the version I wrote for a previous project involved SQL Server and used CronNT to provide the scheduling, this is pretty similar. I've stripped out a ton of bells-n-whistles though. I don't need all the email notifications and event logging, just relying on the table rows to provide the audit trail. The bigger version was hosted on an SSL server with public access, with code-based validation of remote devices (only my Blackberry was trusted). That version had more options for multiple/diverse OU structures, managing groups, user passwords, account expirations and restriction filtering on sensitive accounts and groups. This one just enables/disables user accounts, and only for users in one OU.

Ingredients:
  • A Windows Server Active Directory environment. No, I won't help you get this working on a Samba 4 environment, sorry.

  • A web server. An IIS6 or IIS7 intranet server within the domain, configured to run classic ASP (I don't have time to do it in ASP.NET or PHP right now).

  • A service account added to the "Domain Admins" group, which has been granted GPO "Logon as a service" rights (minimum. you can bolt the security down as tight as you need)

  • Any ODBC capable database kind of thing. I used MS-SQL 2005 for the grand-daddy, but almost anything will do (Oracle, MySQL, SQL Express, Access, etc)

  • A script. This script will open the database, fetch rows where "status=0" (not yet processed) and execute the action requested, then stamp the process date on the row and mark it completed (status=1).

  • A Scheduled Task. You can use pretty much anything, but it needs to execute the script under the domain services account you created. It doesn't matter whether you prefer Windows Task Scheduler or CronNT or or what have you. I personally LOVE the Task Scheduler in Windows Server 2008. It really rocks.

Below is a view of the database schema. The fields are pretty basic. For a real database schema just use INT for the ID and STATUS fields, SmallDateTime for the DATE fields, and VARCHAR for the string fields.



Configure the permissions on the database to suit it being accessed by the IUSR_xx account and the domain services account (they will both be hitting this and making updates to rows). Note that for file-based databases like MS-Access, you need to grant folder permissions to enable the locking file to be created and removed by both accounts opening it.

Next comes the domain services account. I named it "ad_services", and added it to the Domain Admins group. Then I modified the Default Domain Group Policy to grant this account the "Logon as a service" right (remember to include the "Network Services" account also).





Next comes the web folder, code files and image files (optional eye candy)...





As for the web site and script code files, you can download them from links below. Be aware that you will need to open and edit the top-most portion of the "config.asp", as well as the "adwa.vbs" script file in order for them to work properly in your environment. Read the included readme.txt files for disclaimers and the usual legal mumbo-jumbo.

And before you start wondering, this is NOT indicative of how I code in ASP. This was thrown together very quickly due to limited time.

Extract the adwaweb.zip file into a folder tree named "adwa" that also restores the "css" and "images" sub-folders. Then create a new virtual folder in IIS and disable Anonymous Access and Basic Authentication, and select Integrated Authentication only. If you care about security, further lock down the NTFS permissions on that folder as well. Remember to open it up to the local IUSR account and the domain service account to both have Change access.

Extract the adwascripts.zip file into a totally different location, not under the web site. This will be where it is executed by a scheduled task. Lock down the script folder to allow only the domain service account (and administrators) to have read access. Edit the scripts to suit your needs. There are two: BAT and VBS. The BAT is what you schedule to run, which will launch the VBS file and generate a process log file each time it is run.
Post questions or comments if you care. Enjoy!
Post a Comment