Since I have upgraded to DNN 4.00.03 (from 4.00.02), I have not been able to get other visitors to authenticate automatically using Active Directory authentication as it was doing before.

I have set-up the Active Directory authentication in the Admin menu, removed Anonymous authentication in IIS 6.0, and set the web.config to use Windows Authentication with and without Impersonation.  However, anyone who is not me gets this error (taken from the Log Viewer):

AssemblyVersion: 04.00.03
Method: System.Web.Caching.CacheEntry..ctor
FileName:
FileLineNumber: 0
FileColumnNumber: 0
PortalID: 0
PortalName: [PORTAL NAME]
UserID: -1
UserName:
ActiveTabID: 36
ActiveTabName: Home
AbsoluteURL: /LCSBPortal/Default.aspx
AbsoluteURLReferrer: http://[INTRANETSERVERNAME]/
ExceptionGUID: 2f25e383-4d23-4518-b98c-a00dce3f3201
DefaultDataProvider: DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider
InnerException: Unhandled Error:
Message: System.Exception: Unhandled Error: ---> System.ArgumentNullException: Value cannot be null. Parameter name: value at System.Web.Caching.CacheEntry..ctor(String key, Object value, CacheDependency dependency, CacheItemRemovedCallback onRemovedHandler, DateTime utcAbsoluteExpiration, TimeSpan slidingExpiration, CacheItemPriority priority, Boolean isPublic) at System.Web.Caching.CacheInternal.DoInsert(Boolean isPublic, String key, Object value, CacheDependency dependencies, DateTime utcAbsoluteExpiration, TimeSpan slidingExpiration, CacheItemPriority priority, CacheItemRemovedCallback onRemoveCallback, Boolean replace) at System.Web.Caching.Cache.Insert(String key, Object value, CacheDependency dependencies, DateTime absoluteExpiration, TimeSpan slidingExpiration) at DotNetNuke.Services.Cache.FileBasedCachingProvider.FBCachingProvider.Insert(String CacheKey, Object objObject, CacheDependency objDependency, DateTime AbsoluteExpiration, TimeSpan SlidingExpiration, Boolean PersistAppRestart) at DotNetNuke.Common.Utilities.DataCache.SetCache(String CacheKey, Object objObject, TimeSpan SlidingExpiration, Boolean PersistAppRestart) at DotNetNuke.Common.Utilities.DataCache.SetCache(String CacheKey, Object objObject, TimeSpan SlidingExpiration) at DotNetNuke.HttpModules.DNNMembershipModule.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 ---
StackTrace:
Source:
Server Name: [SERVERNAME]

I am sure I probably missed a setting.  Can someone point me in the right direction to fix this please?

---

These are my personal opinions and don't necessarily represent the views and opinions of DotNetNuke Corporation.
Will Strohl
Media Module Team Lead, User Groups Team Lead
Sales Engineer, DotNetNuke Corporation

DotNetNuke Blog | Find a DNN User Group | Media Module
Twitter: @WillStrohl LinkedIn:

I did solve the problem.  However, I don't know what the actual fix is.  I had a feeling that the application was getting cached in the GAC and it was having the conflict there.  Since I house my portals under virtual directories on the web servers I deal with, I was able to create a new virtual directory with a NEW directory name and it worked.

However, in the new one I have found that there is a very specific order in the steps that you want to follow when enabling Active Directory authentication.  However, whenever I get it set-up it is by trail and error.  I have yet to nail down or find documentation on the specific order or details on any step.

That leads me to the only true deficiency that DNN has.  Its documentation is very poor in my opinion.  I only use it as a guide and that is not very often since I find it normally leads me in the wrong direction.

I was attempting to upgrade to DNN 4.03, but its caching fix isn't working well for me.  So I suggest sticking with DNN 4.02 until 4.1 is released.  (That is, if you are using 4.x)

I hope this helps!

---

These are my personal opinions and don't necessarily represent the views and opinions of DotNetNuke Corporation.
Will Strohl
Media Module Team Lead, User Groups Team Lead
Sales Engineer, DotNetNuke Corporation

DotNetNuke Blog | Find a DNN User Group | Media Module
Twitter: @WillStrohl LinkedIn:

I did indeed have that uncommented.  In fact, when I got this running I could still recreate the error simply by renaming the virutal directory to the original name. I could even completely delete the compiled app from the framework temporary files folder and I could recreate this scenario over and over again just by renaming the virtual directory.

I wish I could explain why this happens.  I am normally able to find an answer.  Sorry.

---

These are my personal opinions and don't necessarily represent the views and opinions of DotNetNuke Corporation.
Will Strohl
Media Module Team Lead, User Groups Team Lead
Sales Engineer, DotNetNuke Corporation

DotNetNuke Blog | Find a DNN User Group | Media Module
Twitter: @WillStrohl LinkedIn: