Identity Management and other related stuff

AD account management and BPOS

Living with BPOS

Few weeks ago Schakra cut the umbilical cord of local Exchange server and fully moved into the cloud for all Exchange needs. The “cut” was rather anticlimactic. No email outage, no interruptions, no user screams… it was boring and trivial event. So what we have lacked in the “excitement” of migration, we have acquired on account management front. You would think that having less systems to manage will simplify life of an AD admin… not so fast. Once you’ve got accustom to Exchange management console you become dependent on those [pseudo-hidden] attributes such as msExchHideFromAddressLists, proxyAddresses, etc. With or without local Exchange box my admins demanded functionality to hide accounts, add additional addresses to user mailboxes, etc, etc. My first reaction was: “here is the list of attributes and ADSI Edit – go at it…” then I’ve started an investigation on how to “gracefully” expose the UI for those hidden treasures. Options were not so obvious, as one hoped: ADSI (or other LDAP) editor, upgrading AD to 2008 functional level and use of ADUC in that mode or the scripting. Of course having full-blown Identity Management system would help too.
Demographic data of BPOS user-base suggests that many of its users would lack the fully established Identity Management system, or the latest functional-level of AD, or the tools/comfort-level to edit raw AD data. So I’ve decided to attempt to automate a simple account creation process for all of those who are in post-migration stage of Office 365 deployment.

Choosing PowerShell

At first I was ready to write a command-line tool that would simply create a user account with pre-populated set of must-have attributes. PowerShell (being an interactive version of C# for the masses) is well situated for all sorts of administrative tasks; however my goal of providing familiar environment to my system admins will not be accomplished by writing a command-line utility. Having UI is a good thing for the comfort level. So I’ve decided to wrap a windows-forms application in PowerShell format. “Why oh why”, you would ask? PowerShell is command line environment after all. Writing windows form application defeats the purpose of the shell. Well… the answer is – not really. Even though it is not traditional approach to use the shell, having windows-forms should provide Windows admin with familiarity and therefore convenience. Yet, having PowerShell-based application provides ease of source maintenance and therefore gives end-user an ability to tweak application to his/her liking. So behold the PowerShell script/app to create your user accounts in AD.

Goals

Here are the goals that I’ve set for myself while writing this app

Create form-based application in PowerShell

Ensure that all ‘business logic’ for account creation is automated (OU location, group membership, etc.)

Ensure that there is as little typing as possible (Auto-concatenated display name, auto created alias, etc.)

To ease a pain for PowerShell adopters with creation of form-based application (One can re-use parts of my app to write something else)

Have no dependencies on AD-management snap-in (Use of ‘plain-Jane’ PowerShell would allow user to run it as-is without an additional dependencies and installs)

Non-Goals

Things that this ‘app’ is not…

Fool-Proofing (Although there is no end for error-proofing, I had to keep in mind that this is a ‘script’. PowerShell would throw plenty of nasty errors on the screen is something goes wrong.)

Full account management console (This is an app to create a user in AD, not edit a user or delete a user. I am sure it is more than possible to extend this to the full-blown 3rd party account management console… but why)

Business Logic

In my application I’ve used internal to Schakra assumptions. My system admin team is having set of internal rules for our internal account creation such as user location in AD is determined according to user’s employment type, account name and display names are calculated with particular formulas, group membership is pre-determined according to user’s employment status, etc. etc. All those things are easily modifiable and adjustable. Feel free to extend the application and adopt it for your internal use.