In-Depth

Q&A: Workarounds for Active Directory's Limitations

Too often, Microsoft’s Active Directory and its Group Policy Objects don't offer the granularity security administrators need.

• By Mathew Schwartz
• 07/12/2005

Many organizations use Microsoft’s Active Directory and its Group Policy Objects to manage security settings centrally. Yet such an approach often doesn’t provide needed granularity—at either user, small-group, or location-based levels.

To discuss workarounds, Security Strategies spoke with enterprise policy management software vendor FullArmor’s Rich Farrell, CEO, and Danny Kim, chief technology officer.

Does Active Directory lack security granularity?

Kim: Yes. You can target a user policy to a computer, user, or group. That’s it. So for [a large aircraft manufacturer], which has 600,000 users, you need something more targeted than that.

Can’t the Group Policy Objects (GPOs) in Active Directory handle the different, needed user policies?

Well, even Microsoft has over 800 GPOs in their environment. Internally, they’ve been told there’s some theoretical number, somewhere over 999, where they don’t know what will happen if they go over it. And even [the manufacturer] has over 600 GPOs.

If you ask how many are you actually using, and how many are exception cases that you had to create just to get around something, the number is usually around a dozen. So … most of the time they’re using [so many] because they need to get around some inflexibility in the targeting or intelligence, or lack thereof.

What’s wrong with using GPOs to create workarounds?

It’s actually becoming a significant cost for them. … Each GPO is four or more megabytes in size. That’s a lot of data replicating around your environment that doesn’t need to be there. The other thing is the cost of change management.

Beyond applying more granular policies at the user level, what are the other big problems organizations are trying to solve with Active Directory, but can’t?

There are two. The first is application rights management. About 95 percent of the companies I’ve talked to have told me that one of the biggest security problems they have is … [having] to elevate an end user to local admin status, because they need to run a legacy application that requires local admin status. In Windows … there’s no concept of application rights management—being able to extend rights to an application to a user. …

Now, there’s also Microsoft Least User Privilege or Least User Access. They’re actually requiring you to rewrite your applications so that the application knows the rights it needs, without having to give a user full privileges. … But at companies like [the aircraft manufacturer], they have 6,000 or 7,000 customer applications, in-house applications, and so on. They said, "We can’t go back and touch the application, because the people who wrote it are retired, or even dead." But it was coded so it required local admin access.

How does your software address that?

Now, let’s say there’s a legacy application, or even Internet Explorer. I can extend a right to use that application. But the user will just remain a local user, and the rights will just be elevated at run time. So the user never got any more rights than needed; the application got the rights, though just when needed to run. … This is a huge lifesaver for companies, because they’ve had to give more security privileges than necessary.

So organizations needed a workaround?

Farrell: The big issue with having over-privileged applications is if there is a worm or virus or what have you, and that infects a desktop, if it has admin privileges, then it can take down the network or do nasty things.

How do your policies interface between Active Directory and a client PC?

Kim: You would set the policy centrally in a Group Policy environment, but then all the work is done at the client. … So the client is able to dynamically elevate or restrict these applications. We don’t have any memory-resident processes that have to be resident in the client. It’s literally a client-side extension—a DLL—that resides on the client.

So what’s the other big Active Directory pain point?

The second major pain point we’ve seen is removable storage drives—things like USB drives. About five or six months ago when we visited [a major U.S. financial institution], this was one of the things they really requested: the ability to lock down or put access rights on any removable drives. The reason they gave us was because their employees were coming in with these drives, which were up to a gigabyte, and they’re removing sensitive data. I heard that, then I asked around. And people said, "Yes, this is a huge security hole, but I’m not telling my director"—these are MIS guys talking—"because we don’t have a solution yet."

It’s a major problem because you can lock down the desktop, but then if someone puts in a USB key, they can literally download all of the critical data and walk out the door. …

Now, we can assign rights to removable storage. So, for example, if Rich gets on your computer and tries to download something, he has no rights. Or he can only upload data. And we distinguish between a USB storage device and a USB printer. There are other solutions out there that just disable the whole USB port, but that’s not so useful. So this was another big security limitation that people have been asking for and that we’ve been able to address, through extensions of Group Policy.

Farrell: Also because we do this through Group Policy and Active Directory, you set this centrally and it gets enforced across the enterprise, automatically.

What about handling devices which aren’t yet managed by Active Directory?

Kim: We created a technology … [to] take a Group Policy in Active Directory and create an executable out of it. Once we do, all the functionality that’s inside that Group Policy, all the logic, gets wrapped into one .exe, and you can run it on machines that are not part of Active Directory, and apply group policies to them.

So Active Directory used to be this private block where Group Policy was a membership benefit. What we’ve done is said we’re making this private group public.

Related Article:

Microsoft Discusses Longhorn Security
http://esj.com/enterprise/article.aspx?EditorialsID=1365