locked
ActiveDirectoryMembershipProvider with Forms Authentication fails with error message "The specified domain or server could not be contacted." RRS feed

  • Question

  • User923382660 posted

    I have a web app that resides on a Windows Server 2003 SP1 and IIS 6.0 web server.  I have a login page that uses the AD Membership provider, which is trying to authenticate against an AD server.  The challenge is that the web server is in Domain A and the AD server is in Domain B, i.e. are hosted in 2 different network segements.  The web app uses Forms Authentication and allows the internet guest user access.  It is configured for SSL and valid certificates are assigned to the app.  When the app tries to authenticate, it returns the following error: “The specified domain or server could not be contacted.”  Authentication succeeds if I point the ADMembershipProvider to an AD server in the same domain as the web server, it only fails when it crosses domains.  Here is the error stack:

     

    System.Configuration.ConfigurationErrorsException: The specified domain or server could not be contacted. (D:\InetPub\SSBGGroup\web.config line 150)   at System.Web.Configuration.ProvidersHelper.InstantiateProvider(ProviderSettings providerSettings, Type providerType)   at System.Web.Configuration.ProvidersHelper.InstantiateProviders(ProviderSettingsCollection configProviders, ProviderCollection providers, Type providerType)   at System.Web.Security.Membership.Initialize()   at System.Web.UI.WebControls.LoginUtil.GetProvider(String providerName)   at System.Web.UI.WebControls.Login.OnAuthenticate(AuthenticateEventArgs e)   at ISDM.MyLogin.OnAuthenticate(AuthenticateEventArgs e) in D:\InetPub\SSBGGroup\App_Code\MyLogin.vb:line 11 LDAP://server.domain.com:636/DC=ad,DC=bgep,DC=co,DC=uk

     

    I have tested authentication by using straight up System.DirectoryServices classes WITHOUT using the provider (on the same web server, against the same AD controller, and with the same web server configurations), and I’ve been able to successfully connect and authenticate.  I use the same LDAP connection string, username/password that I use with the AD provider, so I know that my connection string and the membership element in the web.config are correct.  Also, I've used the Microsoft LDP tool and another LDAPEditor tools to manually connect to the AD using the same LDAP server address, username and password, and I've been able to connect just fine.  This leads me to believe that there are no server/network issues, but something that the provider needs which it is not getting on the web server.  I've used network traces to ensure port 636 is open and allowing traffic.  Security is a high priority, so authentication must occur only through 636.

     

    <?XML:NAMESPACE PREFIX = O /><O:P> </O:P>According to my research, I’ve found that the AD membership provider only works in the “Full-Trust” policy in ASP.NET (Reference the security note - http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider(VS.80).aspx).  However, the System.DirectoryServices.dll is installed in the GAC, which automatically gives it full trust.  I’m not too familiar with geeking around with security policies, so if you think I need to change something in this area, I’d appreciate any help you can provide.
     

    I’ve been troubleshooting this issue for about 2 weeks now, and the team members I was brought in to help have spent months trying to resolve this issue.  I’d really appreciate any helpful pointers, diagnostic tips, advice, suggestions – anything you can provide.  I would hate to have to scrap out the AD provider, and replace it with the regular LDAP code!

     

    <O:P> </O:P>Thank you in advance for your help.
    Friday, June 1, 2007 2:12 PM

All replies

  • User2105295512 posted
    Mostly it is configuration issue and lets give a small try. If you are using proxy server, can you add following code to your web.config and test the application.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p> <o:p></o:p>

    <defaultProxy>
         <proxy
              usesystemdefault = "false"
              proxyaddress="http://proxyserver:port"
              bypassonlocal="true"
         />
    </defaultProxy>

    Monday, June 4, 2007 9:20 PM
  • User923382660 posted

    Hi ravikk,

    I believe I've already responded through email, but in my case, they are not using a proxy server on the web server.

    Thanks for your suggestion!

    Tuesday, June 5, 2007 1:49 PM