ASP.NET Active Directory Nested Authorization Issue - asp.net

Question

I'm working on an internal ASP.NET application that uses an Active Directory distribution list for managing who has access to the web site.
However, due to the fact that this distribution list could contain both users and groups, I had to develop a solution for checking to see if the current user is able to access this site (e.g. They could be in a group that is a part of this distribution list). The default Windows authentication mode does not support this type of hierarchical structure.
My question is how can I ensure that every resource in this web site can only be accessed by those who are in this distribution list? I am currently using a custom attribute applied to every page that checks the user's credentials and redirects to a 'No Access' page if they are not a member of the DL. However, I'm thinking that there must be a better way to do this that doesn't require me to use the attribute on every page which is created for this site?
Any help is appreciated!

Answer 1

The simplest fix to avoid duplication without changing the underlying authentication scheme - Instead of using it on every page, you could do hook into the Session_Start event and store the authentication value there, and check this value on an appropriate event of your master page if you have one. (again this is least effort and an answer directed at your direct question)

Answer 2

Update (Response to Comment)
To manage permissions for a group use the following xml block. Note that this will do what you mentioned in your comment on the other answer: this will block image files, etc... too.
<authorization>
<allow roles="domain\group"/>
<deny users="*"/>
</authorization>
Original
The best way is to stick to the native options: Why not use the Membership Provider? The ASP.Net membership provider can handle all of this for you. You can specify which groups can access which pages/directories using web.config files no sweat.
Check out these links for further guidance on implementing the Active Directory membership provider:
http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx
http://blogs.msdn.com/b/gduthie/archive/2005/08/17/452905.aspx
This XML shows how you can configure your web.config, once you are using the membership provider, so that it allows/denies permission to files and folders (I got this from http://support.microsoft.com/kb/316871):
<configuration>
<system.web>
<authentication mode="Forms" >
<forms loginUrl="login.aspx" name=".ASPNETAUTH" protection="None" path="/" timeout="20" >
</forms>
</authentication>
<!-- This section denies access to all files in this application except for those that you have not explicitly specified by using another setting. -->
<authorization>
<deny users="?" />
</authorization>
</system.web>
<!-- This section gives the unauthenticated user access to the Default1.aspx page only. It is located in the same folder as this configuration file. -->
<location path="default1.aspx">
<system.web>
<authorization>
<allow users ="*" />
</authorization>
</system.web>
</location>
<!-- This section gives the unauthenticated user access to all of the files that are stored in the Subdir1 folder. -->
<location path="subdir1">
<system.web>
<authorization>
<allow users ="*" />
</authorization>
</system.web>
</location>
</configuration>

Answer 3

I ended up rolling my own security class for checking to see if the currently logged in Active Directory user has access.
I used the GroupPrincipal.GetMembers function in the System.DirectoryServices.AccountManagement namespace. This overloadedd method which takes a boolean value can be used to search for users recursively (satisfying my groups-within-groups issue).
The security class is a Singleton, and the list allowed active directory users is stored inside the Singleton to keep this access check fast. I chose a Singleton to ensure that there was only 1 copy of this list on the server. I stored the list of allowed users as a SortedDictionary, which increased look-up speed greatly.
When a user who does not exist tries to access the site, the original user lookup will come back negative. At this point, the security class refreshes the users list, saving the timestamp of this refresh to the list of allowed users. The method endures that this refresh is done at most once every 10 minutes to prevent users from hammering the site (and keeping the site responsive for other users).