Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

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 ForumsAuthenticationAuthenticationIssues with new Dnn 4.5 install and AD moduleIssues with new Dnn 4.5 install and AD module
Previous
 
Next
New Post
4/12/2007 6:32 PM
 

First off, I'd like to thank the whole community for such a great openSource CMS app. I have been evaluating a couple of options for the Intranet portal that I have been assigned to and DNN is definetly a contender. Here is what I have come up with:

Office Sharepoint Server 2007: great AD integration and document management + workflow. Very Un-sexy, slow. It's, well, un-appealing.

Ektron CMS400.net: Very cool, flexible. $10,000 for initial license but licenses are very restrictive. They nickel and dime you once they have you locked in

Dot Net Nuke: I will qualify that I'm a geek and I love openSouce software, but that said, I'm pretty impressed. 4.5 is very sexy, easy to set up (for the most part) and the forums have alot of support. Document management seems weak from what I see, but I'm sure there is a module out there for $60 that would link to external sources (network shares) and do some of the workflow things that SharePoint does. If not, I always have the option to write it!!!

Anyways, this post is about the one thing I haven't liked in DNN, which is the Windows Authentication (AD) module.

 

After I installed DNN 4.5, I tried turning on the AD Authentication. I followed the instructions that I finally found here. There were some other posts on this forum, but they weren't as easy to understand as what stuart has posted. Where I was stuck was the error I was getting:

 

Accessing Global Catalog:

FAIL

Checking Root Domain:

OK

Accessing LDAP:

FAIL

Find all domains in network:

Could not access LDAP to obtain domains info.

Logon failure: unknown username or bad password

 

That was really frustrating until I read a comment after stuarts description that I could just ignore that error. So, for novices: Ignore that error!

My current issues are as follows:

- How do I link a host/super user account with an AD created user? I have had to log out, then log in as the host account, and then make my changes. What is frustrating, is I have to clear my browser cache afterwards to get the AD to pick up my windows user after that.  The Auto-Authenticate doesn't work, and I can't use my windows account credentials in the login screen! arggh!

- The display name and other user info (first/last name etc) aren't getting picked up from AD. I found this posting that supposedly fixes that bug and syncs AD and DNN user accounts, but I couldn't get it to work no matter how many times I reset IIS.  Sorry Micheal, I tried.

Anyway,  thanks again for the great product. If I can get the AD stuff sorted, I think I'm going to recommend DNN for the portal.

 

 

 

 
New Post
4/12/2007 9:41 PM
 

Dinsdale, just as an initial check, are the First/Last name populated in the user object on your AD? It's possible that you may have to do what I had to in our environment and use authentication in the web.config. If you look around line 110 of your web.conifg there should be a section called <authentication mode="Forms">. Right below it, commented out will be the <identity impersonate="true" /> section. What I had to do was uncomment that line and add a domain user credential. I don't have my dev system at home tonight so I don't have an exact example from a web.config but in the end it should look something like this:

<authentication mode="Forms">
       <forms name=".DOTNETNUKE" protection="All" timeout="100080" cookieless="UseCookies" />
       <identity impersonate="true" userName="domain\username" password="password" />
</authentication>

Then you have to give that user the same rights on your DNN directory that you gave NETWORK SERVICE. What I think is happening is that while DNN will validate the user credentials against the AD and allow you to logon it doesn't have enough access to pull that information back across and insert it into the DNN tables. Basically AD is saying, "Yup, that's a valid user but that's all I'm going to tell you." Why I'm saying that is that while I was debugging the 4.5.0 AD update and stepping through the code there was an object called objAuthUser that gets filled with the AD information and it kept returning a value of Nothing but still logging my user in. For the life of me I couldn't figure it out because I knew what it was supposed to return and it always had before. I went so far as to wipe out my AD install and database and started fresh. It was while I was in the middle of wiping out everything that I remembered that I hadn't setup the impersonation when I upgraded the install to 4.5.0. Finished the fresh install, set the identity impersonate, and, wizbang, objAuthUser was now filled with data.

As far has linking a Host account with an AD user..... I've never tried it myself, just giving a user account admin rights. I'll give a shot tomorrow.

If AD is working correctly you should be able to login with your domain credentials on the Login screen. Just remember to enter your username as domain\username <-- just in case you aren't. .

 
New Post
4/13/2007 9:52 AM
 

Hi Mike,

Thanks for getting back to me. The user objects are definetly populated in AD. Before I posted yesterday, I had the network admin show me the users in the management screen to verify (cause I'm a jerk).

I'll try your impersonation suggestion, but the user that DNN is using to validate the login credentials is an AD administrator account so I don't see why it wouldn't have enough permission anywhere to retrieve the first/last name. That said, you did the debugging and I didn't so I will try it out. I'm just not terribly comfortable leaving a user/password in any file that has that much permission on our security system. Maybe I'll try a downgraded user for credential verification. Either way, I'll post my results and let you know.

 

Cheers and thanks again.

Dinsdale

 

 
New Post
4/13/2007 1:00 PM
 

Mike,

Thank you for the help. Your suggestion fixed the problem. The information in AD is being propagated in the DNN database. I deleted the users created and they re-created themselves with all AD data being propagated. For ****s and giggles, I deleted the first/last name of a user and then logged in again and the AD module upgrade did in fact re-sync this data. Nice work Stuart and Micheal!

Adding impersonation to the web.config also fixed the error that I was seeing in the first step of the setup. Stuart: maybe you could add that to your AD setup description? The correct syntax is as follows:

     <identity impersonate="true" userName="DOMAIN\username" password="pwd" />
    <authentication mode="Forms">
          <forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" />
     </authentication>

Note that the impersonation line goes inside the <system.web> element and outside the <authentication> element.

I was also able to downgrade the AD validation user role to a standard user and still achieve the same results. I changed it in the Admin\Authentication page and also in the identity element as noted above.

So, onto my last AD issue:

There is a user that I cannot delete (I don't get the little red "X" in the user administration screen). I added my AD created account as a site administrator and I can no longer delete that user, nor can I revoke admin rights. wtf? This may have been caused by something I did; I might have deleted the original admin and then re-created it. I can't remember if it was this install or the previous one I did that in. Anyway, I cannot remove this user no matter who I am logged in as (myself, admin, host). Any suggestions? Is there a way to delete this user from the backend?

Once again, thank you, thank you, thank you!

Dinsdale

 
New Post
4/13/2007 1:28 PM
 

I was thinking about it after I posted last night but I haven't had a chance to really check things out so the following may just me blowing smoke out of my butt.

In theory you're correct that the username/password used in the Authentication screen should be all you need and you shouldn't need to use impersonation in the web.config. However it appears to me that even though there's a valid user the .NET process user (either NETWORK SERVICE or ASPNET) is what's actually making the contact with the AD and because it's not a domain user account the AD won't release the information.

As for having an admin account's credentials in the web.config, I totally agree with you. We use a totally separate account that just has a normal user's rights in the web.config. If someone managed to get those credentials it would do them absolutely no good.

Oh, and as far as giving a user Host rights. Open up the Users table in the database and find the user you want ot have Host rights for. Change the IsSuperUser to True and that user will have Host permissions.

 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsAuthenticationAuthenticationIssues with new Dnn 4.5 install and AD moduleIssues with new Dnn 4.5 install and AD module


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.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out