This is the first of many articles in a series that I’ve planned to help me work through building a simple application. The idea is to create a simple utility that is going to solve a small problem at I’ve seen at work. The base version of the software is going to be quick and dirty and intentionally not implement any software best practices. Over the next few weeks I will then continually refactor the utility by implementing various best practices that are particularly relevant at my job.
A Problem Scenario
During the past week at work, two people asked our system administrator why several phone extensions were not showing up in the company’s Outlook Global Address book. We run a MS Exchange environment which leverages Active Directory (AD) to populate contact information for company employees. It turns out that only administrative personnel have the permissions to update the Active Directory repository.
I was a bit surprised that MS does not have a self-service utility for the modifying the AD repository. Google didn’t have much to offer besides some expensive solutions that would have been overkill.
So why can’t users update their own contact information? Like all good software projects, this one started because I had an itch.
The Proposed Solution
I’m going to write a simple, single-page utility to allow employees to manage their own AD personal information. The goal here is to put enough “meat” into this utility to provide a decent code base to experiment with but not to let the scope of this mini-project creep and turn into an unpaid second job.
The AD Self-Service utility should offer the following features:
- Allow users to edit their own personal account information
- including Name, Address, Phone, and who they report to
- or Just about anything that is viewable in the Outlook Global Address Book
- Users should not be able to do any of the following
- Change other users data
- Change their user rights via group membership or other AD settings
- The Administrator of the utility should not have to grant excessive permissions in AD to allow the utility to work ( e.g. – The admin shouldn’t need to store domain admin credentials within the utility )
- Security should be enforced through the tool
- The system will be an ASP.NET solution with (hopefully) a single page
- I would like to use windows authentication to pass users credentials straight into AD via IIS
- This will keep the UI simple and provide some valuable experience using the ASP.NET / IIS security model
So What’s Next?
The exact number of articles or topics have not been determined. This will be an ongoing mini-project that hopefully I can continually come back to and use to try out different coding techniques. The first article of the series will discuss the base line version of the utility and probably what not to do in software design. Beyond the baseline article here are some additional ideas:
- Fundamentals of good code organization, naming conventions, class design
- Implement an automated build system with Continuous Integration (CI)
- Discuss defensive coding, proper exception handling technique, and Unit Testing