10

I have an application that is using ActiveDirectoryMembershipProvider to grant access to users. The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.

We've opened the LDAP port to the DC on the inside network - yet no matter what we try, we end up with an error that says "The specified domain or server could not be contacted."

Does anyone have any suggestions on how I can resolve this? We've tried everything we can think of and just aren't getting anywhere.

My connection string is:

<add name="ADConnectionString"
    connectionString="LDAP://10.5.3.7:389/DC=MyTestDomain,DC=local"/>

And my provider is:

<add name="ActiveDirectoryMembershipProvider"
    type="System.Web.Security.ActiveDirectoryMembershipProvider"
    connectionStringName="ADConnectionString"
    attributeMapUsername="SAMAccountName"
    connectionProtection="None"
    connectionUsername="LdapUser"
    connectionPassword="LdapPassword"   />
Scott Ivey
  • 40,768
  • 21
  • 80
  • 118

6 Answers6

4

The application is hosted on a non-domain machine, with a firewall between the application server and the domain controller.

Since you could query directly using an LDAP tool, that suggests that the firewall is open correctly. However, keep in mind that the ActiveDirectoryMembershipProvider is not using plain old LDAP, it's using Microsoft technologies. For example, if you set connectionProtection="Secure", ADMP will try using SSL and port 636, if that fails, it will use Microsoft's built-in IPSec signing (see this article for more details).

Anyway, this makes me wonder about a couple things:

  1. Does the AD domain have an IPSec "required" policy which refuses connections from non-domain/non-configured computers? (Probably not, since you connected with plain LDAP, but it's worth investigating.)
  2. Have you added the domain controller's NetBIOS name to your lmhosts file, and its DNS name to your hosts file? (Many protocols check that their target's reported name matches the name you tried to connect to.)
  3. A lot of people have noted problems using ADMP between different domains, and the solution required that a one-way trust be created. Since it sounds like your client computer is not in a domain, you can't have that trust--unless either (a) it is a member of a different domain with a one-way trust or (b) it is a member of the same domain and thus client-server trust is implicit.
Rob
  • 45,296
  • 24
  • 122
  • 150
ewall
  • 27,179
  • 15
  • 70
  • 84
  • Your second point led me to a solution! Apparently, the name of the DNS was changed on our test server which caused only the ADMP to fail, while every other method worked! However, the current workaround for me was to have the IP address instead of a host name in my LDAP connection string, the exact same way Scott has it set up (instead I don't provide the port number, I let it choose automatically). – Alan Fluka Oct 07 '15 at 11:40
3

It seems like the solution is to open port 445.

Read this thread

We're not allowed to open so I guess I'm stuck.

  • Opening up port 445 did the trick for me. I could connect via `System.DirectoryServices.DirectoryEntry(...)` just fine using my LDAP connection string, but any attempts to connect via the `ActiveDirectoryMembershipProvider` would yield the following error: `The specified domain or server could not be contacted`. Opening up this port resolved the issue. – codechurn Dec 03 '14 at 19:59
1

You can use this two articles, may be solve your problem

www.ddj.com/windows/184406424

forums.asp.net/t/1408268.aspx

and check your firewalls

emdadgar2
  • 820
  • 1
  • 9
  • 15
1

I had this error, and managed to fix it. There are multiple reasons that can lead to this, here is a to-do list to identify exect problem:

  1. Create a micro application, with single method Membership.GetAllUsers(), execute on machine outside Active Directory (AD), with incorrect password in connection string, check if you get incorrect password exception. If you don't get it you can't connect to your AD server, check firewall, if you do get invalid password exception, goto next step.

  2. If you can, try to execute same app, localy on AD server, first with incorrect password, than with correct, executing app locally provides more detailed exception what is wrong (for me this exception lead me to fixing problem). In my case it told me that Server service is not started, than that Workstation service is not started.

Some thoughts on the fact that it required Server and Workstation services to be working on server: afaik Server service is used for windows file sharing (netbios over TCP), and is using 445 port, so it mey be that this port must be opened in addition to LDAP port. My second observation was that event if 445 port opened (netstat -an) it still can be not working, winows will drop all packets to this port if Windows Client and File and Printer sharing checkboxes are not checked on network interface adapter which rcived this packets. Check "telnet External_IP 445". Thats all info i gathered while strugling with this problem.

Alex Burtsev
  • 12,418
  • 8
  • 60
  • 87
0

Have you tested with an LDAP browsing tool, from the remote box to see if it can connect with the criteria being used here? I.e. Is it a connectivity problem or something else?

geoffc
  • 4,030
  • 7
  • 44
  • 51
  • Yes - we are able to query using an LDAP tool using the same information. This is baffling me. One strange thing that I did notice is that the AD Membership Provider tries to get the NetBIOS name of the server that you're connecting to (dug this up with reflector) - and that during that there's a try/catch that throws the exact message that we're getting. Not sure why the provider thinks it needs the server's netbios name. – Scott Ivey Aug 13 '09 at 01:48
0

In case anyone stumbles on this and wants to smash their head on a wall... Recently tried doing all this for an AD server that my company had in a different domain than the current context. Was using the IP provided and getting failures as stated here. Even used a tool like Softerra LDAP Admin and it worked fine, however AccountManagement failed.

We had a publicly exposed URL hooked to that IP address (still only allowing certain IP's to make calls). Once I replaced the IP with the URL provided, it worked like a charm.

Hope this saves someone the hours of head smashing I just put myself through.

Ricky Hartmann
  • 891
  • 1
  • 7
  • 20