Partager via

Time for an Active Directory Redesign?

  • Article

Hi all... I'm Robert DeLuca, the Identity Management guy on WinCAT.

After a year or two of slowly dwindling requests for AD design reviews, there appears to be a growing trend among many of my enterprise customers - full Active Directory redesign. I guess 5 years of living with suboptimal AD designs (You have HOW MANY domains? Site-based group policy for WHAT? Firewalls WHERE?) leads to people wanting a fresh start. I generally don't like messing with things that aren't broken, but a lot of the big players are starting to recognize how much those suboptimal designs are costing them to operate. Extra DCs everywhere... problems supporting roaming laptops and users... difficulty keeping group policy consistent... the list goes on. Then there's the difficult-to-quantify impact on enterprise applications. What is the true cost of not having a stable, standardized corp-wide directory service for app developers to rely on? Redesign sure seems like a nice way out. Or maybe the AD guys are just bored and/or looking for job security? :) Either way, it's gaining traction with management and they often seem willing to swallow the costs of a major migration.

Is a fresh start really the correct way forward? The most important question is why the redesign is desired in the first place. What requirements will be addressed by the new system that weren't being addressed by the old one? I try to separate the operational issues from the true architecture/design issues. If the existing AD implementation is troublesome because of... let's call it a "lack of operational prowess"... building a new forest right beside it won't help unless the root cause of the problem is dealt with too. What seemed like a fresh start quickly ends up in the same operationally degraded state.

I typically recommend that customers go through an AD Risk Assessment (formerly known as an AD Health Check - talk to your Microsoft TAM for details) to help shake these problems from the tree. I'm tempted to make them mandatory before I'll dig into a major redesign effort. Why? Once the operational issues are out of the way, there's much more clarity. If there are still underlying issues related to the forest or domain structure, they can be mulled over without the added pressure of constant operational problems.

Back to the original question - time for a redesign? In reality, most of the troubled forests I see are fundamentally sound. Some customers do have broken designs, but in a vast majority of cases it makes more sense to leverage parts of the existing environment as the basis for the "new" environment instead of building anything from scratch. Granted, figuring out which parts to keep is often a challenging mix of technology, strategy, finances, and politics... but that's the fun part. If the trend holds, it looks like were going to see much better AD implementations in the years to come.

Comments

  • Anonymous
    April 06, 2006
    I'd like to see A/D do a lot of things that us 'Legacy' (i.e. those with Novell NDS experence) took for granted in NDS.
    For example, why not use A/D to assign file and folder permissions. Then you could run a query against A/D and see what rights a user has to all files and folders in their domain?
    You could use 'Aliases' to show a folder as more than one name (Although DFS sort of helps with this).
    You should be able to see in user properties a history of when the user logged on/off.
    The list goes on, but the MORE you can do through A/D the better.
    DFS and Printer management should be A/D functions.
    File replication should be done in A/D.
    I think you get my gist.
    A/D has always been more cumbersome to use than NDS ever was.
  • Anonymous
    April 26, 2006
    I think these are great ideas, but so far we've taken a different approach to the directory. Features like data validation/enforcement have been left to other Microsoft products while we focused on ensuring AD was a stable, reliable, secure directory platform.

    Integration between the file system and AD is a common request from NDS folks, but I think the issue runs deeper than the file system. It's an authorization/entitlement issue in general. Think of file services as a consumer of authorization information, just like any other application. We're looking at better ways of handling authorization, especially when you need to enforce and audit across a large globally distributed enterprise.

    So what does it really mean for something to be "done" in AD? Is it having a single console to manage these functions? Or is it storing the configuration information in the directory? Or are you saying the AD code itself should perform these functions? From an end-user perspective I suspect the requirement is somewhere between a single console and leveraging the directory for config data.