I'm a first time dnn user, so be gentle. I'm working on migrating an existing site for a small college (here: http://www.york.edu) to a new dotNetNuke install (currently here: http://web.york.edu), and I have some questions about the security setup.

We're using Active Directory authentication, which I have installed and appears to be working... mostly. Here is what I'm not clear how to do:

• It wants me to create Active Directory groups with names that match my dnn groups. No big deal... except for the Administrators group. We have a few people that need to be in this group, but we don't want to add them to the built-in Administrators group in Active Directory. That would be bad. When everything is up and going, we'll have a web team outside of IT that will own the site, and needs to be able to do things like install Extensions, etc, and we want to control this from within Active Directory.
• Even users who are in the administrators group don't end up with superuser or other other important privileges. 
• When setting up individual pages, we want to give each of our coaches access to a page or several pages for their teams... preferably an "area" defined by a single parent page where they may even be allowed to create additional pages that are children of that page, but not create pages elsewhere. We want the main athletics office manager/Athletics Director to have access to the individual pages of each team by virtue of setting up Active Directory groups for the teams as children of a larger Athletics group that the office manager would also belong to (nesting). We want to control this access from Active Directory. Athletics is not the only nested example, but it's the biggest and most complicated. I'm not sure what that might look like matching it to DNN. 

Help on any of those issues is appreciated.

It seems weird to me to need to directly manipulate the database and go around/subvert the application logic itself... I've worked in shops where that kind of thing could get a guy fired. That said, I'm very comfortable with the procedures involved, and as this has not gone live yet I'm willing to give it a shot. I can try the database change today for the AdministratorRoleId field, and if it somehow breaks things I can restore to last night's backup and no one will ever know (Of course I'll be sure to post the results).

One more question: as it stands, this is going to require creating 18 new and related groups in the top level of our domain tree. That's a lot of clutter. Is there anyway to have the groups themselves listed under a separate OU that is devoted to this purpose, even though the users themselves are at the top level?

I agree that you shouldn't need to directly manipulate the database but in my quick look around I couldn't find anywhere you could set it in a portal. I suspect it's a feature that was either dropped or never implemented.

I'd have to look at the code (as I haven't looked at the logic for this section in quite awhile) but I'm suspecting I'm just looking at whether the role has admin rights and not specifically if it's the administrators role. A quick test would be to see if administrators on the domain are now being added to the administrators role in the portal.

Edit: I missed answering your question about users in the OU. Yes you can do that. It takes the user's information and checks for any groups the user belongs to even if it's only as a child to that group. I.E. You've got the parent group called Coaches and it has as a member the group HockeyCoaches. If the user is a member of HockeyCoaches they also are considered a member of Coaches even though they aren't a physical member of that group.