Products

Evoq Content Overview Content Creation Workflow Asset Management Mobile Responsive Personalization Content Analytics SEO Integrations Security Website PerformanceEvoq Engage Overview Community Management  Dashboard  Analytics  Member Profile Gamification Advocate Marketing Community Engagement  Ideas  Answers  Discussions  Groups  Wikis  Events Mobile ReadyDNN Support PackagesEvoq: CMS FeaturesEvoq OnDemandCompare DNN's CMS Products

Solutions

Content Management SystemMulti-Channel PublishingDigital MarketingOnline Community ManagementIntranet Software SolutionOur CustomersPrime

Resources

Test DrivesSchedule A DemoDocumentation CenterWebinarsWhite PapersProduct ManualsRequest PricingData SheetsCase StudiesEvoq Preferred Products Content Management Ecommerce Forms Identity Management and Authentication Site Management Social Themes

Partners

DNN Partners Partner Directory Become a DNN Partner Partner Program Overview  Hosting  Implementation  ISV  Training  Competencies

Community

Participate Ask a Question Forums Community Showcase DNN MVP  Program Overview  Lifetime MVPs  Honorary MVPs Subscribe to DNN Digest Advisory Groups  Awareness Advisory Group  Developer Advisory Group  Partner Advisory Group  Technology Advisory GroupLearn Documentation Wiki Community Blog Video Library Project History Development RoadmapDownload DNN Store Language Packs Manuals Nightly BuildsSecurity Policies Security Center

Blog

About

News Press Releases News Coverage Press KitCareersContact DNN

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 ForumsAuthenticationAuthenticationWindows prompting for User and passwordWindows prompting for User and password
Previous
 
Next
New Post
9/20/2007 4:35 PM
 
Stendor

Joined: 8/31/2006
Posts: 41
Good afternoon,
 
I’m trying to configure the new Active Directory provider, I think that I install configure everything the right way but users are getting a window prompting them for a user name and password (a window popping up). Does any one now how to fix this.?
 

thanks,

 
 
New Post
9/20/2007 4:43 PM
 
Mike Horton


Joined: 7/16/2003
Posts: 4865

It depends on where your users are coming from. If they are internal users (they use computers that belong to the same domain as you setup the AD Provider for) then the site needs to be added to either the Trusted Sites or Intranet sites in the Internet Options (this can be forced on all users via Group Policy). If they are external users then you need to comment out <add name="Authentication" .... /> in the <httpModules> section in your web.config. The side effect of this is that internal users will not be automatically logged in.
 
New Post
9/24/2007 11:08 AM
 
Stendor

Joined: 8/31/2006
Posts: 41

I'm sorry, the person doing the testing was using a computer that didnt belong to the domain.

every thing is fine thanks
 
New Post
9/24/2007 3:39 PM
 
Hal Saville

Joined: 12/12/2005
Posts: 26

mikeh wrote

It depends on where your users are coming from. If they are internal users (they use computers that belong to the same domain as you setup the AD Provider for) then the site needs to be added to either the Trusted Sites or Intranet sites in the Internet Options (this can be forced on all users via Group Policy). If they are external users then you need to comment out in the section in your web.config. The side effect of this is that internal users will not be automatically logged in.

Hi Mike,

I'm wondering about this. I have been doing an intranet for over a year with AD authentication on my Production site and AD authentication plus auto login on a development site. I'd like to do the auto-login on the Production site too, but with my setup it isn't ready for prime-time yet. I have users who are on the WAN who can auto login to DEVsite either from my native domain or also from another domain which lives on the same WAN (but not in any shared forrest). so far so good. But I also have the majority of my users logging in through a SSL-VPN connection. So where do they fit into the above statement? The VPN doesn't log them formally into the domain but auto-login does work with two annoying exceptions.

First, when you log out, the cookie which it creates keeps auto-login from working. I just get the unauthenticated homepage when I reconnect. I don't know how long that takes to expire.  And the only way around it is to delete the cookie, something generally beyond the average user.

Second, When I log on with one AD account, the cookie maintains it such that if I disconnect from the site and VPN and then reconnect with a different AD account it still logs in with the first account. Not good given that many of my users in a confidential healthcare setting could need to share computers. This has happened with versions dating back to at least 4.0. I just did a clean install of 4.6.0 using the starter kit with the install wizard and selected AD authentication and it still has the logout problem.

I have seen something here in forums about the case of the domain name in the "domainname/username" user name format affecting authentication... could you explain this and the current state of the art with 4.6.0? My AD is set up to render accounts in the newer format of username@domainname.com but DNN accounts are still created in the DOMAINNAME/USERNAME format anyway so I'm wondering if this is part of the issue or whether it is the way my domain or AD are set up.

Is it really either or with what you mentioned above or can both be made to work?

Sorry for the convoluted post here. Please feel free to address whatever parts you can here. We'll all get there eventually.

