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 ForumsAuthenticationAuthenticationsingle sign on problem with DNN 4.7single sign on problem with DNN 4.7
Previous
 
Next
New Post
1/31/2008 8:28 PM
 
I’m having a world of trouble with single sign on in an intranet implementation with DNN 4.7.
 
If a user is registered on a site, they are logged in with their own credentials. If this is their first time, they log in anonymously. This account then browses back to a site they are registered on and are logged into this site anonymously.
 
When I attempt to login through the skin’s login control using Windows Auth, I am getting a login failure despite using DOMAIN\username and correct password. This is frustrating however it’s not something critically important as without single sign on, I am unwilling to deploy DNN as my company’s intranet.
 
My setup is exactly as per the AD Provider User Guide. When I attempted to impersonate, the whole installation fell over, reporting server error in “/”, access denied to CarlosAg.ExcelXmlWriter. My account for impersonation has the same rights to my DNN folder as Network Service.
 
I have a parent portal with 2 child portals. I have been able to confirm that if I browse to http://[portal address]/desktopmodules/authenticationservices/activedirectory/windowssignin.aspx then I am signed in though I can only use this to log into the parent site. I have read Mike’s comments elsewhere on this.
 
I don’t know if anyone has any tips here but it sounds like this is a pretty regular problem on this forum.
 
Mike.
 
New Post
2/1/2008 4:01 PM
 

Mike Hansford wrote

When I attempt to login through the skin’s login control using Windows Auth, I am getting a login failure despite using DOMAIN\username and correct password. This is frustrating however it’s not something critically important as without single sign on, I am unwilling to deploy DNN as my company’s intranet.

I'm assuming when you got it setup that you got an all green when you clicked on Update Settings. When you tried impersonation and got the error did you verify that the account had permission to that file. I've found in the past that even when I've reset permissions on a directory and checked that I wanted all subdirectories and files to have their permissions changed that it hasn't gone through. It's rare but I've seen it happen.

Now, I only quoted the above from your post to ask a quick question. How long are your passwords? By default DNN has the minimum password length set to 7 in the web.config. On manual logins if the password isn't at least 7 characters long it'll fail so if your password is less than 7 you need to change the password length in your web.config. However that doesn't affect automatic logins.

 
New Post
2/4/2008 10:34 PM
 

Hi Mike

Thanks for your reply. First up, in reference to your question Mike, our passwords are minimum 8 characters.

I did get all green when I clicked on Update Settings. I re-applied security priveleges to the folder - I had forgotten that priviledges don't always apply to all sub-folders and files.

I had a thought that I might need to authorise this same user account to access the database so also created an account for this user in SQL Server and assigned the account owner priveledge on the database. I've found no mention of it in documentation or forums but thought it was worth a try. I still get the problem I referred to earlier. I suppose my question from this is when impersonating, what account is used to access the dotnetnuke database?

I'm starting to think about a complete re-install in the expectation that I've fiddled too much and have really killed something.

Thanks

Mike

 
New Post
2/5/2008 12:14 AM
 

The user that access the database is the user account that you used in the connection strings and has nothing to do with impersonation. All impersonation does is replace the account that DNN runs under (by default it's NETWORK SERVICE which is a local account on the server). The only other thing I can think of doing is testing the connection to the domain's Active Directory from the server using a program like Softerra's LDAP Browser (http://www.ldapbrowser.com)  though with you getting all greens that shouldn't be necessary.

 
New Post
2/5/2008 10:09 PM
 

Thanks for you help Mike. Looks like I'll do a clean re-install - see if the clean slate helps matters.

Mike

 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsAuthenticationAuthenticationsingle sign on problem with DNN 4.7single sign on problem with DNN 4.7


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