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 ForumsAuthenticationAuthenticationAD Provider 01.00.04 issuesAD Provider 01.00.04 issues
Previous
 
Next
New Post
5/26/2008 11:49 PM
 

The source is available on my site (http://dnn.gmss.org). In the source version there's a file called ActiveDirectory Source Files.resources. You can either extract that from the .zip and rename from .resources to .zip or you can install it on your dev portal and the files will be extracted automatically.

 
New Post
5/27/2008 2:15 AM
 

Great news...it's now working.  Here's the story:

I had some trouble uninstalling the provider due to file permissions on my website (related to me having it checked into source safe).  The uninstaller showed errors during the uninstall, but the provider disappeared from the Host Settings screen.

I tried installing the source of the provider by renaming the resources file to be a .zip, but the install failed because there were some files missing (the ascx files etc) and there was still some data in the database (foreign key exceptions during install).

At this point I figured the database was completely out of sync, so I had no qualms deleting the authentication data by hand (even though I don't know all the places it writes data).

Again, I attempted the install of the source provider, but it failed because of missing files.

At this point, I dug out the source version of DNN, added the authentication provider source, brought in the missing files, and compiled. 

Then I tried browsing to the new site, but it kept redirecting to my original site.  I tried changing the portalalias in the database, but the site wouldn't even load then.

I figured I may be able to attach the source project to the running instance of IIS (given it's all on my local client).  It seemed to attach okay.

I then repeated my test (login as user).  I was disappointed that my breakpoint didn't get hit in the source I'd attached, but I noticed the first and last name were assigned correctly.  Checking the roles assigned to the test user showed me the role was also assigned.

Thinking the data was left over from a previous test, I deleted the user from the role, then deleted the user, logged out, and repeated the test.  Again, it logged the test user on with the correct first and last names, and assigned it to the test role.  Hooray!

I've since confirmed that removing the user from groups in Active Directory causes the provider to correctly synchronise when they log on (i.e., the user is removed from the role in DNN).  So it looks like everything is working correctly!

Incidentally, I can now attach the source to IIS and hit my breakpoints.  I had to manually copy the compiled DLL to the website folder before this would work.

Summary

Given that no code changes were required to get the provider working again, I can only think of three reasons why it wasn't working before:

  1. PEBCAK - Did I have the wrong version of the provider installed?  It's unlikely, but it's possible.
  2. Provider install/uninstall issues.  I previously had beta 1.01.03 installed.  I uninstalled it before installing the 1.01.04 beta.  While the install messages and version number in the packages table indicated it had installed, the problem persisted.  It wasn't until compiling the provider source on my own machine that the problem corrected itself, without code changes.  I think this points towards a DNN environmental / database configuration synchronisation issue on my machine.  Given I have a brand new PC with a virtually vanilla version of DNN on it, the only place I can consider this occurring is the provider install/uninstall.
  3. The provider configuration itself may be bad.  I think this highly unlikely, but it may have something to do with #2.

Because I can no longer get it to fail, I unfortunately can't help anyone else having this issue other than to say it looks to be a DNN environmental issue.  The only advice I can give is to compile the DNN source with the provider source on your development machine and synchronise your website folder.  It certainly doesn't seem to be a problem with the provider itself.

Carl.

 
New Post
5/27/2008 4:25 AM
 

 

*Dr Farnsworth voice on*

 Good news everyone,

*Dr Farnsworth voice off*

I have figured out what the configuration issue is that causes both the incorrect synchronisation of the users first and last name, and the synchronisation of roles to fail in the provider.  It has nothing to do with the install/uninstall as previously thought, and it's something very, very simple.

I noticed during the configuration of the authentication provider (on the Admin | Authentication screen) that if I didn't have impersonation switched on, the configuration would fail.  I had inadvertently left impersonation switched on in my web.config, and had just taken it out (for security reasons) when I noticed the authentication provider began to fail again.

Without impersonation, the authentication provider cannot seem to read the user details from AD, so they don't get synchronised properly.  Further, the internal method that provides the synchronisation of the user roles doesn't fire when there is no impersonation.  This means the user is able to log on, their first and last name are set incorrectly, and the roles are not synchronised.

Looks like you need impersonation turned on; and in my limited ASP.NET experience this means your web.config must contain a line such as:

 <impersonate="true" userName="CONTOSO\jbloggs" password="somethingSilly" />

I found a nice article in MSDN that talks about encrypting this in the registry using a tool called aspnet_setreg.  I've been able to use this to make my web.config more secure (i.e., not having a username and password in it) and instead using registry keys.  The only gotcha I found with this method is that you need to go into regedit once you create the entry, and give the ASPNET user read access.

I'm wondering if there is a better way to get the provider working correctly? 

Carl.

 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsAuthenticationAuthenticationAD Provider 01.00.04 issuesAD Provider 01.00.04 issues


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