IT Stuck in Manual Mode Despite Active Directory's Promises
According to a recent survey, administrators in Windows environments are still doing much of their administrative legwork the old-fashioned way: by hand.
Directory services were originally sold as a way to simplify management in the enterprise, at least in non-mainframe environments. 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."