Thanks,

Hal
 
New Post
9/25/2007 1:34 AM
 
Mike Horton


Joined: 7/16/2003
Posts: 4865

hssaville wrote

 mikeh wrote

 

It depends on where your users are coming from. If they are internal users (they use computers that belong to the same domain as you setup the AD Provider for) then the site needs to be added to either the Trusted Sites or Intranet sites in the Internet Options (this can be forced on all users via Group Policy). If they are external users then you need to comment out in the section in your web.config. The side effect of this is that internal users will not be automatically logged in.

 

Hi Mike,

I'm wondering about this. I have been doing an intranet for over a year with AD authentication on my Production site and AD authentication plus auto login on a development site. I'd like to do the auto-login on the Production site too, but with my setup it isn't ready for prime-time yet. I have users who are on the WAN who can auto login to DEVsite either from my native domain or also from another domain which lives on the same WAN (but not in any shared forrest). so far so good. But I also have the majority of my users logging in through a SSL-VPN connection. So where do they fit into the above statement? The VPN doesn't log them formally into the domain but auto-login does work with two annoying exceptions.

Is there a trust between the domains? That would explain why users from the other domain can login I think. I haven't got the testing facilities to test from multiple domains or sub-domains but it is something that I'm trying to get setup. As far as VPN goes; my understanding from using it for work is that as far as the network resources are concerned I am logged into the domain (ie: When I logged in via VPN the credentials I supplied where authenticated against the domain and everytime I try to use a network resource those are the credentials that are used. Again, it's something that I haven't been able to fully test.

First, when you log out, the cookie which it creates keeps auto-login from working. I just get the unauthenticated homepage when I reconnect. I don't know how long that takes to expire.  And the only way around it is to delete the cookie, something generally beyond the average user.

I'm not sure if there's a suitable workaround for this. The Logout button is part of the DNN core and I'm not sure what's written to any cookies. I'm in the process of switching over to a new computer at home so I can't access the source code to see what is done but I will try to look at it at work. I think either the OpenID or LiveID provider has its own code for when a user logs out and I'll take a look at that to see what Charles has done. Possibly I may be able to adapt what he's done to fix the logout/log back in problem.

Second, When I log on with one AD account, the cookie maintains it such that if I disconnect from the site and VPN and then reconnect with a different AD account it still logs in with the first account. Not good given that many of my users in a confidential healthcare setting could need to share computers. This has happened with versions dating back to at least 4.0. I just did a clean install of 4.6.0 using the starter kit with the install wizard and selected AD authentication and it still has the logout problem.

Hmmm, I'm not sure how to get around the VPN other user logged in issue. The way the code is written and how it should work using auto-login is that DNN automatically goes to WindowsSignin.aspx which takes the users credentials and passes them to the authentication code. Cookies shouldn't be part of the equation at this point. I'll have to look at setting up a VPN here at home so that I can try to test this or get a test account setup at work that I can use.

As far as things in 4.6.0 being the same as earlier versions, that's how it should be. I could have gone and made a bunch of changes that I want to make but I thought it would be best if the provider continued to work the same way as it always has initially. 1.) I, and the DNN Core Team, then know the that any new bugs are the result of the separation and not because of something else that I coded which makes it easier to fix and 2.) The end user's are comfortable with using the provider in it's current state and new changes can be added gradually.

I have seen something here in forums about the case of the domain name in the "domainname/username" user name format affecting authentication... could you explain this and the current state of the art with 4.6.0? My AD is set up to render accounts in the newer format of username@domainname.com but DNN accounts are still created in the DOMAINNAME/USERNAME format anyway so I'm wondering if this is part of the issue or whether it is the way my domain or AD are set up.

That was a bug in versions 4.5.1(?) to 4.5.3 and was fixed in 4.5.5. What was happening was that further into the core code (not part of the provider) there was a string comparison between the logged in user vs. the username that was stored in the database. When you compare strings the text has to match exactly and usually programmers either convert both strings to all upper or all lower case when the case doesn't matter. This was missed in the code (easy mistake that I've done hundreds of times) so if the username was domain\user in the database because the user manually logged in at some point and the autologin that was passed was DOMAIN\user it would fail and log the user out. I'll have to look at the code to verify but the DOMAIN\USERNAME account is just how the provider pulls the information in from the AD. I don't think it matters how the accounts are rendered in the domain. IE: I can log in at work or on my domain at home using either format and I still get logged in.

Is it really either or with what you mentioned above or can both be made to work?

Sorry for the convoluted post here. Please feel free to address whatever parts you can here. We'll all get there eventually.

No worries. You got me thinking and planning. Fire away with your questions/ideas.

Thanks,

Hal
 
 Page 1 of 2
12Next 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsAuthenticationAuthenticationWindows prompting for User and passwordWindows prompting for User and password


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