We are in the process of rolling out a new corporate intranet on DNN. It is currently running DNN v4.03.05, .NET 2.0, W2k3, IIS6. There is 1 Parent portal and 2 child portals (more child portals to come).
We are trying to set the portal up in Windows Auth mode, but also need a handful of users to have separate accounts (created directly in DNN) that they will use to log in to perform content management. For this reason, we have <authentication mode="Forms"> <forms name=".DOTNETNUKE" protection="All" timeout="600" cookieless="UseCookies" /> in web.config. We have identity impersonate turned off. We have been able to access the Authentication module on the Admin menu and synch all three portals to the AD. We have the DNN root folder, and the windowssignin.aspx page set to Windows Authentication in IIS.
Up until recently we had been working purely on content management functions, by coming to the portal and logging in using a userid created directly in DNN (meaning not an AD account). Again, this has been done to allow our content managers to easily get into admin mode to update the site (without having to do a complete network login) and back out again so they can use the site in normal mode (without seeing all the modules, some of which are filtered by security when they are using their normal network login).
We are in the process of trying to roll the intranet out to a group of test users. We initially had some problems, where users were not being recognized when they accessed the portal. Some of the users were able to login using a fully qualified (domain\username) login name, and see the content expected, filtered by security settings.
We came in this Monday to find that one of the child portals was unaccessible. The log shows the message of:
AssemblyVersion: 04.03.05
PortalID: 1
PortalName: CS Intranet
UserID: -1
UserName:
ActiveTabID: 72
ActiveTabName: CS Home
RawURL: /dnn/cs/Default.aspx
AbsoluteURL: /dnn/cs/Default.aspx
AbsoluteURLReferrer:
UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
ExceptionGUID: be9e886f-45ea-4f9f-a1ad-91335e48a8aa
InnerException: Unhandled Error:
FileName:
FileLineNumber: 0
FileColumnNumber: 0
Method: DotNetNuke.Security.Authentication.Configuration..ctor
StackTrace:
Message: System.Exception: Unhandled Error: ---> System.NullReferenceException: Object reference not set to an instance of an object. at DotNetNuke.Security.Authentication.Configuration..ctor() at DotNetNuke.Security.Authentication.Configuration.GetConfig() at DotNetNuke.HttpModules.AuthenticationModule.OnAuthenticateRequest(Object s, EventArgs e) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) --- End of inner exception stack trace ---
Source:
Server Name: CHPSQL01
This child portal was completely inaccessible, even by the host account. After a lot of google research, I finally commented out the authentication http module in web.config. The child portal was instantly accessible again and users were able to login with their DNN content mgr account to get to work. No network users were able to login to this portal however. When they try to login with a domain account, they get an exception about an undefined object. The log viewer only shows the attempted login, it does not show the complete error. Here is where things seem to get very strange. With the auth http module commented out, we are still able to synch the parent portal and one child portal with the AD. We are also able to request the windowssignin page and are authenticated. When we try to access the Authentication module in the "problem child" portal, we get the error that "Windows Authentication is currently unavailable."
It seems very strange that this child portal behaves so differently from the other two. The bottom line is that we need windows authentication working for all three portals. It is not even a big deal if the users have to manually specify their network account to get logged in. Currently we can't make the one child portal, the most important of the three, work properly.
Any help will be greatly appreciated!