I figured that they were the same issue.
So here is what is currently happening with my intranet.  Any user that currently has an account in DNN is not having any problems at all.  If I manually create an account in DNN and add the new user to the proper Roles they have no problems.  If a new user hits the intranet but does not already have an account they get "The page isn't redirecting properly" in Firefox.  If I create an account for the new user but do not add them to the proper Roles in DNN they are not added to those Roles automatically.
So it would seem that DNN is not able to retrieve any AD information at all but is relying on the windows credentials that are passed to it.  I'm guessing that DNN does not do an additional check on AD when a user logs in but simply relies on windows to prove they are authenticated.
This began happening to me after an upgrade from 3.1.1 that had ADSI authentication working perfectly.
I have the following ADSI related code in my web.config:
    <identity impersonate="true" />
    <authentication mode="Windows">
    </authentication>

<add name="Authentication" type="DotNetNuke.HttpModules.AuthenticationModule, DotNetNuke.HttpModules.Authentication" />

    <authentication defaultProvider="ADSIAuthenticationProvider">
      <providers>
        <clear />
        <add name="ADSIAuthenticationProvider" type="DotNetNuke.Security.Authentication.ADSIProvider, DotNetNuke.Authentication.ADSIProvider" providerPath="~\Providers\AuthenticationProviders\ADSIProvider\" />
      </providers>
    </authentication>

I just checked for \Providers\AuthenticationProviders\ADSIProvider\ on my server and it does not exist.  Is this a problem?  It's not in the original install zip file either.
Much thanks,
Nathan

I've been scratching my head over these web.config settings for a couple of years now, so I went to look up exactly what they are...

Here is what I have determined (paraphrased):

Windows vs Forms authentication:  If you select Windows authentication, IIS will do all the authentication work.  If you select Forms authentication, you need to add code to your application to do the authentication.  If I read this right, you will probably always want Forms Authentication with DNN, so the login procedure can be controlled by the application, not IIS.

To use identity impersonation or not:  If you leave the line commented out, the application runs as the user if they are able to authenticate locally, otherwise as the user IIS runs as.  If you uncomment it, and leave it as <identity impersonate="true">, your process will always run as the user that IIS runs as.  If you expand that to include a username and password, the process will run as that user instead of the IIS user.  To me, this seems like a duplication of effort, as you've already entered a username/password in the Admin->Authentication menu that you want to use to access the AD with.  I think you only need to uncomment this line in the first place if your webserver is locked down tight, and has trouble doing authentication calls without help.

It would be great if the new provider could be written so that you don't have to make any changes to the web.config at all!