Depends on the application, but I immediately see the following problems which may or may not be problems for you depending on what you're doing.

1. The strategy described indicates that you have to create new database connections for every request, which won't scale very well.
   
2. I'd have concerns about vendor lock-in. Particularly if your implementation is IIS-dependent and your network has problems with viruses and the like.
   
3. How reliable is Active Directory? I've heard bad things over the years and happen to know of a couple of major disasters associated with it. But that's anecdotal, and I don't know what your needs are.
   
4. Usually there are tables (eg ones with user information) where users need to be granted/denied access per row. So you'll likely need to build the usual kind of permission scheme ANYWAYS. Having multiple permission scheme's is a good way to lead to confusion, and confusion is a Bad Thing when it comes to security.
   

Against all of this I can name at least one big positive - which is that the damage from compromises in your web application are more likely to be automatically contained. For instance if most users don't have permissions on whatever table has credit cards, then an attacker will have a lot more trouble getting that table to dump. A second positive is that you may have to do less work to set up a new user - just let the sysadmins handle it in Active Directory.

For a low-volume intranet application at a site that has accepted vendor lock-in, depends on Active Directory anyways and has good Windows administrators, your strategy sounds reasonable to me. But if any of those assumptions are loosened (or you wish them to be loosenable in the future), then I'd not be as happy with it.

Cheers,
Ben

The single worst-performing SQL query that I've ever written was one whose job was to propagate permission rules to figure out exactly who could do what, when. It scaled like O(n^5). I broke it into several pieces and it improved to O(n^4). It got slow again and we moved it to a better machine.

It was a lot more flexible than the one you describe, was simple to use, and was very fine-grained. But the logic behind the scenes to make it work was a bear. But it did work well for a few thousand users with hundreds of permissions each.

The reason that I needed a complex scheme was that I needed to grant access to a lot of people based on the kind of data they were accessing, the kind of company they were associated with, the terms of their subscription (when your term expires, so does your permission), and our decisions about when to change specific parts of our site between being premium and standard. And I had to keep it simple enough for our sales reps to be able to use the system. "Why don't I give you a 30 day free trial..."

Cheers,
Ben