News

Survey: IT Stuck in Manual Mode Despite Active Directory's Promises

Directory services were originally sold as a way to simplify management in the enterprise. According to a recent survey from independent consultancy Osterman Research, however, administrators in Windows environments -- where Microsoft Corp.'s Active Directory predominates -- are still doing a lot of their administrative legwork the old-fashioned way: by hand.

This is in spite of the fact that Microsoft first pitched Active Directory as a means to automate or simplify many common administrative tasks.

Experts say Active Directory has delivered on this promise: it's certainly more intuitive, more flexible, and more manageable than the kludgey NT Domains model it supplanted. However, Active Directory -- like any directory service -- isn't a manageability slam dunk. It still has manageability gaps.

Osterman researchers say that almost three-fifths (59 percent) of IT managers are relying on manual tools (such as scripting or hand-coding changes) to navigate these gaps. Manual intervention of this kind can be costly. Respondents in the Osterman survey say that they require about eight person-hours per week to manage 1,000 Active Directory users -- so a shop with 5,000 Active Directory users would require the equivalent of a dedicated administrator to manage group or user changes.

The most alarming scenario, of course, is that Active Directory shops might wind up repeating the mistakes of the past. That's actually happening, argues Edward Killeen, vice president of sales and marketing with Active Directory management specialist -- and Microsoft Gold Partner -- Imanami Corp.

"A lot of really large companies have developed these really cumbersome scripts, and we have this concept of a Rube Goldberg kind of way of dong things, where you chain all of these scripts together and you have multiple points of failure and really no effective logging going on," he observes.

"This is basically where [administrators are] repeating these mistakes [of the past]: they either have the ability [in Active Directory] not to have to do this or there are tools they can use so they don't have to do this but they're doing it anyway. It's what they know."

Manual means still predominate in most shops. Killeen cites data from the Osterman survey -- which, he concedes, was commissioned by Imanami -- that indicates that nine-tenths of respondents use a manual process of some kind to manage Active Directory users or groups. This isn't in itself surprising, Killeen points out: neither Microsoft nor any other vendor has ever pitched a directory service as a completely automated management tool.

"On the other hand, I believe about 60 percent of [shops] are completely manual," Killeen counters, "and that's just unacceptable."

Killeen claims that the problem is especially vexing when it comes to managing Active Directory groups. "I think users are managed a little bit better, because there are a lot of software solutions out there for that. That's part of why we focus on groups, because there aren't a lot of tools," he explains.

The irony is that Active Directory groups tend to accumulate over time, such that a shop could at some point wind up with nearly as many groups as it has users.

"People use Active Directory groups pretty extensively. I was a little shocked that e-mail was fourth or fifth on the [survey] list of what they're used for most often, compared to granting access to folders or usage rights," he says, noting that in many shops users have self-service rights that permit them to create collaborative or recreational groups.

The latter category can include any number of non-business topics, such as a mailing list for the company softball team; a calendar for weekly after-work or happy-hour meetings; or a discussion list for fantasy football. One problem, Killeen points out, is that such groups tend to accumulate -- for example, Fantasy Football 2007, Fantasy Football 2008, and so on.

This is one reason that Imanami's concept of "dynamic groups" -- which gives users self-serviceability but prevents them from hanging either themselves or the organization in the process -- makes sense, Killeen argues. As implemented in Imanami's GroupID Automate, for example, the dynamic groups model prescribes a means of "aging" groups -- so they can be automatically disabled in the event of prolonged inactivity. At the same time, GroupID Automate polls Active Directory at periodic intervals to ensure that users (or groups of users) are still legitimate members of parent groups.

"[W]e find most of the [customer] interest initially [is] in dynamic groups. That solves the big [problems]," Killeen explains. "For example, everyone who's in marketing communications who's a director, everybody in the Akron office -- these are both groups that you can create really easily, then you never have to think about them again." The problem isn't just one of clutter. Yes, groups accumulate over time, and such groups can impact the performance, navigability, and manageability of Active Directory, but what happens when a user shifts from one internal business group to another? On the Active Directory side, if a user's legacy group memberships aren't purged in a timely fashion, havoc can ensue.

