New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsAuthenticationAuthenticationWindows Authentication Not Working In DNN 4.5.1 OR 4.5.2Windows Authentication Not Working In DNN 4.5.1 OR 4.5.2
Previous
 
Next
New Post
6/1/2007 2:34 PM
 

notepad wrote

I am having the same problem on my intranet and I applied the fix referred to in the post referred to above and it did not fix the problem, new users that login do not get an account created in DNN and get the "redirect loop" errors.
Another issue that I noticed was that AD group to DNN roles membership is not working.  For instance users in the Staff group in AD do not get automatically added to the Staff role in DNN even if they already have a DNN account.
Any help would be greatly appreciated.

While they seem like two seperate things, they are the same issue.  You are not going to get AD users added to the correct DNN groups if they are never authenticated in the first place! 

Take a few steps backwards and try your trouble-shooting.  Restore your web.config to the original settings, and try one thing at a time.  The redirection loop can be a number of things, but is also an indicator of a bad setting in the web.config.

You should also know that the "AD Fix" doesn't fix non-working AD authentication issues, it just fine-tunes it.  If you cannot get AD authentication working with the original files, applying the AD fix isn't going to help you.

Go back to the basics... Revert the web.config to the original settings, change the permissions on that one file, and make changes in the Admin->Authentication menu to start with.  I have the feeling you changed too many things at once.

 
New Post
6/1/2007 3:35 PM
 

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


The greatest and the least among men have this in common: a high priority vigorously pursued.
 
New Post
6/1/2007 3:54 PM
 

The redirection error is fixed in 4.5.3 so try upgrading to that first.

On our intranet I left the authentication mode at its default of Forms and added a userName="domain\username" password="password" to the identity impersonate line.

Don't worry about the "missing" file. It's all handled in the .dll files in the bin directory.

 

 
New Post
6/1/2007 11:45 PM
 

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! 

 
New Post
6/4/2007 11:27 AM
 

mikeh,
The issue that I'm experiencing is not the "login page redirect after signin".  As mentioned above I applied the fix.  These two issues have the same symptoms from the users perspective but are very different issues.
On my intranet IIS handles authentication automatically based on NTLM authentication.  The user does not enter a username/password to get into DNN.  IIS directory security is set to integrated Windows authentication (anonymous is unchecked) and in Admin -> Authentication it is able to connect to Active Directory.

Accessing Global Catalog:
OK
Checking Root Domain:
OK
Accessing LDAP:
OK
Find all domains in network:
1 Domain(s):
cjryouth.org (CJRYOUTH)


So authentication is working (current users have no problem) but DNN is not pulling information from Active Directory when a new user logs in.  No errors are logged.


The greatest and the least among men have this in common: a high priority vigorously pursued.
 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsAuthenticationAuthenticationWindows Authentication Not Working In DNN 4.5.1 OR 4.5.2Windows Authentication Not Working In DNN 4.5.1 OR 4.5.2


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.