Table of Contents
- Common WMI Firewall Considerations
- WMI in Active Directory Environments
- To Enable Remote Administration Exception Using Group Policy
- To enable Windows Firewall exceptions Using Group Policy
- WMI In Workgroups and Windows NT 4.0 Based Domains
- Set password for Local Accounts
- Configure Network Access Policy
- UAC behavior in workgroups
- To Configure Windows Firewall Exceptions for Workgroups and Windows NT 4.0–Based Domains
IMPORTANT: Keep checking the MAP Blog and MAP Toolkit Content Index (en-US) for
updates and changes , especially after new versions of MAP are released.
The WMI collector in the MAP Toolkit is used to gather hardware, device, and software information from remote Windows based computers. This
collector technology is used for these inventory scenarios and must be enabled on the remote target computers.
- Windows computers
- Windows Volume Licensing
- Active devices and users
- Exchange Server
- Forefront Endpoint Protection Server
- Lync Server
- Software ID (SWID) tags
- SQL Server
- SQL Server with Database Details
- Windows Azure Platform Migration
- Oracle
- Client access tracking for Windows Server 2012
- Client access tracking for SQL Server 2012
- Client access tracking for Configuration Manager
- Client access tracking for SharePoint Server 2013
- Client access tracking for Remote Desktop Services
The Inventory and Assessment Wizard will not provide an option to enable WMI: You must enable it through Group Policy settings, logon scripts, or manually on each computer.
To connect remotely and perform the WMI inventory, you must provide accounts that are members of the local Administrators group on the computer being inventoried. For most networks, the network administrator will have a domain or local account that is a
member of the local Administrators group on all the computers in the environment. These are the accounts you should enter on the Active Directory Credentials page in the Inventory and Assessment Wizard to perform the WMI inventory. By default, in Windows domain
environments, the Domain Admins security group is added to the local Administrators group on a computer when it is joined to a domain.
Common WMI Firewall Considerations
Many host-based and software-based firewall products will block DCOM traffic across the network adapters on the computer.
For example, remote WMI connections will likely fail when attempting to connect to a computer running the Microsoft Internet Security and Acceleration (ISA) Server firewall service. To enable remote WMI access, make sure that the appropriate TCP/UDP ports
are open on the computer running the software firewall.
If your firewall doesn’t accept listing a service like WMI or Remote Administration, you will also need to open ports 135 and 1024-65535. The reason for this has to do with the way RPC works. WMI uses DCOM to communicate with remote machines, and DCOM uses
RPC extensively.
When a computer boots, WMI is assigned a dynamic port by the RPC service. When the MAP computer makes a WMI request, it first talks to the target computer’s RPC Endpoint Mapper which is listening on port 135 and asks it what port has WMI been assigned. The
RPC Endpoint Mapper replies with the port for that machine and then MAP sends the WMI query to that port. The port can be different for each machine that MAP tries to connect to, which is why we can’t be more specific than 1024-65535; since many applications
and services use RPC for remote communications, this is how they work as well.
See this MSDN topic to force WMI to use a static port. (http://msdn.microsoft.com/en-us/library/bb219447(VS.85).aspx)
Computers running Windows Firewall introduce some challenges to the inventory process. By default, Windows Firewall is configured to block remote requests to authenticate and connect to the computer via WMI. The following sections describe how to enable
the required exceptions using Group Policy and scriptable commands.
WMI in Active Directory Environments
Use the Group Policy Editor or the Group Policy Management Console to edit Group Policy for the organizational units (OUs) that contain the computers on which you will perform the assessment. For instructions, see the following resources:
- For Windows XP, see the Microsoft Support article
How To Use the Group Policy Editor to Manage Local Computer Policy in Windows XP. - For Windows Vista, see
Deploying Group Policy Using Windows Vista. - For Windows 7, see What’s New in Group Policy.
To Enable Remote Administration Exception Using Group Policy
You need to enable the Remote Administration exception for computers that have Windows Firewall enabled. This exception opens TCP port 135 used by RPC and DCOM. If you have another host firewall installed or a network firewall, you will need to consult that
system’s documentation on allowing the WMI service through the firewall.
- Click Start and then click Run. In the
Open box, type gpedit.msc and then click OK. - Under Console Root, expand Computer ConfigurationAdministrative TemplatesNetworkNetwork ConnectionsWindows Firewall and then click
Domain Profile. - Right-click Windows Firewall: Allow remote administration exception and then click
Properties. - Click Enabled and then click OK.
To enable Windows Firewall exceptions Using Group Policy
- Using the Local Group Policy Editor, expand Computer ConfigurationWindows SettingsSecurity SettingsLocal Policies and then click
Security Options. - In the Network access: Sharing and security model for local accounts section, click
Classic – local users authenticate as themselves. - Expand Computer ConfigurationAdministrative TemplatesNetworkNetwork ConnectionsWindows Firewall and then click
Domain Profile. - In the Windows Firewall: Allow remote administration exception section, click
Enabled. - In the Allow unsolicited incoming messages from box, type the IP address or subnet of the computer that will perform the inventory.
After saving the policy changes, you need to wait for up to two hours for the Group Policy settings to be applied to the client computers.
WMI In Workgroups and Windows NT 4.0 Based Domains
For computers in a workgroup, you need to manually configure each computer. For computers in a Windows NT® 4.0–based domain, use logon scripts to configure the Windows Firewall exceptions.
Set password for Local Accounts
If a computer is in a workgroup and the local account used for inventory does not have a password configured, logon is limited to the console by default. For a WMI inventory of the computer to be successful, the local account needs to be a member of the
local Administrators group and must have a password defined.
Configure Network Access Policy
If the computer is in a workgroup, you must manually change the “Network access: Sharing and security model for local accounts” policy setting from Guest only to Classic on the local computer.
- Using the Local Group Policy Editor, expand Computer ConfigurationWindows SettingsSecurity SettingsLocal Policies and then click
Security Options. - In the Network access: Sharing and security model for local accounts section, click
Classic – local users authenticate as themselves.
For more information, see
Network access: Sharing and security model for local accounts.
UAC behavior in workgroups
When you attempt to remotely connect to a machine that has UAC enabled, UAC will automatically downgrade the credentials you use for remote access to only have guest level access. This even applies to accounts that are part of the local machine’s Administrators
group. To successfully inventory computers in a workgroup that are running operating systems that support User Account Control (UAC):
- Add this DWORD registry key: HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciessystemLocalAccountTokenFilterPolicy
- Set the value to 1 and restart the machine.
Alternatively, you can use an account that is part of a local Administrators group and has UAC disabled for that account.
For more information about handling remote connections of this type, please check this link
http://msdn.microsoft.com/en-us/library/aa826699(VS.85).aspx.
To Configure Windows Firewall Exceptions for Workgroups and Windows NT 4.0–Based Domains
From a command prompt run the following command, or run it from logon script on each computer to enable the remote administration exception:
- For XP or older:
netsh firewall set service RemoteAdmin enable
- For Vista or newer:
netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes
This tutorial contains instructions to resolve the following error while trying to remotely manage a computer through Active Directory Users and Computers from the AD Domain Server 2016: «Computer cannot be connected. Verify that the network path is correct, the computer is available on the network, and that the appropriate Windows Firewall rules are enabled on the target computer.
To enable the appropriate rules Windows Firewall rules on the remote computer, open the Windows Firewall with Advanced Security snap-in and enable the following inbound rules:
COM+ Network Access (DCOM-In)…»
How to fix: Unable to Manage Computer(s) from Active Directory Users and Computers – Computer cannot be connected. (Active Directory 2016/2019)
The error message «Computer cannot be connected» in Active Directory, may appear for the following reasons:
Reason 1. The computer does not exist anymore on the network or is shut down. At this case, verify that the computer is up and running.
Reason 2. The computer’s IP Address cannot be resolved from the domain controller. The problem usually occurs when the computer uses the DNS Servers provided by the router (ISP). To fix the issue, make sure that the computer uses the AD DNS.
Troubleshooting Steps:
1. Ping the computer by using its name, or use the NSLOOKUP command to find out if the computer’s name and IP address, is resolved correctly from the DNS server.
2. If your Active Directory Domain controller acts also as a DNS Server, then go to Control Panel > Administrative Tools > DNS > Forward Lookup Zones to add the missing record.
Reason 3. The remote administration is blocked from the Windows Firewall on the target machine (the computer that you want to manage). To resolve this issue, you can disable the Windows Firewall on the target machine (but is not recommended), or to enable the COM+ Network Access on Windows Firewall, either only on the target machine or on all AD computers. To do that, follow one of the methods below:
- Method 1. Enable the COM+ Network Access (DCOM-In) on the Target Machine.
- Method 2. Enable the COM+ Network Access (DCOM-In) for all the Active Directory Computers (Group Policy).
Method 1. Enable the COM+ Network Access rule on the Target Machine.
To allow the Remote administration (enable COM+ Network Access), in Windows Firewall, in Windows 10, 8, 7 OS:
1. Open the registry editor on the computer that you want to connect/manage and navigate to the following registry location:
- ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftCOM3
2. At the right pane, double click at RemoteAccessEnabled and change the value data from 0 to 1.
3. Click OK and close the registry editor.
4. Restart the computer.
Method 2. Allow the «Remote administration» for all the Active Directory Computers through the Domain Group Policy.
To enable the COM+ Network Access rule (allow the «Remote administration»), on all the computers in the Active Directory:
1. In Server 2016 AD Domain Controller, open the Server Manager and then from Tools menu, open the Group Policy Management. *
* Additionally, navigate to Control Panel -> Administrative Tools -> Group Policy Management.
2. Under Domains, select your domain and then right click at Default Domain Policy and choose Edit.
3. Then navigate to:
- Computer ConfigurationPoliciesAdministrative TemplatesNetworkNetwork ConnectionsWindows FirewallDomain Profile
4. At the right pane, double click at: Windows Firewall: Allow inbound remote administration exception
5. Check Enabled and click OK.
6. Close the Group Policy Management editor.
7. Finally, open Command Prompt as Administrator and give the following command to update the group policy.
- gpupdate /force
That’s it! Which method worked for you?
Let me know if this guide has helped you by leaving your comment about your experience. Please like and share this guide to help others.
If this article was useful for you, please consider supporting us by making a donation. Even $1 can a make a huge difference for us in our effort to continue to help others while keeping this site free:
If you want to stay constantly protected from malware threats, existing and future ones, we recommend that you install Malwarebytes Anti-Malware PRO by clicking below (we
do earn a commision from sales generated from this link, but at no additional cost to you. We have experience with this software and we recommend it because it is helpful and useful):
Full household PC Protection — Protect up to 3 PCs with NEW Malwarebytes Anti-Malware Premium!
|
Рубрика: Безопасность / Сетевая безопасность |
Мой мир Вконтакте Одноклассники Google+ |
Андрей Бирюков
Windows Firewall: защищаем внутренние ресурсы сети
Сейчас локальная сеть любой, даже совсем небольшой организации, защищена от внешних угроз. Настолько ли хорошо защищены ресурсы внутренней сети?
Защита снаружи, но не изнутри
Современные средства защиты корпоративных ресурсов от внешних угроз весьма разнообразны, существуют как аппаратные и программные межсетевые экраны (например, Cisco PIX, CheckPoint или Microsoft ISA), так и системы обнаружения вторжения, разбирающие проходящие пакеты до уровня приложений, а также шлюзовые антивирусы, фильтрующие определенный вид трафика. Все эти грозные и дорогостоящие средства защищают наши ресурсы от посягательств извне. Однако стоит оказаться внутри локальной сети компании, как тут же обнаруживается, что на большинстве пользовательских машин персональные межсетевые экраны или отключены, или работают в режиме разрешения всех входящих соединений. Такое положение вещей многие системные администраторы объясняют просто: «Нам нужен полный доступ к локальной машине пользователя, и у нас нет времени на настройку портов». Таким образом, получаем ситуацию, когда рабочие станции не защищены персональным межсетевым экраном и в случае если вредоносный код каким-либо образом сумеет проникнуть в локальную сеть, последствия могут оказаться весьма неприятными.
Проблему защиты рабочих станций можно решать с помощью различных средств. Например, многие корпоративные антивирусы имеют встроенный межсетевой экран, политики для которого можно задавать централизованно, но сегодня я продемонстрирую аналогичную защиту рабочих станций с помощью стандартных средств Windows, Active Directory и WSH. Сначала опишу, как автоматически установить firewall и задать соответствующие разрешения для машин, находящихся в домене, а затем, как проделать то же самое у пользователей, не входящих в домен, с помощью сценариев Windows Script Host.
Персональный межсетевой экран Windows XP SP2 и Windows 2003 Server SP 1 автоматически включен и используется для защиты всех сетевых соединений, однако для того чтобы гарантировать запуск службы Firewall на машине пользователя, пропишем его в групповой политике. Предварительно необходимо все пользовательские машины, на которых предполагается включить firewall, поместить в отдельную организационную единицу (Organization Unit). Категорически не рекомендуется применять политики, о которых речь пойдет далее, ко всему домену, так как тогда они применются и к серверам, вследствие чего могут быть закрыты порты, необходимые для нормального функционирования клиент серверных приложений. Итак, необходимая организационная единица создана, и пользовательские машины туда помещены. Теперь на контроллере домена откройте оснастку Active Directory Users And Computers, далее «Computer Management -> Windows Settings -> Security Settings -> System Services -> Windows Firewall». Включаем использование этого сервиса (Enable) и метод запуска автоматический (Startup Automatic) (см. рис. 1).
Рисунок 1. Список сервисов, запускаемых в GPO
Теперь в вашей сети на всех пользовательских машинах запущен сервис Windows Firewall. Следующим шагом укажите приложения и порты, к которым вы хотите разрешить доступ снаружи. К сожалению, версия персонального межсетевого экрана, входящая в состав Windows XP 2003, не позволяет блокировать исходящие соединения, только входящие, поэтому будет открываться доступ только снаружи внутрь.
Что и кому открывать
Так как правила межсетевого экрана работают по принципу «запрещено всё, что не разрешено», то прежде чем включить firewall, вам необходимо определиться с тем, какие порты должны быть открыты на клиентской машине. По возможности постарайтесь минимизировать это количество, так как чем меньше открытых портов, тем меньше потенциальных уязвимостей в защите системы.
В качестве примера буду открывать порты для корпоративного антивируса, удаленного управления и видеоконференций, а также явным образом буду блокировать доступ к порту, используемому сетевыми играми. Также доступ к каждому из портов должен быть разрешен только с определенных узлов или подсетей. Вот что нужно открыть (см. таблицу).
Правила, которые необходимо настроить на межсетевом экране
|
Порт |
Протокол |
Источник |
Действие |
Описание |
|
10001 |
TCP |
172.29.0.0/24 |
Enable |
Antivirus |
|
3999 |
TCP |
172.29.0.2, 172.29.0.200 |
Enable |
Remote Admin |
|
666 |
TCP |
* |
Disable |
No Games |
|
999 |
UDP |
Localsubnet |
Enable |
Stream Video |
Небольшое пояснение к предъявляемым требованиям: в первой строке я разрешаю доступ по порту 10001 всем хостам, находящимся в подсети 172.29.0.0 с маской 255.255.255.0, во второй – к порту 3999 только двум хостам 172.29.0.2, 172.29.0.20, в третьей всем пользователям явным образом запрещено устанавливать соединение по порту, который используют сетевые игры, и наконец в четвертой строке все пользователи локальной подсети могут отправлять UDP-пакеты на порт 999.
Отдельно скажу про ICMP. Администратор должен иметь возможность пропинговать любой узел в своей сети, но при этом не следует разрешать любые операции с этим протоколом, так как существуют виды атак, позволяющие с помощью атак вида Denial Of Service осуществить отказ в обслуживании системы. Таким образом, подводя итог всему изложенному в данном абзаце, будет разрешаться только отклик на входящий эхо-запрос.
Открываем порты
Определившись с тем, какие порты и кому вы хотите открыть, пропишите все эти правила в групповых политиках Active Directory. Для этого откройте ту же групповую политику, которую вы использовали для запуска сервиса Firewall, затем раздел «Computer Management -> Administrative Templates -> Network -> Network Connections -> Windows Firewall». Далее есть два профиля Domain и Standard. Профиль Domain применяется, когда машина подключена к Active Directory, обычно Domain Profile используется для рабочих станций пользователей. Профиль Standard применяется, когда машина не подключена к Active Directory, как правило Standard Profile используется для ноутбуков и портативных компьютеров. В нашем примере мы будем рассматривать Domain Profile.
Как видно из рис. 2, у межсетевого экрана имеется 14 свойств, которые мы и будем сейчас настраивать:
- Protect All Network Connections – использовать ли межсетевой экран для всех соединений (LAN, Dial Up и др.).
- Do not allow exceptions – не позволять исключения. В нашем случае необходимо выставить Disabled, так как исключения, то есть открытые порты, у нас есть.
- Define program exceptions – определяет приложения, обращение к которым разрешено извне. Не самый безопасный способ, лучше ограничивать по портам, чем по приложениям.
- Allow local program exceptions – разрешать исключения для приложений.
- Allow remote administration exception – разрешать удаленное администрирование средствами Windows.
- Allow file and printer sharing exception – разрешать доступ к файловым ресурсам и принтерам, подключенным к данной машине.
- Allow ICMP exceptions – разрешать исключения для протокола ICMP. В соответствии с тем, что было сказано ранее про ICMP, мы разрешим только Inbound echo request (см. рис. 3).
- Allow Remote Desktop exception – разрешать установку соединения по протоколу RDP.
- Allow UPnP exception – позволять исключения для universal Plug and Play (технология, позволяющая различным интеллектуальным устройствам устаналивать соединения интернет-технологий).
- Prohibit notifications – запрещать уведомления пользователя.
- Allow logging – разрешать журналирование. При этом вы можете сохранять информацию об отклоненных пакетах и об успешных соединениях. Как правило имеет смысл вести журналирование только отброшенных пакетов, в случае учета всех соединений лог становится практически нечитаемым из-за своего большого размера.
- Prohibit unicast response to multicast or broadcast – запрещать отправку пакетов в ответ на широковещательные запросы.
- Define port exceptions – определяем порты, которые будут открыты на межсетевом экране.
- Allow local port exceptions – разрешить локальные исключения для портов.
Рисунок 2. Свойства межсетевого экрана
Рисунок 3. Исключения для протокола ICMP
Итак, укажите те порты, которые хотите открыть на всех пользовательских машинах в организационной единице.
Открыв свойства «Define Port Exceptions», выбираете «Enabled», затем «Define port exceptions: Show…». В открывшемся окне вам необходимо определить список портов в соответствии со следующим форматом.
<порт>:<протокол>:<источник>:<действие>:<описание>
Таким образом, после выполнения этих действий вы получите список портов, которые необходимо открыть либо явным образом закрыть (рис. 4).
Рисунок 4. Определяем список портов
Вот собственно и все, что нужно сделать для того, чтобы развернуть на машинах в локальной сети под управлением Active Directory межсетевой экран и открыть необходимые порты.
Для тех, кто вне домена…
Что же делать, если у вас имеются машины, не входящие в домен, например, сеть филиала или ноутбуки сотрудников, находящихся в командировке. В такой ситуации можно прибегнуть к помощи сценариев Windows Script Host. Этот сценарий можно отправить по электронной почте, снабдив получателя соответствующими инструкциями по его запуску. Кстати, сценарий, открывающий порты на межсетевом экране, может быть также полезен при развертывании приложений, которым для работы необходимы открытые порты на firewall.
При работе с Windows Firewall через сценарии WSH обратите внимание на то, что этот объект не является WMI-классом, а СОМ-объектом из библиотеки HNetCfg (Home Networking Configuration), которая в свою очередь обеспечивает большинство функций межсетевого экрана.
Для обращения к библиотеке HNetCfg в нашем сценарии обязательно должна присутствовать строка:
Set objFirewall = CreateObject(«HNetCfg.FwMgr»)
Эта библиотека содержит ряд объектов:
- LocalPolicy – этот объект определяет, использовать ли локальную политику межсетевого экрана (в оснастке Group Policy она называлась Standard) или же доменную политику (Domain).
- Profile – объекты управляют профилем Windows Firewall и включают следующие свойства:
- AuthorizedApplications – набор авторизованных приложений, к которым разрешено обращение снаружи. Этот список использует объект Profile.
- CurrentProfile – свойство задает текущий профиль межсетевого экрана. Для установки этого значения используйте команду NetCfg.FwMgr.LocalPolicy.CurrentProfile.
- CurrentProfileType –устанавливает тип профиля, который использует Windows Firewall. Может иметь значения: 0 (ноль), если используемый профиль является доменным, или 1, если это стандартный профиль.
- ExceptionsNotAllowed – свойство указывает, разрешать ли использование исключений в Windows Firewall, может иметь значения TRUE или FALSE. Это необходимый элемент для любого профиля.
- FirewallEnable – данное свойство определяет, должен ли быть включен межсетевой экран на машине, возможные значения TRUE или FALSE. Это свойство доступно через объект Profile.
- GetProfileByType – позволяет получить тип профиля (Domain или Standard). Например, вызов HNetCfg.FwMgr.GetProfileByType для сценария, используемого в данной статье вернет 0 (Domain). Может использоваться только для объекта CurrentProfile.
- GloballyOpenPorts – это список открытых портов для данного профиля. Данное свойство доступно через объект профиля.
- IcmpSettings – свойство доступно только для чтения и определяет настройки по протоколу ICMP. Также доступно через свойства профиля.
- NotificationsDisabled – определяет, отправлять ли пользователю уведомления, возможные значения TRUE или FALSE. Доступно через свойства профиля.
- RemoteAdminSettings – разрешать или запрещать удаленное управление системой. Доступно через свойства профиля.
- Services – набор служб (Services), содержащихся в профиле. Также доступно через свойства профиля.
- Type – показывает тип профиля, доменный или стандартный (0 для доменного и 1 для стандартного). Доступно через свойства профиля.
Определившись с объектами, которые вы можете использовать при написании WSH-сценария, попробуйте открыть нужные порты на пользовательской машине. Отмечу, что сценарий использует тот же набор параметров, что и групповая политика Active Directory, с одной лишь разницей, что здесь есть возможность динамически задавать и изменять политику межсетевого экрана. Развернуть сценарий на удаленной машине можно, к примеру, отправив данный файл прикрепленным к письму или с помощью FTP. В любом случае вмешательство пользователя для установки сценария будет минимальным.
Листинг 1. Сценарий для открытия нового порта
‘ объявляется объект HNetCfg
Set objFirewall = CreateObject(«HNetCfg.FwMgr»)
‘ используется текущий профиль
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
‘ создается новый открытый порт
Set objPort = CreateObject(«HNetCfg.FwOpenPort»)
objPort.Port = 10001 ‘ номер порта
objPort.Name= «Antivirus» ‘ наименование
objPort.IPVersion=4 ‘ версия IP
objPort.Protocol= «TCP» ‘ вид протокоа
‘ с каких адресов разрешен доступ
objPort.RemoteAddresses=»172.29.0.0/24″
objPort.Enabled = TRUE ‘ доступ разрешен
‘ используется список уже открытых портов
Set colPorts = objPolicy.GloballyOpenPorts
‘ добавляется новый порт в список уже открытых портов
errReturn = colPorts.Add(objPort)
По аналогии для остальных портов вы сможете написать подобный сценарий. В приведенном примере указание версии протокола IP является необязательным, так как по умолчанию используется IP v4. Как видно из примера, сначала открывается порт, затем прописываются необходимые параметры, такие как вид транспортного протокола, подсеть, которой разрешен доступ и наименование. И в завершении все данные по новому порту добавляются в список уже открытых портов.
В продолжении темы приведу пример сценария, который разрешает доступ по сети к указанному приложению, то есть авторизовывает приложение. Как уже упоминалось выше, этот способ является не слишком безопасным, так как приложение может использовать различные порты, но иногда он более удобен, чем явное открытие портов. В следующем примере откроем доступ для приложения, находящегося по адресу c:myapp.exe для всех узлов по протоколу IP версии 4.
Листинг 2. Сценарий для авторизации приложения
‘ объявляем объект
Set objFirewall = CreateObject(«HNetCfg.FwMgr»)
‘ используем текущий профиль
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
‘ объявляем объект
Set objApplication = CreateObject(«HNetCfg.FwAuthorizedApplication»)
objApplication.Name = «Corp App» ‘ указываем имя
objApplication.IPVersion = 4 ‘ версия IP
‘ путь к приложению
objApplication.ProcessImageFileName = «c:myappl.exe»
‘ с каких адресов разрешен доступ
objApplication.RemoteAddresses = «*»
objApplication.Enabled = True
‘ авторизуем приложение
Set colApplications = objPolicy.AuthorizedApplications
‘ и добавляем его в список авторизованных приложений
colApplications.Add(objApplication)
Иногда возникает необходимость в получении списка всех открытых портов, а также их свойств:
Листинг 3. Сценарий, выводящий список всех открытых портов
Set objFirewall = CreateObject(«HNetCfg.FwMgr»)
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Set colPorts = objPolicy.GloballyOpenPorts
For Each objPort in colPorts
Wscript.Echo «Port name: » & objPort.Name
Wscript.Echo «Port number: » & objPort.Port
Wscript.Echo «Port IP version: » & objPort.IPVersion
Wscript.Echo «Port protocol: » & objPort.Protocol
Wscript.Echo «Port scope: » & objPort.Scope
Wscript.Echo «Port remote addresses: » & objPort.RemoteAddresses
Wscript.Echo «Port enabled: » & objPort.Enabled
Wscript.Echo «Port built-in: » & objPort.Builtin
Next
Эта информация вам пригодится, когда вы будете изучать состояния текущих правил межсетевого экрана и определять, какие порты необходимо открыть или закрыть.
Завершая тему персональных межсетевых экранов, отмечу, что по утверждениям представителей корпорации Microsoft, в следующей версии операционной системы Windows межсетевой экран будет двусторонним, то есть можно открывать/закрывать как входящие, так и исходящие соединения. Что ж, посмотрим, но думаю, подобное нововведение окажется весьма полезным, так как позволит еще больше защитить рабочие станции и пользователей.
Поживем – увидим.
- Don Jones, Jeffery Hicks Advanced VBScript for Microsoft Windows Administrators.
- Windows Server 2003. Справочник администратора.
Мой мир
Вконтакте
Одноклассники
Google+
Greetings!
We are setting up Spiceworks on a Windows 2003 Server. Spiceworks is not integrating well with our environment due to the fact that our desktop machines are running XP, and Windows 7. Spiceworks indicated that the issue is with Windows firewall on the desktop PC’s. The FAQ’s here in the community indicate that we need to edit the Group Policy on our 2003 server to update windows frewall settings on the local machines, but I am feeling a bit lost with these group policy instructions.
<SNIP>
Optionally, you may choose to manage Windows Firewall centrally via Group Policy.
The equivalent Group Policy setting is:
Windows Firewall: Allow remote administration exception
The setting path in Group Policy is:
Computer Configuration/Administrative Templates/Network/
Network Connections/Windows Firewall/Domain Profile
<End>
So how do we get to this setting path?
Kind regards,
Brian
check
Best Answer
Hey Brian, I saw your PM. You’re definitely on the right path thanks to the help from Thomas, Brian S, and Grant.
I would also recommend what Grant said — use RSOP (Resultant Set of Policy) to check one of the remote devices and ensure the GPO you created is actually being applied.
Did you create a new GPO for the firewall rule in the past (the one you found), or was it enabled on a default policy (like the Default Domain Policy). Just be sure you aren’t confusing «Default Domain Policy» and the GPO for Domain Controllers — I think its «Default Domain Controller Policy». I’ve done that before by accident!
As Brian S said, I’d recommend creating a new GPO and using it for Spiceworks specific purposes. It’ll make tracking things (i.e. confirming GPOs are applied) easier.
Was this post helpful?
thumb_up
thumb_down
View Best Answer in replies below
Read these next…
Merging two domains with the same name?
Windows
It seems that a possible company merger is coming down the pipeline, but as luck would have it, the active directory domains have the same name (ie, domain.local)The domain I maintain is running server 2019 at a 2016/2019 functional level.The other domain…
How can I track changes to network adapter configuration
Windows
Ok, so we have a site where most of the users have local admin and they have a small group of users who «know about computers». The site runs pretty smoothly but we’re seeing a bunch of users who are able to function on the wired network but aren’t able …
Snap! — Cooling in Antarctica, Back to the Moon, Biological Clothing, AI Sci-Fi
Spiceworks Originals
Your daily dose of tech news, in brief.
Welcome to the Snap!
Flashback: February 3, 1986: The term “vaporware” is first used by Philip Elmer-DeWitt in a TIME magazine article (Read more HERE.)
Bonus Flashback: February 3, 1966: Luna 9 Lan…
Safety Glasses with Glasses
Networking
I’m going to be pulling some new wire soon through some dirty drop ceilings, and without fail, at some point I always get a piece of something in my eye at some point during the job.I’d like to avoid that this time.I have struggled to find safety glasses …
AD on-premise courses
IT & Tech Careers
Hello!We have a predominantly on-prem AD environment. Whilst we will be moving to M365 that will be in a while.We have a number of junior staff that need basic instruction in Active Directory and file/folder permissions. I recall many years ago the MC…
Allows remote administration of this computer using administrative tools such as the Microsoft Management Console (MMC) and Windows Management Instrumentation (WMI). To do this Windows Firewall opens TCP ports 135 and 445. Services typically use these ports to communicate using remote procedure calls (RPC) and Distributed Component Object Model (DCOM). Additionally on Windows XP Professional with at least SP2 and Windows Server 2003 with at least SP1 this policy setting also allows SVCHOST.EXE and LSASS.EXE to receive unsolicited incoming messages and allows hosted services to open additional dynamically-assigned ports typically in the range of 1024 to 1034. On Windows Vista this policy setting does not control connections to SVCHOST.EXE and LSASS.EXE.If you enable this policy setting Windows Firewall allows the computer to receive the unsolicited incoming messages associated with remote administration. You must specify the IP addresses or subnets from which these incoming messages are allowed.If you disable or do not configure this policy setting Windows Firewall does not open TCP port 135 or 445. Also on Windows XP Professional with at least SP2 and Windows Server 2003 with at least SP1 Windows Firewall prevents SVCHOST.EXE and LSASS.EXE from receiving unsolicited incoming messages and prevents hosted services from opening additional dynamically-assigned ports. Because disabling this policy setting does not block TCP port 445 it does not conflict with the «Windows Firewall: Allow file and printer sharing exception» policy setting.Note: Malicious users often attempt to attack networks and computers using RPC and DCOM. We recommend that you contact the manufacturers of your critical programs to determine if they are hosted by SVCHOST.exe or LSASS.exe or if they require RPC and DCOM communication. If they do not then do not enable this policy setting.Note: If any policy setting opens TCP port 445 Windows Firewall allows inbound ICMP echo request messages (the message sent by the Ping utility) even if the «Windows Firewall: Allow ICMP exceptions» policy setting would block them. Policy settings that can open TCP port 445 include «Windows Firewall: Allow inbound file and printer sharing exception» «Windows Firewall: Allow inbound remote administration exception» and «Windows Firewall: Define inbound port exceptions.»
Policy path:
NetworkNetwork ConnectionsWindows FirewallStandard Profile
Scope:
Supported on:
At least Windows XP Professional with SP2
Registry settings:
HKLMSOFTWAREPoliciesMicrosoftWindowsFirewallStandardProfileRemoteAdminSettings!Enabled; HKLMSOFTWAREPoliciesMicrosoftWindowsFirewallStandardProfileRemoteAdminSettings!RemoteAddresses