That's precisely what happened in the case of the notorious Société Générale fraud of 2008, Killeen notes. In that case, an employee with knowledge of the auditing mechanisms and controls used by Société Générale (as well as other financial houses) to safeguard against fraudulent trades was able to use both his expertise and his access privileges to game the system.

"If you control something like that by security groups and that guy's department changes, you take him out of those groups that give access and you wouldn't have had the problem in the first place," Killeen points out. "It's pretty simple to do the way we do it. Manually, it isn't so easy. If you had to write a query for everyone in your organization or every manager, that takes a lot of time."

Such issues are problematic to some degree in all directory services infrastructures, Killeen argues. They're especially problematic in Active Directory environments because -- for all intents and purposes -- Microsoft won the directory services battle, he maintains.

"The other [directory services] do have some of the same issues," he explains. "One of the reasons it's not as hot of a topic [with regard to other directories] is that Active Directory kind of won," Killeen concludes. "Even customers who are Notes customers still use Active Directory for authentication and everything else around network access -- so even if you aren't an Active Directory shop per se, you probably have it somewhere."

About the Author

Stephen Swoyer is a Nashville, TN-based freelance journalist who writes about technology.

comments powered by Disqus

Reader Comments:

Thu, Oct 21, 2010 Tom Philo Portland Oregon

Actually AD can have role groups, and people can easily be assigned a role which in turn has various sub resources assigned to the role which when a person is added into the role gives them specific rights to specific resources. However, all this works ONLY in VERY highly vertical structured departements where underlying servers, applications, and rights never change - static for years on end. What happens is that you end up with hundreds of specific resource groups being created to meet the need of these particural 3 people working on this project and they need rights for this particular folder, and then there is no role group for them, so you create a role group for them, create GPOs for them, manually assign the resources. The task is now finished the data has to remain behind, and be read, so ANOTHER role group and another set of resource groups for different people are created so they can see it, repeat for thousands of things done in any business. So you end up with 10 to 15 thousand resource groups being used in a few thousand role groups all having to be manually applied to specific folders on servers FOREVER. It just creates a lot of work on the back end that has to be manually reset anytime a new system is built to replace the old and there is no real managment tool that addresses any of this at all in AD.

Wed, Oct 20, 2010 Joe Dyck

Further to my comment, although it is "Creative" to think up a new product (Forefront Identity Manager to solve the problem (and sell it!) it would probably be a good idea to make Active Directory more manageable. Simplicity in the long run will keep Active Directory and Windows Server a strong and attractive product.

Wed, Oct 20, 2010 Joe Dyck

It is interesting you mention Lotus Notes (Domino). What Lotus Notes Access Control has that AD doesn't is and additional item called a ROLE. A person with a particular Job Function (E.G. Electrical Engineer) has a corresponding ROLE. The ROLE is given access to whatever groups or data is needed to perform that Job Function. There should ROLES in MS AD as well as groups. This simplifies maintenance, as when you have a new Electrical Engineer, you just assign them to that ROLE, not a dozen groups associated with that ROLE and other general groups, you don't have to cook up the EE recipe again and again .

Thu, Jul 22, 2010 Shinigami Switzerland

Indeed, FIM 2010 has the capabilities to automate group management. Plugins for Outlook or a dedicated web portal provide users with capabilities to request and manage group memberships via a delegation hierarchy, thus easing the administrative burden on the IT department. But not only this, FIM has many other capabilities such as directory synchronizations, password self-resets, user creations and more. btw: I'm a FIM Consultant at Microsoft :) Please don't shoot me...

Wed, Jul 21, 2010 EVVJSK

Would have been helpful to have a concrete example of where AD automation could replace a script or other manual means. Also, need to determine if that automation relies on purchasing some additional software (scripts are usually free).

Wed, Jul 21, 2010 David

The solution to this problem is use Forefront Identity Manager 2010. Not sure why Stephen didn't mention this. http://www.microsoft.com/fim

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.