IT-Business Collaboration

It seems that any tasks that are “tech-related” fall into the hands of IT. It’s been that way as long as I can remember. Managing groups in Active Directory is no different: It is something that IT takes care of — mostly because groups exist within a system (Active Directory) for which most users haven’t needed admin-level or manager-level access.

IT Business Collaboration

You might want to re-think this approach.

A critical step for organizations to improve how they manage groups involves a shift in thinking — from IT as the owner of all group management tasks to IT as the provider of services that allow users to own and manage groups by themselves. Managing Active Directory groups need to be thought of as a method for the entire organization to manage access to critical resources, applications, and data. Given these changes in perspective and approach, there are a number of factors that frequently prevent IT from being the perfect manager of Active Directory groups, including the following:

  • Application Expertise: IT doesn’t necessarily need, nor want, to be the omniscient overseer of an application or resource. In most cases, IT’s role is simply to provide the supporting infrastructure, and leave the app management to someone closer to its internal function. Take, for example, a CRM app accessed by a sales team. Without some context from the application owner, IT wouldn’t know whether someone should be a part of the SalesEast or SalesWest.
  • Visibility into Changes in Staffing: The list of people who need access to an application can change frequently. In some organizations, sales people come and go on a daily basis. So, which approach makes more sense to ensure proper group membership:
    • Letting someone who is concerned with the application’s data modify group memberships by adding and removing sales people?
    • Or relying on someone to send requests to IT for both additions and removals?
  • In most cases, the second option usually results in no removals of Active Directory groups.
  • Visibility into Changes to the Application: Upgrading to a new version of just about any application usually adds new features, which often require new levels of access granularity. Given the lack of familiarity with the application’s purpose or function, IT may not be in a position to assist in setting up or updating groups to take advantage of those new levels of granularity.
  • Time: If you’re like most IT professionals, you already know that you don’t have the time to manage all of the many other seemingly far more critical tasks and projects. Putting some real focus on groups just isn’t part of your reality.

When you consider all of these factors, it just makes sense that IT should really be simply the keepers of the groups, not the managers of them.

That statement goes against the grain of over 15 years of group management practices, doesn’t it? But think about it: like any service you provide, there is both an infrastructure aspect and an application aspect. With Microsoft Exchange, for example, IT provides the email service, but IT does not read and respond to email for everyone. So why should it be any different when you think of Active Directory as a directory service? Active Directory groups are just another service. You provide the service (infrastructure, replication, availability, etc.), and the rest of the business does the work within Active Directory.

Given the details required to properly manage the security for a given application, it makes sense that IT needs the day-to-day support and assistance of the rest of the business in order to truly keep the access provided by Active Directory groups as secure as it possibly can be.

For more information about shifting the responsibility of managing Active Directory groups to the rest of the organization, check out our whitepaper, The Importance of Collaboration Between IT and Business for Effective AD Group Management.