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" />
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:
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.)
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.)
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.
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.
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
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:
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.
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.
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?
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.
Related
I have followed the guides at https://www.azerothcore.org/acore-docker/, and everything installs and works fine. Auth, WorldServer, DB, etc all work. However, when trying to play locally (LAN, main computer with client, the server on a different Windows machine on same LAN), it consistently loops back to realm selection.
So, I searched here and found these two questions/answers:
Azerothcore: Looping on Realm Selection List
How to resolve sticking in "Realm Selection"?
I have followed the guide in the bottom one, and have changed the Address field in the database to my external IP address (assigned by ISP). The LocalAddress is 127.0.0.1 The rest of the information appears to be correct.
When trying to connect via the external IP, it won't connect at all. But when I try setting my realmlist to 127.0.0.1 it will connect and log me in, but continually loops back to the realm selection screen.
To make sure it was updating, I changed the name of the realm and it shows up correctly when I try and log in. So the data appears to be saved to the database, but I cannot get it to connect from the LAN.
Followed the official guides, and changed the IP address in the DB to external IP. Same result, except now it takes a few seconds to connect and try to log into the realm. Then fails, back to realm selection.
Help would be appreciated. Thanks.
It's 99.9% related to your networking. That's what it turns out to be for pretty much everyone asking this question.
Most likely either a port isn't forwarded correctly, or your firewall prevents the connection. Try and use an external service to verify if the port is open. (Do a search for "Port open check"). Also, check your firewall to have the worldserver listed as an exception in the right folder.
Another common mistake is to change the "default" values when using HeidiSQL in the realmlist db instead of changing the actual values in the 'data' tab.
I have an ASP.NET 2 (very old) web app that I am trying to migrate to a new server. BTW, I am a complete ASP.NET noob but have a good amount experience with other web technologies.
In the web.config, I can see the following connection string XML:
<connectionStrings>
<add name="myCon"
connectionString="Data Source=DEVELOP\DEV_SQL2008R2;Initial Catalog=QO2_New;Persist Security Info=True;User ID=sa;Password=q"/>
</connectionStrings>
I did "nslookup" on the machine name 'DEVELOP' and RDP into the server. To my surprise, I don't see any SQL Server process running. Also, there is no SQL Server installed on that server. I am 100% that the app is running and I am very confident that there are content that comes from the database. I also did a search on the code base and it seems like the connection string is being used.
On a side note, we do have some other databases on separate machines. My questions are the following:
Can the machine DEVELOP somehow redirect the DB connection to somewhere else? If yes, how do I find out which IP is it being redirected at?
If DB connection cannot be redirected, then what is going here exactly?
Unfortunately, I have very little people whom I can ask what is going with this app. Any tips that you can share is much appreciated.
Nslookup uses DNS but there is a chance your machine has a hosts file entry that points DEVELOP to somewhere else..
However, if you RDP'ed into DEVELOP (as in, used that name when connecting RDP, not the ip address given by nslookup) then you should have been able to see a sqlserver install in the list of services.
If there is surely no sqlserver installed there then, from within your RDP session, use TCPView from sysinternals to see what process is listening on port 1433. Could be some kind of TCP redirector like PortTunnel from SteelBytes, bouncing the connection somewhere else. Remember to run tcpview on the server, not your local machine
Perhaps you can try getting connected to the sqlserver using management studio, using the credentials in the web config, you can get sqlserver itself to tell you more about where it is running, such as:
SQL - Query to get server's IP address
Using Environment variables in T-SQL
I am truly ashamed to inform everyone that the database in the web config was never being used. Therefore, even though it is pointing to a non-existing database, it still works. The data from the old database have been converted to static files.
I should have checked this the first thing I came across it. Thanks again for all the help.
I have written an asp.net application and validated the logged in user with Active Directory.
It works perfectly in my local machine IDE. But when hosted in my production server, it couldnt communicate with the AD Server.
I have windows authentication enabled in my IIS in server as well has put identity impersonate in my web.config.
The error is get is
Error Trace :System.Runtime.InteropServices.COMException (0x8007054B): The specified
domain either does not exist or could not be contacted.
Any suggestions is appreciated.
That error usually means exactly what it says - that it cannot find a DC to authenticate against for the specified domain. Are you sure the production box can hit the domain via DNS? You can use nslookup if the server is Windows. This will confirm you can actually hit it. You usually see a different error if it's a security/rights issue.
If it is a windows box try using nslookup domain_name and see if any IP addresses are returned. If they aren't, then that's your issue. You may need to manually configure the IP address if that's the case or resolve the potential routing issue if you can't hit it by IP.
I am writing a small c# app to run at startup when a new machine is booted, connected to our corporate network.
I have some code which checks whether a machine account for the machine already exists on the domain, and if so deletes it, prior to joining the machine to the domain.
This works fine on my computer, which already has the trust set up to the domain, but doesn't from a test machine which is not yet joined.
Is there a way round this? Not sure if this is one for Serverfault or Stackoverflow - so hedging my bets!
Yes you can, via LDAP, as long as you can connect to a domain controller via your underlying network transports (ie- TCP/IP). You'll need to bind to Active Directory under the context of a domain user who has at least read access to the directory. You'll also need to specifically call out which domain controller you want to connect to as autodiscovery relies on a domain connection.
ASP.NET Login control is very slow making the initial connection to AD when authenticating to a different domain than the domain the web server is a member of. Problem occurs for the IIS server and when using with the Visual Studio's built in web server.
It takes about 30 seconds the first time when attempting to use the control to connect against another domain. There is no trust relationship bewteen the web server's domain and the other domains (attempted connecting to several different domains). Subsequent connections execute quickly until the connection times out.
Using Systernals Process Monitor to troubleshoot, there are two OpenQuery operations right before the delay to "C:\WINDOWS\asembly\GAC_MSIL\System.DirectoryServices\2.0.0.0_b03f5f7f11d50a3a\Netapi32.dll with a result NAME NOT FOUND" and right after the 30 second delay the TCP Send and TCP Recieves indicate communication begins with the AD server.
Things we have tried:
Impersonating an administrator on the web server in the web.config;
Granting permissions to the CryptoKeys to the NetworkService and ASPNET;
Specifying by IP instead of DNS name;
Multiple variations of specifying the name and ldap server with domains and OU's;
Local host entries;
Looked for ports being blocked (SYN_SENT) with netstat -an.
Nslookup resolves all the domains and systems involved correectly.
TraceRt shows the Correct routes
Any Idea or hints are greately appreicated.
we finaly fixed it with
connectionProtection="None"
To turn off all attmepts to connetc on the secure port and only use 389.
We also had to specify the Connection username like "ad/bob" instead of just "bob" after the connetionProtection change.
Thanks,
Eric-
I had the same issue. Following this advice seems to have sorted it.
https://elgg.leeds.ac.uk/webteam/weblog/15385.html
We had a custom user running as the app pool user, giving the user read access to this directory 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' Sorts the issue.
If you have the .NET 2.0 SP1 installed
just add the following to the
machine.config (of course all sites
will not check verisign any longer)
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
http://forums.asp.net/t/968778.aspx