Cross - post - Lessons Learned

As I wrap up a significant travel segment doing user groups, customermeetings and product strategy meetings I have learned many things – and perhapsone thing that has become abundantly clear is:


Active Directory has won


Active Directory is special


As I met with several hundred customers, racked up just a touch over100,000 air miles, it is quite clear that Active Directory is the defacto andprimary user enterprise identity repository for virtually any organization onthe planet. Hardly a revelation to be sure, but I suppose that I wasperhaps a little surprised at the depth of penetration and usage everywhere Igo.

With this in mind, and the raft of applications, services and infrastructurethat utilizes AD for its operations it is important to consider the folksbehind this that make this happen.


What I have seen in many cases is that the AD administrator teams continueto be relegated to the back office, and perhaps not getting the same exposureas other specific technology groups.


While this is not meant to be a rant on how bad AD folks have it,it's moreof a call out to what the technology means to the business and how best toensure its continued health and reliability.


When you look at other specific technologies such as large scale HR systems,inventory control platforms - one thing becomes clear. These technologiesrequire specialized skillets, processes and management approaches.


If you review your organization, you will notice that the HR group has theirown specific and specialized IT team that is primarily responsible for thatplatform. Sure they may utilize network services from the infrastructure team,rack space from the physical plant team and SSL certs from an outside vendor -the rest of the application stack is their baby.


"Ya, so what?".


Well when I've seen AD admin teams run over by other projects - large scaleIDM deployments for example - that fail to take consideration for thespecialties that AD requires - it is clear that neglecting this important partof infrastructure will very much be at your detriment.


For example, I have one customer that had an over arching IdM projectdeployment that was managed outside of the AD team. The technologydoesn't matter in this case, as you'll see shortly. This customer, which hadwell over 50,000 users - had the IdM project team decide to do AD provisioning(and requisite services like Exchange) managed by the IdM team and its newtool.

Now, for those of you what have done IdM deployments you understand thatthese are large projects that involve significant business process integrationand management. Again, putting technology and platforms aside, by the verynature of including the business and process you get business process changewindows, change approvals and a whole host of process that surrounds theplatform that manages many important business requirements.


Fine, so IdM means slow right? Yes and no. If you arechanging a separation of duties roles, you want this to be a considered, vettedand properly managed process. What it also means is that other servicesare dependent on the IdM platform as well.


So back to our example, this customer had a major issue with some SAMstorage arrays and basically had to change out much of the infrastructure, andas part of the emergency changes had to update host names, some policies andpermissions.


Now since the IdM platform was already in place, and there were many otherhigh priority requirements in place, the AD team wasn't able to get therequired updates into the IdM platform for almost 3 months, which meantevery AD account provisioned was done incorrectly resulting in manual workefforts for each. Silly you say? Yes. Should they have betterchange processes? Perhaps. Maybe it wasn't possible, andboarding applications for SOX compliance was more important than updating someAD attributes for provisioning. Since this customer had a huge retail presencewith big churn - there were over 2000 accounts a month that had to be touchedby hand. You do the math on lost staff time (AD admins, helpdesk,management escalations, new employees standing around without access, etc.)


Anyways, back to my main point here. After some whiteboard time wecame up with a more sane approach to managing AD within this sort ofcontext. In essence, we posited that the AD provisoning and managementfunction was no differentthan maintaining a specialized application like SAP or the host even. It's a specific skillset, with special requirements that higher level tools andoperational teams can’t be expected to be concerned with.


So in this case, the higher level IdM tool would simply send requests toactive roles server with basic provisioning information and wait for results.ARS would handle the backend magic and maintain AD cleanly andefficiently. The IdM tool focussed on its strengths – like managingidentity information, access controls and compliance reporting.


Who cares? Well, this architecture allows the teams that are 'closerto the metal'- AD in this case – to manage care and feeding of this hugelyimportant piece of infrastructure and allow the compliance teams to focus ontheir targets.


So it's AD as special as PeopleSoft? I think you could have a gooddebate about that. Is AD as importantto the business as the HR system? You betcha.Consider what would happen if AD went wonky in your company - what wouldbe down? Mail, document access, building access controls - perhaps yourVOIP system, remote access for sure, etc.. Since AD has become defacto,it is also enormously criticalto standard business operations.


So allowing a specific, powerful and rich tool like ARS to facilitate theinterface to AD realmed solutions, while leaving other tooling to handle otherservices is not much different than other technologies, and has great historicIT examples.


And... This happens to be the approach we believe in here at Quest - thatthis provides a more agile and business responsive design for business - having AD being a specially designated servicewithin IT and managed as such.


Also, when you consider business requirements for the cloud, hybridcoexistence scenarios and other very complex IT requirements from the business,a specialized architecture that respects each platforms operational,maintenance and architectural requirements is the design pattern that survives.


Treating AD as a simple target that is just a few attributes and simple toprovision and manage is an approach that has left many vendors, consultants andunfortunately, customers in the lurch with a half baked, broken and inefficientIdM deployment.


Next time you hear someone say - "Ah we have a connector for that andAD is simple to provision" – be sure to demand and demonstrate that AD hasspecial requirements and should be treated with the same respect andconsideration of a PeopleSoft, SAP or other important piece of infrastructure!


//rantoff - Cheers!

Cross posted from my personal blog: