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 (http://sourceforge.net/projects/ldaptool/). 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 :-)
------ cut from web.config -----------
<roleManager enabled="true" defaultProvider="MultiplexingRoleProvider" cacheRolesInCookie="true"> <providers> <clear /> <add name="MultiplexingRoleProvider" type="EPiServer.Security.MultiplexingRoleProvider, EPiServer" provider1="SqlServerRoleProvider" provider2="ActiveDirectoryRoleProvider" providerMap1="SqlServermembershipProvider" providerMap2="ActiveDirectoryMembershipProvider" /> <add name="WindowsRoleProvider" applicationName="EPiServerSample" type="EPiServer.Security.WindowsRoleProvider, EPiServer" /> <add name="SqlServerRoleProvider" connectionStringName="EPiServerDB" applicationName="EPiServerSample" type="System.Web.Security.SqlRoleProvider, System.Web, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> <add name="ActiveDirectoryRoleProvider" type="EPiServer.Security.ActiveDirectoryRoleProvider, EPiServer" connectionStringName="ActiveDirectoryProviderConnection" connectionUsername="yyyy\epiread" connectionPassword="xxxx" /> </providers> </roleManager> <membership defaultProvider="MultiplexingMembershipProvider" userIsOnlineTimeWindow="10"> <providers> <clear /> <add name="MultiplexingMembershipProvider" type="EPiServer.Security.MultiplexingMembershipProvider, EPiServer" provider1="SqlServerMembershipProvider" provider2="ActiveDirectoryMembershipProvider" /> <add name="WindowsMembershipProvider" type="EPiServer.Security.WindowsMembershipProvider, EPiServer" deletePrefix="BUILTIN\" searchByEmail="true" /> <add name="SqlServerMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="EPiServerDB" requiresQuestionAndAnswer="false" applicationName="EPiServerSample" requiresUniqueEmail="true" passwordFormat="Hashed" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="4" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" passwordStrengthRegularExpression="" /> <add name="ActiveDirectoryMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ActiveDirectoryProviderConnection" connectionUsername="yyyy\epiread" connectionPassword="xxxx" enableSearchMethods="true" /> </providers> </membership>
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?
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.
Is the AD still under the same domain?
Yes. The site has been moved from a server in the dmz to a server included in the domain. AD has not changed
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?
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.
Not working at a place where I have a AD connection untill Monday but will test around and check back by then.
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!