Does anyone have any idea how to tell if an app is running on your internal domain? That is:
Does anyone have any idea how to tell if an app is running on your internal domain? That is:
function IsRunningOnMyDomain(aDomainName: string): Boolean;
or something similar?
function IsRunningOnMyDomain(aDomainName: string): Boolean;
or something similar?
Do you refer to the user account running the app belonging to that domain or the machine the app is running on is part of the domain? For a first approach the LOGONSERVER or the USERDOMAIN environment variables come to mind.
ReplyDeleteThis returns the domain name, and I can just compare against the known value:
ReplyDeletefunction GetDomainName(): String;
var
vlDomainName : array[0..30] of char;
vlSize : ^DWORD;
begin
New(vlSize);
vlSize^ := 30;
ExpandEnvironmentStrings(PChar('%USERDOMAIN%'), vlDomainName, vlSize^);
Dispose(vlSize);
Result := vlDomainName;
end;
I am not sure what your goal is, but don't forget that the workstation running your app may not be logged into the domain. The workstation might be on the LAN subnet, but not logged in - hence no environment variable. Example: I have a WiFi network in our corporate building. It uses the DMZ of our firewall and has a completely different "view" of server hostnames than what would be appropriate on the LAN.
ReplyDeleteI wrote an app that runs both on a corporate LAN, our WiFi network and outside of our firewall. Luckily, the subnet is different in each external location, so I can detect "where" the app is running. I adjust server hostnames to match either the internal hostname or the public-external hostname.
You can use DsRoleGetPrimaryDomainInformation() from netapi32.dll to figure out the domain name of the machine that is running your app:
ReplyDeletevar
buf : PDSROLE_PRIMARY_DOMAIN_INFO_BASIC;
begin
if (DsRoleGetPrimaryDomainInformation(nil, DsRolePrimaryDomainInfoBasic, Pointer(buf)) <> ERROR_SUCCESS) then
Result := buf.DomainNameDns;
(don't forget to call DsRoleFreeMemory afterwards, buf.DomainNameDns might as well be nil).
If you need the domain name of the logged on user that is executing your app, use the approach Nick Hodges posted above.
Kevin McCoy Both environment variables are set to the workstations name when not logged into a domain. So there are always meaningful values.
ReplyDeleteif you are still developing and/or maintaining the app, you can create a COM server app that will keep track of the monitored app. Using DCOM, the app will tell the server that it is active. One drawback is that if the app or computer crashes, then the server is not notified. You would need to have the Server poll the running apps. If no response for a given machine, then the app went AWOL.
ReplyDeleteUwe Raabe I just logged in to Win7-Pro, using a local login, (using the machine's hostname as the domain) on my laptop. The laptop is connected my corporate LAN with CAT5.
ReplyDeleteI then checked the environment variables. The above-mentioned domain environment variable was set to the laptop's hostname, not the corporate domain name. Did I miss something in your explanation? ;-)
I think the only reliable way to check what domain you are "sitting in" is to use an external web site that returns your public WAN IP. Then, do a reverse-DNS lookup of that IP to get your domain. This would work regardless of login status, what side of the firewall (DMZ/LAN) you are sitting on, Etc.
I think if Nick's goal is to use the correct server hostname(s) depending on if he is sitting in one domain or another, then the correct answer is a bit more complex than simply reading the environment table - at least if you want a reliable system.
If his goal is something else, then I'll shut up now :-)
Actually, my goal is to answer the question: Is this app running inside our firewall on our Windows Domain?
ReplyDeletePing the login server?
ReplyDeleteNick Hodges Aren't they both the same thing?
ReplyDeleteNick Hodges But why do you want to know? It sounds like there's a different problem that you want to solve.
ReplyDeleteCrude security -- so that the app will only run on our domain.
ReplyDeleteChecking the appropriate environment variables should be good enough. More accurate would be checking that you're logged on to a domain account and can talk to a domain controller.
ReplyDeleteThat code you posted looks like it came out of the 90s though. New() and Dispose() on a ^DWord AND a 30 byte fixed buffer? Gah.
Yeah, I know -- But it's working for now, and I don't want to mess with it until I get some tests around it. ;-)
ReplyDeleteDo a Dns lookup for a value you put into your work active directory domain.
ReplyDeleteHow is detrimental or a security risk if the app is not running on your domain? Can it even run if not authenticated to the domain? One would assume that resources within a domain would be inaccessible to an application not correctly authenticated with that domain. Maybe it's just your description, but it seems like you might be looking for a solution to a non problem.
ReplyDeleteTo make it OS independent, why not simply connect to a database or Web service that only is visible in-house?
ReplyDelete