I have investigated this a little further and have found the following:

The end user is authenticated via NTLM when they access /Default.aspx.  They are then redirected to /Admin/Security/WindowsSignin.aspx initially as anonymous.  This is rejected, and the authenticated user tries to access the file again.  This time the end user is successful, with an http code of 302, and then end user then make multiple calls to WindowsSignin.aspx.  When I say multiple I mean hundreds

Then using the SQL Server profiler I see the multiple calls to GetUserByUsername.

Has anyone got any ideas about this?  Can anyone help?  Any ideas would be greatly appreciated.

Many Thanks

Glen

Hi everyone

I have a potential solution to this which seems to be working.  One of the the other posts suggested looking at http://dnn.gmss.org/ for "DNN AD Fix 4.3.5".  This seems to have fixed the initial problem.

I then immediately ran into my second fault of child portals not allowing the same user to be added to the database more than once.  I then re-ran a stored procedure that another post suggested, search for AutoUpdateUsersToAllPortalAccess in this forum, and everything seems to work as expected.

I expect that I will create a trigger on one of the user tables which will make this stored procedure automatically executed.

Hope this helps.

Hi all

Well tried the AD Fix and that didn't fix my problem.  One colleague in my IT department was added to DNN, everyone else can't get on.

To recap my problem:

I am using DNN 4.3.5, Win2K3, IIS 6, SQL Server 2000.  I have applied the AD Fix and had the problem before, and after, the update.  The problem is that new AD users are not added to DNN 4.3.5., although some have been added in the past (i.e. me).

The Symptoms
The end user connects to the web site and gets placed in a loop where nothing appears to happen.  They are redirected to the WindowsSignIn.apx.  After using SQL Profiler (SQL Server 2000) I was able to see repeated calls to the following:

exec dbo.GetUserByUsername @PortalId = 0, @Username = N'DOMAIN\username'

NOTE: "DOMAIN\username" has been replaced for the purposes of this post.

On my browser DNN is not a trusted site but it works.  My end user's machine is the same.  When I added DNN as a trusted site to IE on their machine it made no difference.  I have tried this on another user's computer with the same effect.

The Question/Challenge
I have read most of this forum searching for the solution to my problem.  Has anyone got AD integration working for an Intranet solution on DNN 4.3.5 on IIS 6?  Any help here would be great, for me and everyone else.

Glen