Out of the box, there is a reasonably high likelihood that you can get the provider to start working with an AD domain. Because the first hurdle you will face is the question of connectivity to the directory, getting the correct connection string is important. Luckily, if you know what your options are it is also pretty easy to set up. For starters, you can configure a sample application with the provider that attempts to retrieve a user object from the Users container that is found on all domains. Because ActiveDirectoryMembershipProvider is not configured in either machine.config or the root web.config files, you will need to explicitly configure it in web.config.
<membership defaultProvider="appprovider"> <providers> <clear/> <add name="appprovider" type="System.Web.Security.ActiveDirectoryMembershipProvider, _" connectionStringName="DirectoryConnection" /> </providers> </membership>
Because none of the other provider-specific configuration options are used, the provider will connect to the directory using the underlying process credentials. This is an important point because it means that, by default, when running on IIS 7.0 the provider will connect to your directory as NETWORK SERVICE (that is, the machine account from the perspective of the directory server). For now, let's use a connection string that looks like:
<connectionStrings> <add name="DirectoryConnection" connectionString="LDAP://aspmvp.bhaidar.net" /> </connectionStrings>