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 ForumsAuthenticationAuthenticationConfirmed: Intranet AD autologinConfirmed: Intranet AD autologin
Previous
 
Next
New Post
11/8/2006 9:37 PM
 
bill_ward wrote

To force automatic signin, just change web.config to use windows authentication rather than forms authentication.

Oh, so that's what that tag is for.

I must be blind because I cannot find the list of changes you referenced in another thread. Consequently I have problems with auto role assignments. Where did you get the changes from? (preferably source and compiled). If someone can point them out to me I'd be very grateful.

Sorry if my link wasn't very accurate.  Here is the link to the download site copied from the thread I tried to refer to, with credit to slhilbert, the orginal poster.

http://www.getyourowntots.com/Projects/DNNProjects/DNNADFix/Download/tabid/99/Default.aspx

I have an AD group X whose members are those in AD group Y. I also define roles X and Y in my portal. People who are in AD grout Y are automatically put into role Y. However, AD knows these users are also in group X, but DNN does not appear to put the users into role X. Still puzzling over this one. Hopefully the above problem will resolve this.

My guess is that the logic in the AD module only looks for direct AD group memberships (i.e. for DNN group X, is there an AD group X, and if so, is this user in it?) and not nested group memberships where the user is not directly in the group.

Without looking, there is probably an fairly simple recursive search that would descend in to child groups to look for the user that could be implemented in the AD module.

Since I upgraded to DNN 4.3.5, the concept of "display name" has appeared. This is not populated from the AD and so no user name is displayed to the user to show who is logged in (and to have something to click on to make changes). Consequently, I have to make edits from the host account whenever a new user uses the portal. Mildly annoying.

I believe this is one of the issues addressed by the fixes above.  The data is refreshed each time the user logs in.

 
New Post
11/9/2006 12:33 AM
 

I cured my blindness and found the link to the patches. They seem to improve thinngs a lot, thanks. Also, I forgot one other point - you have to uncomment out one line in the web.config. So change the line that comes as this...

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

Bill

 
New Post
11/9/2006 8:00 AM
 
ukedude wrote
 DanBall wrote

1a:  This is a problem inherint from using that Module, and would definitely be something I'd add as a fix in future versions.  I did a SQL query (from Host menu) to set an e-mail address on all accounts that didn't have an e-mail address.

Ah, that is an excellent idea.  I attached to the DB file using SQL Server 2005 management tools, but that seemed to screw up DNN while I did so.  I didn't want to mess up my DB.

 2a:  Why do you consider it a recipe for disaster? 

This is for our corporate Intranet with hundreds of users.  If I create an alias for the server, something like "intranet", I want users to be able to just enter "intranet" in IE and have it log them in.  We would get many Help Desk calls about that URL.  Also, linking back to the Intranet from other web applications becomes problematic.

I want to get it down to just typing "intranet" in IE, which leads to...

 2b:  If you're running in complete AD integrated mode, you shouldn't "need" to redirect your users to that URL.  Simply browsing the website should log them in.  You might need to set your domain as a "Intranet" or "Trusted" site though first.

I tried this, but I may not have done it right.  I tried to add my server name, say "intranet" as a trusted site.  That did not appear to make any difference--I was not logged in when I went to the root URL (http://intranet).  I still had to go to http://intranet/admin/WindowsSignIn.aspx before I was automatically signed in.

There may be a simple fix for this, but I am not sure what I am missing.

 3a:  If you want to remove it, modify the skin and remove the [LOGIN] token.

Ah, another good point.

 3b:  True, that does make it difficult.  But, you can log in as host from the login menu (put the login module on a hidden page if you want), even if you are currently logged in.

That is an excellent idea.  I did not know one could log in again before logging out.

2a:  Good point.  You could also force that URL out via GPO as a "Favorite", so they can use it upon request.

2b: Try it out manually in IE first, on some systems you need a variant of the URL that isn't quite obvious.  If you add it manually to IE, and it works, then it should work if you force it out via GPO.

 
New Post
11/9/2006 8:03 AM
 

Here is more information after more testing:

First, I confirmed that in IE7 (which is what I have on my laptop), my server is automatically detected as a "Local intranet" site.  I can tell becuase at the bottom of the IE window it shows the zone in which this site is operating.  I also confirmed that the security settings for the Intranet zone are set to "Automatically login only in the Intranet zone".  I believe if this were not the case, even navigating to the http://myserver/admin/security/WindowsSignIn.aspx URL would not work.

With that confirmed, I tried to make headway on automatic login by visiting the URL http://myserver (rather than having to add the specific path to the Windows login page).

NOTE: After each of the changes below, I restarted the IIS Admin Service just to be sure there were no residual effects of the previous configuration.

First, I tried changing <authenticaltion mode="Forms"> to <authentication mode="Windows">.  Specifically, I commented out the existing section in web.config and uncommented the section after:

<!--
<authentication mode="Forms">
  <forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" />
</authentication>
-->
<identity impersonate="true"/>
<authentication mode="Windows">
</authentication>

This had an adverse effect.  All I get now when loading http://myserver is the following error:

DotNetNuke Upgrade Error

The Assembly Version ( [ASSEMBLYVERSION] ) does not match the Database Version ( [DATABASEVERSION] )

ERROR: Could not connect to database.

A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)

I undid my changes, and it reverted to the previous behavior.  So that part, at least, is reproducible.

Next, thinking that the problem may be due to the <identity impersonate="true"/> tag, I left it commented out.  In this case, I reached the Home page, but I was not logged in.  Additionally, entering the URL http://myserver/admin/security/WindowsSignIn.aspx also did not log me in.

So, in conclusion, I have not been able to confirm any configuration that allows automatic login without visiting the URL http://myserver/admin/security/WindowsSignIn.aspx.  I am happy to try any ideas other may have.

 
New Post
11/9/2006 8:45 AM
 

What is the status of your <!--add name="Authentication" type="DotNetNuke.HttpModules.AuthenticationModule, DotNetNuke.HttpModules.Authentication" / --> line? 

This line need to be "uncommented" in order for auto login to work, and is relatively unrelated to the windows or forms login setting.

Also, the autologin via URL "will" work even if your IE settings are not correct, I know that one from trial and error.  It took me awhile to get the zones entered correctly here.

 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsAuthenticationAuthenticationConfirmed: Intranet AD autologinConfirmed: Intranet AD autologin


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