I hit a problem today moving a site (DNN V7.2.1) to a new host - azure as it happens.  

I bring up the site on the new host using a temporary domain name. Let's say it is "testing.azurewebsites.net".  My home page appears as I hope and I can navigate the site until I try to login.  When I try to login I end up in a loop being redirected back to the login page. Pretty sure this is because the landing page after login is restricted to logged in users and it thinks I haven't logged in.  However, I have used a valid ID and password and I do not get a login error message.

On searching this forum I find 

http://www.dnnsoftware.com/forums/thr...

Which gives me a hint as to the problem and indeed when I look at the network traffic the cookie is on the wrong domain:

"olddomain.co.uk" (name changed by the way)  being the domain the original site was on. What I don't know is where "olddomain.co.uk" is coming from? The domain is not set in the  web.config file - I am not using single sign-on.  If Ido deliberately set domain to:

<forms name=".DOTNETNUKE" protection="All" timeout="600000" cookieless="UseCookies" slidingExpiration="true" domain=".testing.azurewebsites.net" />

Then login works and I am away, but of course as soon as I point the DNS to the live domain name everything is going to stop working again.

So where is ".olddomain.co.uk" coming from when no specific domain is set in domain setting of the <forms> tag?

Hi Sebastian,

Thanks for your response, but the aliases are correctly configured, including the default.

I eventually tracked the problem down and post in case others hit the same issue.

I do in fact have two .net applications running, one in the root ("olddomain.co.uk"!!) and DNN in a sub-dir.  The web.config for the root site DID have the domain set in the <Forms> tag (even though it didn't need it).  Why the web.config from the root application impacts/overrides(?) the web.config in the sub-dir I don't know and assume this is an Azure thing, because the sites were previously running on a Windows 2012 server in the same configuration without this issue - although it may be that it was because both sites were accessed off the same domain in the the live environment ("olddomain.co.uk" and "olddomain.co.uk/dnn".

Anyway, removing the "domain" entry on the root site resolved the issue. 

So, in summary if you hit this type of issue, it is probably a "domain" entry in a web.config and could be in a web.config other the the DNN version.