Active Directory login not working after moving site



Just moved part of a clients site from a DMZ to inside their network. This was done be creating a new db from a db backup and setting up a new site on a brand new server. The site also got new licenses, domain/host name to fit the new internal network.

Now we have just one "small" problem - AD users can no longer login using the same username/password as before. We have checked the connection from new server to DC by telnet using same IP as in connectionstrings (works fine), by changing connectionPassword/connectionUsername in web.config (got errormessages when user credentials was not OK), and by using the ldap explorer tool ( The connection from new webserver to DC seems to be fine, according to these tests. But not according to users who want to login...

See our Role/Membership setup from web.config below.

I guess a lot of you have moved sites before - grateful for any help or suggestions :-)

/ Markus



------ cut from web.config -----------  

<roleManager enabled="true" defaultProvider="MultiplexingRoleProvider" cacheRolesInCookie="true">
        <clear />
        <add name="MultiplexingRoleProvider"
  type="EPiServer.Security.MultiplexingRoleProvider, EPiServer" provider1="SqlServerRoleProvider"
  providerMap2="ActiveDirectoryMembershipProvider" />
        <add name="WindowsRoleProvider"
  type="EPiServer.Security.WindowsRoleProvider, EPiServer" />
        <add name="SqlServerRoleProvider"
  type="System.Web.Security.SqlRoleProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
 <add name="ActiveDirectoryRoleProvider"
  type="EPiServer.Security.ActiveDirectoryRoleProvider, EPiServer"
  connectionPassword="xxxx" />
    <membership defaultProvider="MultiplexingMembershipProvider" userIsOnlineTimeWindow="10">
        <clear />
        <add name="MultiplexingMembershipProvider"
  type="EPiServer.Security.MultiplexingMembershipProvider, EPiServer"
  provider1="SqlServerMembershipProvider" provider2="ActiveDirectoryMembershipProvider" />
        <add name="WindowsMembershipProvider"
  type="EPiServer.Security.WindowsMembershipProvider, EPiServer"
  searchByEmail="true" />
        <add name="SqlServerMembershipProvider"
  type="System.Web.Security.SqlMembershipProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"   connectionStringName="EPiServerDB"
  passwordStrengthRegularExpression="" />
        <add name="ActiveDirectoryMembershipProvider"
  type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
  enableSearchMethods="true" />

Apr 11, 2012 16:47

Hi Markus,


What error are you getting trying to login with the AD users?

I see you are using multiplex with SQLProvider so I'm guessing your using forms for login?

Apr 12, 2012 13:19

Hi Petter, and thanks for your help!

The error is the usual wrong credentials error. And yes, using forms authentication. The plan is to let AD groups control all access in the future, so then we can skip the sqlprovider and only use AD. But the first step was to create a intranet site "as is" that worked the same way as the previous site. 

Apr 12, 2012 15:25

Is the AD still under the same domain? 

Apr 12, 2012 15:48

Yes. The site has been moved from a server in the dmz to a server included in the domain. AD has not changed

Apr 12, 2012 16:03

Was just thinking if the domain part of the username might be the one srewing it up....


If you log in to the site and search for AD users. How are they saved? With or without the domain part?

Apr 12, 2012 16:28

In this configuration above, with the domain part. This is also the way users have logged in. Tried attributeMapUsername="sAMAccountName" but login fails, with or without domain part.

Apr 13, 2012 7:48

hmm strange.


Not working at a place where I have a AD connection untill Monday but will test around and check back by then.

Apr 13, 2012 9:20

Hmm, actually this problem might not have been a problem, after all...

After getting some anwers about AD groups from the AD adminstrator about which users that where testing, they belonged to wrong groups and our test users where not correctly set up. This hard to check when you only see a few bits of a larger puzzle.

So with appropriate users login works just as it should :-)

Thanks for your help, Petter!

Apr 13, 2012 16:00
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.