The reason why I asked is to make sure you can make changes without affecting everyone.  I'm not entirely sure, but to me it sounds like you are putting too much into it, which is why you're running into problems.

- Install a fresh copy of DNN so that you get all the default settings.
- Modify the web.config file to ONLY add in the correct database information, make no other modifications from it's original state.
- Set the NETWORK SERVICE account to have FULL access to the DNN subdirectory.
- Test the DNN install to make sure it is working properly with DNN accounts.
- Install the AD Authentication module.
- Modify the permissions on the WindowsSignIn.aspx file in IIS.
- Go into the Authentication Module configuration page and enter all the information for your domain.  When you submit the information, it should give you a nice green icon saying it was setup correctly.  If you don't get that, check your settings.
- Add your website in as a trusted or Intranet site in Internet Explorer on a workstation that is part of the domain and browse to your website to test it.

What I'm basically saying is that the DNN AD Authentication module works perfectly with very little configuration to DNN.  Too many people get caught up in the impersonation settings and/or the Windows/forms authentication settings, etc...  If your domain is setup like you said, you should not need to do ANY modifications to your web.config file outside of setting your database information. 

What do you mean by this?  How do you have that part setup?   The account you use to access the SQL server should be a DBO of the database, and probably should not be an account you use for anything else (for security purposes).  The account information for the SQL access should not in IIS, but in the web.config file. 

The system works but you can only log in with one account?  That doesn't sound like it is working to me...  If you follow the directions on how to install DNN and the AD provider, the system will work fantastic.  If you keep changing the directions to something you think will work better, then you are no longer following the directions and you will experience problems.

Also, having multiple levels of protection is one of most important things in security... If you use the same account to manage both your SQL server and IIS, you're basically putting all your eggs in one basket, if any one point is breeched, "everything" is lost.  The web.config file is protected at many levels, it is not as vulnerable as you might think.  

Create a seperate SQL account that "only" has access to the DNN database (do not make it a sysadmin account), and use that in your web.config file.  Then run your IIS system back at the default permissions set.  That will give you several levels of protection.  If any one of these levels are breeched the others will still hold, making any bug exploit nowhere near as disasterous as it would be if everything was run under one account.