This project is read-only.


AD authenticaiton on public portal preventing search engine indexing


On public facing portals where the active directory provider is enabled, it attempts to set an authentication.status cookie for anonymous users. This in turn prevents search engine indexers from getting to the site due to a 302 redirect loop.

If testing the site using a tool like fiddler, it is easy to see that a 302 redirect loop is occurring. When I tested I witnessed the following:
  • A 302 redirect from “/” to “/Default.aspx”
  • A loop of 302 redirects from /Default.aspx to /Default.aspx (10 before fiddler stopped following the redirects)
Also in google web master tools, using the fetch as googlebot feature we get the following response trying to access the home page of a site that had AD enabled:

HTTP/1.1 302 Found
Cache-Control: private
Content-Length: 160
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
Set-Cookie: authentication.status.4=179028B4DE669753......; expires=Mon, 15-Feb-2010 22:04:50 GMT; path=/; HttpOnly
Date: Mon, 15 Feb 2010 21:04:49 GMT

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="">here</a>.</h2> </body></html>

The cookie in the http header above shown above is also the same when using fiddler to get the page.

With only the standard DNN authentication enabled the following headers are set and search indexers can access the pages:
Set-Cookie: .ASPXANONYMOUS=muh-4drlygEkA.........; expires=Tue, 27-Apr-2010 07:25:58 GMT; path=/; HttpOnly
Set-Cookie: DotNetNukeAnonymous=c36748f0-0294-...........; expires=Tue, 16-Feb-2010 21:05:58 GMT; path=/; HttpOnly

Work around:
Disable the AD provider on public facing sites and use standard DNN authentication instead.

Other info:
In a previous version - DNN 4.8.4 and with 1.0.4 AD provider we were able to run our intranet with the AD provider enabled and for our public portals use only the standard DNN authentication. This meant we could setup our content managers by adding a record to the UserPortals table once they had visited the intranet to create their user record and then be able to login with AD credentials via standard DNN authentication on the public facing sites.

When we moved to 5.2 & upgraded the provider to 5.0.2 we could no longer login with our AD accounts with only the standard DNN authentication enabled on a portal (this does make sense though). When we enabled the AD provider and disabled the standard authentication it was trying to auto-login all visitors, to get around this we set the auto-login IP addresses setting for the provider to which worked. So everything appears to work as expected, but for sites where only the AD provider is enabled, it will try to set the authentication.status cookie for anonymous users - hence blocking search indexer bots.

file attachments

Closed Jan 25, 2012 at 9:27 PM by mikeh36
Fixed in the 05.00.03 release


avtheos wrote Sep 23, 2010 at 1:06 PM

Dear All,
We are facing the same problem since we have launch our new website using the community version of dotnetnuke. We wanted to have everything on one URL. I have spend a lot of time searching and searching in the web for a solution and no luck.
So after struggling my brain I found a solution via a certain IIS/DNN/SQL configuration, but it works. Here is the solution:
(a) Create two domain users, grant them access to your one DNN Database and respectively two application pools on IIS running with those accounts
(b) Create two Websites IIS:
(b1) One with your public URL (host header), probably e.g. "", for public access only (No AD Authentication) pointing out the DNN Directory and assign one of the above application pools to run it. For this site do not set any special right for WindowsSignin.aspx
(b2) One with your public or internal URL (host header), probably e.g. "", for intranet access only (AD Authentication) pointing out the same DNN Directory with the same web.config pointing out the same DB!!! and assign the second of the above application pools to run it. For this site you have to set special right for WindowsSignin.aspx as per DNN AD Module instructions
(c) DNN have both URLs as Portal Alias in DNN with the public URL first. Disable Caching (Set to None) as this is going to return errors while you are trying to change content, as you cannot control, which DNN WebSite is locking the cache.
(d) SQL Server DB change the GetPortalSettings to return for the public AD user another value (as per attached sql script sample)
You can try different variations of the above configuration, also having two directories, but then you will have adittional admin overhead if you have to sync file like attachments.

I hope this helps everyone facing problems with SEO. Now we are getting a 200 OK and not a 302 Temporary Redirect.
Antonis Theofanopoulos

wrote Apr 18, 2011 at 2:59 AM

wrote Apr 18, 2011 at 3:07 AM

wrote Apr 18, 2011 at 3:11 AM

wrote May 2, 2011 at 7:49 PM

wrote Jan 25, 2012 at 9:27 PM

wrote Feb 21, 2013 at 11:30 PM

wrote May 16, 2013 at 11:25 AM

jcoehoorn wrote Aug 27, 2013 at 6:44 PM

I'm using the 5.0.4 release, and this is still occurring.

We need both AD and normal auth, and it needs to work to allow editing on a public-facing site. This is killing us, that Google can't index.

raphael_m wrote Aug 26, 2014 at 8:45 AM

We are also affected by this issue - four years after it has been reported. Why has this issue been closed? There are various side effects which we are experiencing:
  1. Search engines may not correctly index the website as noted in the original issue
  2. Facebook and other social networks can't download the website's text and images when liking it - Facebook does just output "Object moved"
  3. Google Webmaster Tools can't access the website, only the HTML file way works

benigemperle wrote Sep 17, 2014 at 8:49 AM

An easy workaround is to remove the AuthenticationModule in web.config and replace it with a custom IIS URL Rewrite Rule.

The following is a working example. It does an Auto-Login-Redirect on http://intranet if no cookie with name "authentication.status" is present. The Match-URL makes sure it does not redirect WindowsSignin.aspx itself. Make sure "HTTP_COOKIE" is an "Allowed Server Variable" (See
<rule name="Auto-Login Intranet" enabled="true" stopProcessing="true">
  <match url="WindowsSignin\.aspx" negate="true" />
    <add input="{HTTP_HOST}" pattern="intranet" />
    <add input="{HTTP_COOKIE}" pattern="authentication.status" negate="true" />
  <action type="Redirect" url="/DesktopModules/AuthenticationServices/DNNPro_ActiveDirectory/WindowsSignin.aspx" redirectType="Found" />