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