I'd like to know how to determine, in a running application, the domain controller/primary domain controller of the Windows workstation or server on which the application is running, using Win32 APIs.
In particular, given a machine's hostname, I want to find the name of the authoritative source of resolving that hostname to a particular machine. (I think that's the domain controller; my knowledge of this area is pretty weak so I may be asking the question the wrong way.).
I've seen a C# code fragment that purportedly does this, but don't know if there is any relation to Win32 APIs. There's lots of "how to get DC" web pages, but they are all invoking command scripts, not the APIs.
Happy to have code, but willing to do the homework on extracting the steps, if somebody points me in the right direction.
Is there an analog in Linux? (e.g., native calls to find a name server? I'm not assuming a Linux context with a Windows domain controller).
(Aha... just discovered this question: Get the domain name of a computer from Windows API. Will dig into it some more. EDIT: Maybe the function I want is NetDCName? Where do I get the parameters that it wants?).
EDIT April 19: I coded/tested NetDCName using Eric's hints. Yes, it produces the domain controller name when there is one,
and an error signal when there is not, which is just the right functional behavior.
However, the function call seems to take several seconds! Why would that be?
That puts an unacceptable, user-visible delay in a check I'm trying to do.
NetGetDCName is one option; if you need more functionality, DsGetDcName is also an option.
The MSDN documentation clearly states that NULL is used to indicate the default, so
nStatus = NetGetDCName(NULL, NULL, (LPBYTE *) &lpDcName);
would return the domain controller for the default domain on the local computer.
Related
I looking for an API method that retrieve the info that "net view /domain" does.
namely, I'm looking for a way to enumerate the visible domains within a forest, using win32api (in C environment)
thanks.
Update:
it seems that DsEnumerateDomainTrusts can do what I need, however, it doesn't looks like net.exe importing it, so I'd still like to know of other options.
Update2:
as it's name imply, the function only enumerate trusted domain, even when DS_DOMAIN_IN_FOREST is specified,
so I'm in square 1.
I think that in your case the best way is to interrogate Active directory.
You will find in this answer the way to get all the domains in your directory, first requesting "rootDSE" to find the configuration naming context, second requesting for crossRef with nETBIOSName to retreive domain entries
As you are interested in how to interrogate active directory from native code, you may have a look to LDAP C-Binding API as discribed in RFC 1823 specifies, Microsoft support it, see MS Strategy for Lightweight Directory Access Protocol (LDAP). You'll find the using and reference manuals of the Microsoft API in Lightweight Directory Access Protocol.
First off, The Problem:
We have a Web App with a Flash front-end that talks to our ASP.NET web service via SOAP which then deals with all of our server side code (C#).
Right now, we implement a simple user sign on in our application, storing the info in our MSSQL DB.
A client has requested what I understand to be Windows authentication through our application using the currently logged in user.
So, I have been tasked with investigating this. Nobody, including myself, has any experience in this area.
I have been reading up on some basic Active Directory information, and some simple tutorials. I understand how to get access to the directory using ADSI through code. What I'm really interested in seeing is how the entire thing should be architected. I don't want to throw together a hacky solution.
Does anyone know of a good tutorial for this kind of thing or have any advice on getting started? More importantly, does this even sound viable?
I know I haven't given much information, but feel free to ask and I will provide answers.
Thanks.
Edit:
Will, to give you an idea of the scope of this, the network will include every computer in a large hospital. So yes, this is huge. Clearly I need to start small. I would like to come up with something that will work at my office first. Maybe ~10 Windows computers on a single domain. One Domain Controller.
I am also open to any good books on the subject.
If you are going to tie into Active Directory you will want to take a look at the System.DirectoryServices namespace. The implementations can vary wildly depending on your system architecture, but this should give you a good starting point.
Enjoy!
I have a problem that probably is not unique, but certainly does not seem to be widely reported.
I need a method to ping a windows service that will tell me if it has stalled out, even if windows is reporting that it is running.
I would prefer to use have a Perl solution but would accept any solution that someone can come up with.
Thanks,
Jeremy
What service are you dealing with? I don't think there is any generic solution to your question if the Services control panel doesn't indicate a problem. In order to detect a running-but-no-longer-functioning-properly process, you have to know what "functioning properly" looks like.
You could use the Win32::Service module
use Win32::Service;
GetStatus(hostName, serviceName, status);
From http://metacpan.org/pod/Win32::Service:
Get the status of a service. The third argument must be a hash reference that will be populated with entries corresponding to the SERVICE_STATUS structure of the Win32 API. See the Win32 Platform SDK documentation for details of this structure. You can even grab the service with GetServices(hostName, hashref).
Right now, my application is using the c-ares asynchronous DNS resolver library on Windows below cURL, and I have users complaining that it behaves differently from other windows apps. One particular user said that "other applications are using the Microsoft DNS client" and experiences no problems.
cURL itself has an asynchronous DNS implementation that uses getaddrinfo() in a thread. My guess is that would be equivalent behavior to using the "DNS Client" and its host of functions (e.g. DnsQuery?)
So, dear Lazyweb, I ask if there is a tangible difference between the behavior of getaddrinfo() vs. using the actual Dns* APIs from the Win32 API.
Looking at the sources it seems ares actually implements the dns protocol for querying host names (and doesn't directly call getaddrinfo) - I'd expect that to miss out on things like WINS lookups, and god knows what other kind of stuff windows can do to look up names.
The easiest way to do DNS queries on Windows is to use DNSQuery (and derivated functions, utf8, wbytes, ansi). Unless you need asynchronous resolution, in this case I would recommend to keep using c-ares or other similar API.
I'm not sure about WINS or other windows specific resolution (not part of DNS specs) not being covered by c-ares. It would help if you can give us some examples, maybe we can get them implemented in c-ares as well.
I have a windows exe app that used to sends packets to a server in the clear. This app (lets call it the client app) is definitely close sourced, but some clever hacker hex-edited the binary, and made it send packets that are scrambled.
Now, obviously, those packets are scrambled in a way that is decipherable (otherwise the server would not be able to understand it), but what I wanted to do is to write an emulator that emulates this binary app, sending the same packets to the server, and being able to unscramble the response (if it is scrambled).
The hex-ed client required an extra dll in order to run, which the old client did not. I am assuming that somehow the hex-ed client managed to load that dll (lets call it client.dll) and the function of that dll is to implement the scrambling/unscrambling, by hooking into some windows api that rerouted all packets sent from the client.exe process.
If there are anyone who can direct me on how to even get started on working out how this all works, and how I can reverse engineer the scrambing, that would be really appreciated.
I have no idea what kind of information to provide, but if there is any lacking, just reply, and I will post with more details, and if anyone wants the binaries, I m happy to provide it.
binary download for any interested parties:
http://dl.getdropbox.com/u/46623/client.dll
http://dl.getdropbox.com/u/46623/newClient.exe
http://dl.getdropbox.com/u/46623/originalClient.exe
These wont run because the resource files are required - they are about 3 gigs, so too big to upload anywhere. Names have been changed to protect the guilty =) , but that probably doesnt protect the name of the dll...
I'm assuming that the person which coded this hook which adds encryption to the packet I/O for the aforementioned program has either hooked the relevant Windows' socket APIs (WSASend, send, etc) or hooked the internal program functions used to send/receive data.
This being said, I'd suggest you use a hook detection program (e.g. RkUnhooker) to find out what is actually being hooked. Once you know what APIs are hooked you should also know where these hooks are going and from there on in you'll have to manually reverse engineer the hook functions.
As for the subject of learning how to do this, I couldn't direct you to just one tutorial to teach you everything but I highly suggest you look at the Tuts4You site, it has a plethora of tutorials which would meet all of your needs.
If possible, upload a copy of the edited client & the hook DLL, if I have the time I'll code you replica encryption & decryption functions.
You need to hook the functions exported by the additional DLL and look into the functions being called and the parameters being passed to them. This is not going to be easy since you do not have type information (e.g. the function signatures for the DLL exports.)
Look here for some information on API hooking. You will also need a good debugger try Windbg from microsoft.
As far as I can see the only option you have here is black box testing ie give known input to both systems and compare the responses against each other to find the differences and similarities.
+--------------+
Input--------->| Original App |--------->Response1
+--------------+
+------------+
Input--------->| Modded App |--------->Response2
+------------+
Now once you figure out how to use the functions from the additional dll you can use it yourself in the same way the original app does.