Is there any way to programmatically add an .exe file to the exception list for the Windows Vista firewall to allow it to run normally? I'm using VC++.
Yes - if you take a look at the WindowsFirewallAddApp method here, it should give you some ideas how to do it.
I don't know for certain about the Vista firewall, but I would defeinitely excpect that it is a violation of the security of any computer to allow programmatic access to firewall exception lists. I would be very surprised if Windows allowed arbitrary code to fiddle with the Firewall in this way.
The user sitting in front of the computer, or a network administrator setting network wide security policies would be the only two who should be able to do this. Notice that they are both actual people doing the process interactively.
Related
this question has been asked before but there is no conclusive answer.
I've written a Windows service in Delphi, which needs to generate a beep under certain condition. This works fine on XP, however fails in Windows 7 or 2008.
Note:
Beep can work if i create a console program instead of a service - using PC speakers.
Beep cannot work in a service even if i enable "allow service to interact with desktop" or even assign administrator rights to the service.
My question: Is there a way I can call beep API such that it works in a service? Thanks.
You can't do this in Vista and up. Services run in a different session and so don't have access to the speaker.
Update: Someone found a way here. it involves IOCTL, and is available to drivers and services.
Original answer:
The only way I know of to interact with the user would be to have your Service communicate with a small user-agent process which would be added to HKEY_LOCAL_MACHINE\CurrentUser\Run to autorun.
This is the usual pattern in vista and win7 where no user interaction is possible directly from the service:
MyLittleService.exe has no access to the user. But it can communicate via a named pipe with a tray icon utility.
MyLittleTrayIcon.exe communicates to the service, and can also be told to signal the user with message boxes, beep via whatever method (windows sound effects probably would be better than trying to access the PC speaker which is not guaranteed to exist on every PC anymore), etc, and maybe even can be used to control the service (restart it, reload the configuration etc).
My organisation produces a suite of Windows applications that make use of networking, and so when users run our software for the first time, the Windows Firewall (if it is running) brings up a pop-up, informing the user that our app(s) are trying to use the network, prompting the user to allow or deny access.
This occurs with plenty of other apps (Spotify, to give one example), but ee'd like to prevent these popups from happening, as they can be a bit problematic for our users. Some Applications (MSN Messenger, GoogeTalk) operate without ever causing the Firewall to alert the user, and we'd like to do the same.
We've successfully done this on Windows XP by having our installer write appropriate registry keys at:
HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List
However, this does not have the same effect on Windows 7 - the Firewall popups still take place.
Any ideas how we can do this? (Our installers and software are all digitally signed.)
Thanks
Tom Davies
You can add exceptions to Windows Firewall by shelling out to netsh, a utility built into Windows, but the utility works differently on Windows XP and Windows 7. Here are the commands I used:
Windows XP:
add:
netsh firewall add allowedprogram mode=ENABLE profile=ALL name=[exception name] program=[program path]
remove:
netsh firewall delete allowedprogram profile=ALL program=[program path]
Windows 7:
add:
netsh advfirewall firewall add rule action=allow profile=any protocol=any enable=yes direction=[in|out] name=[exception name] program=[program path]
remove:
advfirewall firewall delete rule profile=any name=[exception name]
I actually advise against making this an installer issue for several reasons:
There are multiple software firewalls
out there; you can't code and test
for all of them.
Some (such as the built-in windows
firewall ) have API's that won't
allow you to configure port
exceptions when the FW is disabled.
If the user later enables the FW you
are hosed again.
There could be external firewalls
that still get you.
Instead I prefer to make this a documentation effort so that users and administrators are fully aware of the networking requirements. I once had to goole Apple's website to figure out what ports iTunes needed and I swear to God they made it really hard to find as they tried to soften everything up for consumers.
However, if you want to give it a best faith effort in the install, WiX has a Custom Action extension for interacting with the firewall rather then writing your own Custom Action. Even if you are using another tool such as InstallShield, you can wrap this behavior up in a WiX merge module and then consume it with your primary tool of choice.
You can read about it here at:
Joy Of Setup Blog
and
WiX Documentation
In your installer (i.e. as elevated admin), you need to write code to access the Windows Firewall APIs and add your app as an exception
I have a WiX installer project where I have added two firewall exceptions as part of the installer by using the WiX FirewallException. This works great when the client machine is using Windows Firewall, but I got a report that a user failed to get the solution running when using Norman's Personal Firewall. Some question regarding this:
Will other firewall products in general respect rules added to the Windows Firewall? If so - is this just an import or will firewall products always respect changes to Windows Firewall rules?
Are there any generic way to add firewall exceptions so that all/many of the firewalls will respect them during an installer such as the Firewall extensions in WiX?
Will usage of netsh result in firewall exceptions getting added to other products than Windows Firewall?
I believe the answer to all of that is no, no and no. This is one of the reasons that I don't even try to do any of this in my installs. I always encourage application development to write systems that don't need massaging of the firewall and/or get the systems engineers to work with documentation to properly document to the end user the networking requirements. I only attempt automagical in the installer if everyone understands it's a best effort attempt and that documentation must be available to assist users in integrating into their custom environment. That and I'm naturally adverse to having my way with users operating system configuration settings without their (true) consent.
#UPDATE:
OK FOR ANYONE ELSE WHO IS SEEKING ADVICE ON THIS ISSUE...
So far, the best thing I have found is to download yourself a copy of pGina and for 2k/XP modify the GINA, and for vista/win7 you will need to create custom login credentials (pGina have the tools/samples to interface with the Vista/Win7 architecture).
to confirm -- it appears that this is what Novell are doing with Vista/Win7 rather than the traditional method of replacing the GINA (like in 2k/XP)
If anyone else comes up with a way to run an application on the logon screen in Win7 please post it.
Ok I'm writing some vb6 software that requires input before the user logs on to the system.
Basically I want to run an application on the Windows logon screen where the user can interact with the program. At present I have the application running as a service allowing to interact with the desktop, but it is still now showing.
I know that "Allow service to interact with desktop" will work in Windows 2000 / XP, I'm running Windows 7 - I am also aware that services cannot directly interact with a user as of Windows Vista - saying this, are there any other methods to get my application running on the logon screen. Novell does it
Does anyone have any other ideas to get this working?
You can only do this if you are authenticating the credentials yourself. Prior to Vista, this was done via GINA, but since Vista, you need to write your own Credential Provider.
The reasons behind this are buried deep in the security principles -- Ctrl-Alt-Del will only ever bring up the window station associated with login (etc), and no other application can get to that window station (so you can't create a fake password box over the top to scrape passwords, for instance).
Without knowing why you think your service needs to interact with that desktop, it's difficult to advise further, but it might mean that your design is broken somehow.
Service isolation will probably prevent you doing this from a service.
Pre-vista Novell and the like would probably have used GINA, which was replaced in vista; http://msdn.microsoft.com/en-gb/magazine/cc163489.aspx
The only way I know of would be to write your own msgina.dll.
It can get dicey during testing though. Any mistakes can mess up your OS so bad that a complete reinstall becomes necessary.
A fresh Windows XP SP3 install does not allow remote WMI access like Windows XP SP2 does.
If I follow the steps in the "How to troubleshoot WMI-related issues in Windows XP SP2" document at http://support.microsoft.com/kb/875605 I'm unable to get SP3 to respond to a remote WMI request.
Every request, even to the built-in Administrator account, a new account in the Administrators group, or even a new account not in the Administrators group but given access to remote DCOM & the WMI namespace as described in the Microsoft document all return error code 0x80070005, Access is denied.
To verify I didn't have a goofy system configuration, I installed a fresh Windows XP SP3 image (using the .ISO image from MSDN) and performed no configuration changes save enabling RemoteAdmin through the Firewall. The Access is denied behavior was seen in this scenario as well.
What changed in Windows XP SP3 to remote DCOM / WMI access and how best to enable it?
It turns out the issue wasn't specific to SP3, but rather the lack of these systems being in a domain.
If XP isn't in a domain then the "Use Simple File Sharing" option, found in the Folder Options control panel applet, works it magic. If this option is enabled (the default) all file sharing connections are done with the guest user credential, but this also is applied to incoming DCOM connections as well.
Disabling this option allows DCOM connections to be verified as expected.
Supposedly SP3 does not check 'Enable Distributed COM on this computer'. Get into Component Services (dcomcnfg.exe) Component Services, Computers. Right click 'My Computer' and go to properties. 'Default Properties' is the tab you want. I have also heard that changing the DTC Logon account to NT AUTHORITY\NetwerkService (note the e instead of an o) will work. You can find this under the MSDTC tab, Security Configuration following the same path to My Computer.
We solved something very similar by using these tricks. Hope this helps.
I'm not sure if RemoteAdmin is the one you need to turn off or not in the firewall.
One suggestion would be to turn off the firewall completely first and try that. If it works, then you know it is the firewall. If this is the case, then I would try adding port tcp 135 directly and try again.
You may also try using telnet [ip address of XP_SP3 machine] 135 and see if you can establish the connection.
Hope this helps.