Second Site Saver

System Center Configuration Manager 2007 is a multitalented animal for distributing software, and with the branch distribution point option you may not need a secondary site server in branch offices

Microsoft’s System Center Configuration Manager 2007 (ConfigMgr) introduces many site server roles. In this article, we look at the branch distribution point.

First, we need to define the term “branch office”. Microsoft defines it as a location with fewer than 10 workstations. When managing clients at remote locations connected via wide area network (WAN) links with Microsoft’s Systems Management Server (SMS), you had a choice of four options:

• Do nothing Simply let SMS use bandwidth as required. This wasn’t a good choice as the SMS-related traffic would be sent uncompressed and at random times with no control. This could impact other applications and users’ ability to do their job.
• Use Background Intelligent Transfer Services (BITS) Better than doing nothing, a Group Policy Object (GPO) was defined to control how much bandwidth was used by BITS and during what hours.
• Install a distribution point at the branch office The benefit of this was that the package content was only sent once across the WAN rather than each time a client requested it. The problem was, an SMS site assumed that any of its site systems were installed on machines with LAN-speed connections to the site server. As a result you had no control over when SMS sent the packages and the traffic was not compressed in any way.
• Install a secondary site Microsoft’s recommendation whenever you had clients to manage over a WAN. Installing a secondary site allowed the SMS-related traffic to be controlled in terms of the amount of bandwidth used and during which hours. And any traffic sent between SMS sites was compressed to further reduce bandwidth consumption.

Out of all these options, installing a secondary site was typically the best solution for managing branch office clients. However, many companies questioned why in such small locations they needed to go to the expense of installing and managing a secondary site where there wasn’t space to physically secure it or to house local IT support staff.

With ConfigMgr you still have the same four options as you had with SMS, plus a fifth option in the shape of a branch distribution point (BDP).

RAISON D'ETRE
The prime purpose of a BDP is to reduce the need to install a secondary site server in branch office locations. To achieve this, a workstation (or server) can be configured to host the BDP role. The BDP downloads any ConfigMgr packages in a controlled manner and then makes them available to any clients in its location, thus eliminating the need for a secondary site.
At a high level, a BDP functions in the same way as a standard DP but with some key differences, as shown in Table 1. Although it directly communicates with the site server, a BDP isn’t like all other site system roles. The BDP relies on a standard DP to provide its content (Figure 1).

For a standard DP, the Distribution Manager component is responsible for creating the DP and managing its content on an ongoing basis. In the case of a BDP, all Distribution Manager does is to initiate the creation of a policy that tells the BDP it has content to copy. At the next Policy refresh cycle, the BDP connects to a BITS-enabled standard DP in the same ConfigMgr site and initiates a pull via BITS of the relevant package(s).


Figure 1: Branch distribution point overview

BITS AND BANDWIDTH
It’s important to note that the package files are not compressed before the BDP pulls them from the standard DP (unlike when traffic is sent between ConfigMgr sites); the files are simply pulled using BITS. Even though BITS is used, you have control over when and how much bandwidth is used because a GPO for BITS exists.

Under Computer Configuration | Administrative Templates | Network | Background Intelligent Transfer Service select “Maximum network bandwidth that BITS uses” (for BITS 2.0) or “Maximum network bandwidth for BITS background transfers” (for BITS 3.0). Set the transfer rate value (in kilobits per second) you want BITS to use (10 by default), and the times during which you want this limit to apply (set at 08:00 – 17:00 by default). Limits that apply outside of these hours can also be set (the default being to “Use all available unused bandwidth”).
Table 2 highlights the bandwidth control options available for various package-sending scenarios.




WHICH BDP TO USE
It’s important to understand the process clients go through to determine which BDP/DP to use to pull their content from (the process is the same whether it’s a BDP or DP), as this can have serious implications for your design. Once a client receives a policy to inform it to download content, the client sends a content location request to a management point (MP). The MP then runs through various checks before returning a list of available BDPs/DPs to the client.

On receipt of the list, the client first looks at those flagged as “local” (based on the client’s location), giving preference to BDPs/DPs on the same subnet first, then those in the same AD site, and finally any others. If no local BDPs/DPs are available, the client will run through the same process for any remote BDPs/DPs. In all cases, the client will prefer to connect to a BITS-enabled BDP/DP.

Once the client determines which BDP(s)/DP(s) are the best to retrieve the content from, it chooses one at random which gives a degree of load balancing. The client then attempts a connection. If the connection is successful, but the client experiences any transient errors at any time, it will keep retrying the connection for up to eight hours, after which it will move onto the next BDP/DP on the list.

If the connection is unsuccessful, the client tries the next BDP/DP on the list. If there is only one BDP/DP on the list, the client will retry for up to eight hours before it fails.
Any client that is running SMS 2003 SP2 or later that is assigned to a ConfigMgr site can access any BDPs contained within that site. In the same way, any SMS 2003 SP2 or later client that roams to a ConfigMgr site can access any BDPs contained within that site.

WHAT YOU NEED
Once you’ve configured at least one BITS-enabled standard DP in the same ConfigMgr site as that where you want to create the BDP, the machine you wish to become a BDP has to be:

• A ConfigMgr client The BDP software is integrated into the ConfigMgr client as standard.
• A member of a domain Although the machine needs to be a member of a domain, it is possible for machines that are not a member to retrieve content from the BDP.
• Running Windows XP SP2 or a later operating system
• The BDP doesn’t necessarily have to run a workstation OS and in some cases you may decide you don’t want the limit that these operating systems have of only allowing 10 simultaneous incoming connections. Nominating a machine running a server-class OS such as Windows Server (Standard, Advanced or Enterprise) with SP1 or a later OS is fully supported.

INSTALLATION ISSUES
To install a BDP, first load the ConfigMgr Administrator console. Navigate to System Center Configuration Manager | Site Database | Site Management | | Site Settings. Right-click Site Systems and select New | Server from the Context menu. (Remember a BDP cannot be installed on a server share in the same way a standard DP can.)

Next run through the New Site System Server Wizard to create the BDP. On the System Role Selection page, you need to select the Distribution Point checkbox; there is no checkbox for a BDP. Select the “Enable as a branch distribution point” radio button on the Distribution Point page (Figure 2). On this page you can also set the drive to host the BDP content and to reserve a specific amount of disk space for non-BDP content on the target machine.


Figure 2: Configuring a branch distribution point

If the “Enable as a branch distribution” radio button is not available (ie greyed out), make sure there is a matching client record for the target machine in the ConfigMgr site database.
Once you’ve installed the BDP, you’ll probably want to determine which clients on which boundaries can use it (see the “How do I Protect a DP?” article on FAQShop for details of how to do this).

Microsoft does not recommend creating a BDP (or DP for that matter) on any Internet-based clients as doing so increases your risk of surface attack.

MANAGEMENT TASKS
Once the BDP is installed and running, the next task is to manage the packages you send to it. (Once installed, a BDP appears under System Status where you can monitor its status.)
Content that can be provisioned (in other words, loaded onto) a BDP is the same as a regular DP (in other words, software distribution packages, patches, Operating System Deployment images and task sequences, and the like).

There are three key ways of actually provisioning the content onto a BDP:

• Administrator provisioned
• “On-demand” package distribution
• Manual content provisioning

Administrator provisioned
This is the typical way content is distributed whereby the ConfigMgr administrator selects the BDP on which the content is to be copied in exactly the same way as for a standard DP:

• From within the ConfigMgr console go to System Center Configuration Manager | Site Database | Computer Management | Software Distribution | Packages.
• Right-click on the package you want to distribute to the BDP and select “Manage Distribution Points” to run the Manage Distribution Points wizard.
• Choose the target BDP.

Once a BDP is added to a package, a policy is sent to the BDP telling it to download the content. During the next policy update cycle (60 minutes by default), the BDP retrieves the policy and automatically starts downloading the package from a BITS-enabled standard DP in the same ConfigMgr site.

If you have lots of packages you need to send to the BDP, rather than having to go to each package to manually add the BDP, from within the ConfigMgr console go to System Center Configuration Manager | Site Database | Computer Management | Software Distribution. Right-click Packages. Select Copy Packages which will start the Copy Packages Wizard. The wizard allows you to choose which DP/BDP to copy to and the package(s) you want to copy.

Note that by default the Copy Packages functionality only copies the node type that you right-clicked, so if you right-clicked on an item under the Software Distribution node, you can only copy software distribution packages. If you want to copy other package types, such as Software Updates or Operating System Deployment, you need to right-click on the relevant folder in the ConfigMgr console and run the wizard from there.

“On-demand” package distribution
This is a new ConfigMgr content provisioning method that applies to BDPs only. Rather than having to send all of your packages to all of your DPs just in case a client needs it, you can now decide not to distribute packages to your BDPs; in other words, you don’t add the BDP to the list of DPs in the relevant package(s).

The first time a client connects to a BDP and requests a package that has not been distributed to that BDP, the BDP contacts a standard DP in the same ConfigMgr site and automatically starts downloading the package (the process is almost the same as when you add a BDP to the list of DPs for a package). “On demand” package distribution works through the properties of the package and is controlled using package creation or post-package creation.

With package creation, at the time you create a package using the New Package wizard, you select the “Make this package available on protected distribution points when requested by clients within the protected boundaries” checkbox on the Distribution Settings page (rather than the default option, “Branch distribution points automatically download this package when they receive the advertisement”).

You use post-package creation if you add a new BDP but decide you don’t want to automatically host the content there. In this case you need to go to the Properties of the package and click the Distribution Settings tab. From there make sure you’ve clicked both the radio button titled “Branch distribution points automatically download this package when they receive the advertisement” and the checkbox titled “Make this package available on protected distribution points when requested by clients within the protected boundaries”.

Manual content provisioning
With this method, rather than copying content across the WAN to get it to the BDP, you might decide to manually copy it there. To do this, first ensure you have configured the target machine as a BDP (otherwise the rest of this process will fail).

Create the SMSPKG $ directory and share it on the BDP. For example, if you want the BDP content to be hosted on the D: drive of the target machine you’d create and share the SMSPKGD$ directory.

Copy the Packages from the source DP to the SMSPKG $ directory on the BDP (for example, copy them to CD, transfer the CD to the BDP’s location and load them into the same directory on the BDP).

On the BDP go to Control Panel | Configuration Manager and click on the Actions tab. Select the “Branch Distribution Maintenance Task” then click the Initiate Action button. This task verifies that the pre-staged package is valid and then updates the list of DPs for the package on the source site server to include the BDP.

THE RESTORATION
The contents of a BDP are not backed up automatically by ConfigMgr (which applies to standard DPs as well). To back up a BDP, first disconnect any users from the SMSPKG$ share. Then back it and its contents up to backup media.
To restore a BDP:

• Reinstall the ConfigMgr client and reconfigure the machine as a BDP if it has been rebuilt.
• Create the SMSPKG $ directory and share it.
• Restore the packages to the SMSPKG$ directory.
• Go to Control Panel | Configuration Manager and click the Actions tab.
• Select the “Branch Distribution Maintenance Task” then click the Initiate Action button. This task verifies that the restored packages are valid, re-downloading any that aren’t.

FACTORS TO CONSIDER
As with anything ConfigMgr-related, whether you actually implement BDPs in your environment depends on a number of things that are unique to each environment and need to be considered carefully.

If the current level of service you offer to your branch offices is acceptable, maybe you don’t need to install a BDP. You need to weigh up the cost of procuring, installing and managing a BDP versus the cost of simply upgrading the WAN link. If there are other applications using the WAN link, maybe the owners of those apps would be open to sharing the cost of upgrading the WAN link for mutual benefit versus you installing a BDP.
Although installing a BDP may negate the need to install a secondary site, a BDP does not give you as much bandwidth control as a secondary site does. Sure, you can limit the amount of data and times during which data is copied from the standard DP to the BDP using a GPO, but you lose the benefit of content being compressed before it is sent which you have when data is sent between ConfigMgr sites.

Loss of control
Also bear in mind that if you decide to install one or more BDPs in a location with a couple of hundred machines, you only have control over the software distribution traffic. Again, what you lose by not having a secondary site is compression and the ability to control all ConfigMgr-related traffic, not just software distribution-related (for example, all the data that needs to be sent up the hierarchy from the client to its site server, such as inventory data, status messages, etc). OK, most of this traffic is small in nature, but when it’s multiplied over a couple of hundred machines and then sent totally randomly across a saturated WAN link, it could present problems.

Note also that protected boundaries only control which clients can access DP/BDP content; they play no part in determining which standard DP a BDP will obtain its content from.
BDPs cannot be installed on server shares like regular DPs, although when you create the BDP you do have the option (which I’d strongly recommend you take advantage of), of specifying which drive should be used to host the BDP and its content.

Choose wisely
Remember also that workstation operating systems such as XP can only accept 10 simultaneous incoming connections. If you have more than 10 machines at a BDP location that will need to simultaneously download content, either consider installing more than one BDP or use a server OS on the BDP to overcome this limit.

Ensure you have sufficient disk space to accommodate your packages. Disk space is typically more abundant (and easier to expand) on a server than a workstation.

DO'S AND DONT'S
Don’t install the BDP on a laptop. It may sound obvious, but there is little point installing a BDP on a machine that is likely to go off-site from the branch office and impact software distribution there.

Don’t install BDPs on Internet-based clients. Although you can do this, Microsoft strongly advises against it as it greatly increases your attack surface. Only create BDPs on machines inside your intranet or perimeter network.
If you decide to host the BDP on a user’s workstation make sure they are aware that if they switch off their machine it could affect their colleagues’ ability to receive content. This could be disastrous if you have service level agreements in place for distributing software.

BDP content (like standard DP content) is not encrypted. If the user has local admin rights, they can access the BDP content directly, which is not desirable.

You might want to consider creating more than one BDP at each location to provide failover in the event of a BDP failing. Distribution
Although “on-demand” package distribution may sound wonderful, the biggest drawback is that the user will need to wait for the package to be downloaded to the BDP before they can install it. This may be fine for small packages/patches, but if the package is something large or urgent, there will be a delay while it is downloaded. (Also bear in mind that if the package request is made during the day, you may not want a large amount of network traffic traversing your WAN links, or because of limits you’ve set for BITS a download during restricted hours could take significantly longer than one during unrestricted hours.)
Remember also:

• On-demand provisioning is controlled on a per-package basis.
• For on-demand provisioning to work, the BDP needs to be protected and the target client needs to be within the protected boundaries of the BDP. If either of these isn’t true, it won’t work.
• If you have multiple BDPs in the same protected boundary, when a client requests a package that has been configured for on-demand provisioning, it will be downloaded to all BDPs in that boundary, not just the BDP the requesting client has contacted. Again this could have a severe impact on your WAN link.

If you decide to host a BDP at a location, I’d recommend investing in a dedicated machine for this purpose that is physically secured as if it were a server to avoid as many of these potential issues as possible.

IN SUMMARY
With the new Branch Distribution Point Site System role in ConfigMgr 2007, you no longer need to either install a secondary site or have to rely on other methods to limit the impact of your clients on your WAN when it comes to software distribution.

It is now possible and supported to configure a workstation machine in a remote location and use this to host content to service local ConfigMgr client needs.
System Center Configuration Manager is an ever-increasing beast in terms of both functionality and complexity. However, with an understanding of how BDPs work and the potential issue and gotchas they present, BDPs can be a valuable addition to any ConfigMgr solution.

FURTHER READING
Configuration Manager and Content Location (Package Source Files) http://technet.microsoft.com/en-us/library/bb632366.aspx

How do I protect a DP? http://www.faqshop.com/configmgr2007/instconfig/idps/how%20protect%20dp.htm

Why is the “Enable as a branch distribution point” checkbox greyed out/unavailable? http://www.faqshop.com/configmgr2007/trobshoot/bdps/enable%20as%20bdp%20unavail.htm

How to configure on-demand package distribution to a BDP http://technet.microsoft.com/en-us/library/bb632933.aspx

How to prestage packages on a branch distribution point http://technet.microsoft.com/en-us/library/bb681046.aspx

Усовершенствования Windows Server 2008 R2: сервер DHCP

Сервер DHCP (Dynamic Host Configuration Protocol) предоставляет одну из наиболее востребованных функций в IP-сетях любого масштаба и развитости – функцию предоставления клиентам параметров конфигурации протокола IP и других параметров, необходимых клиентам для обнаружения и взаимодействия с сетевыми службами. Новая версия операционной системы Windows Server 2008 R2 привносит в свою реализацию сервера DHCP не только некоторые улучшения функционала ранних версий, но, что удивительно, и новый функционал.




Производительность.
Служба DHCP в Windows Server использует Microsoft Extensible Storage Engine (ESE, также известный как база данных JET) в качестве посредника хранения данных (конфигурации, списков резервирования, журналов аренды и пр.). Одной из возможностей ESE является возможность кэширования, позволяющая размещать в оперативную память избранные страницы или всю базу данных целиком, что существенно уменьшает время выборки и нивелирует зависимость между обращением к файлам базы и очереди к накопителю данных. Служба DHCP в Windows Server 2008 R2 использует эту возможность по умолчанию, задействовав режим «autotune cache», который указывает ESE, по возможности, загружать как можно больше страниц базы данных DHCP в оперативную память.
Такой механизм работы вызывает увеличение потребления оперативной памяти процессом, ассоциированным с сервером DHCP, например, в моменты обращения к журналу аренды с целью поиска соответствия или создания в этом журнале новой записи. В ситуации, когда сервер DHCP обслуживает запросы сотен клиентов в минуту и обладает журналом аренды для тысяч клиентов[i], размер оперативной памяти, выделяемой под эти нужды, может достигать сотен мегабайт. С целью предотвращения излишне агрессивного использования ресурса оперативной памяти, предусмотрена возможность определения максимально допустимого размера (в МБ), выделяемого для кэширования базы данных сервера DHCP: в разделе системного реестра, хранящего параметры службы DHCP[ii], можно задать параметр «JetDatabaseMaxCacheSize» (тип DWORD).
MAC-фильтрация.
Windows Server 2008 R2 привносит новый функционал в службу DHCP – фильтрацию клиентов по MAC адресам (MAC Based Filtering). Этот функционал предоставляет дополнительную возможность администраторам контролировать распределение адресного пространства по запросу от клиентов на основе протокола DHCP без необходимости обновления коммутирующего или клиентского оборудования.
В основе механизма MAC-фильтрации лежат разрешающий и запрещающий списки соответствия MAC адресов («issuance» и «denial» списки). Список может содержать как полностью определенный MAC адрес (конкретного сетевого адаптера), так и маску MAC адреса[iii], что позволяет управлять разрешениями обобщенно.
Как это работает?
Сервер DHCP обращается к спискам MAC фильтра при получении им сообщений (инспекции подвержены сообщения “Discover”, “Inform”, “Renew” и “Rebind”) от клиентов. В случае если сообщение исходит от клиента с MAC адресом, подпадающим под запись в запрещающем списке, DHCP сервер не выполняет обслуживание этого клиента (не отвечает ему). Если клиент подпадает под действие запрещающего списка на основе маски, но запись с его MAC адресом содержится в списке разрешающем, то обслуживание клиента осуществляется. В случае если MAC адрес клиента явно указан в запрещающем списке, то обслуживание клиента не осуществляется, вне зависимости от наличия соответствующей записи в списке разрешающем, т.е. явный запрет имеет абсолютный приоритет.

Как это использовать?
Важно понимать, что фильтрация на основе MAC адреса на сервере DHCP не может считаться действенным механизмом защиты доступа к сети! Данный функционал оправдан и рекомендован к использованию лишь как вспомогательное средство в сценариях, предполагающих применение ограничения в обслуживании службой DHCP доверенных узлов сети.
Управлять функционалом MAC-фильтрации можно из консоли управления сервером DHCP («DHCP Server», «dhcpmgmt.msc»): узел «Filters» («Фильтры»), а наблюдать за ее работой можно в журнале событий[iv].
Материалы по теме.
Основные сведения о протоколе DHCP
[i] Такой сценарий типичен, например, для распределенных множественных точек доступа к сети, предоставляющих своим клиентам возможности авто-конфигурирования их сетевых интерфейсов с помощью центрального сервера DHCP.

[ii] Путь в системном реестре:

«HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters».

[iii] Маска может содержать лишь один и только завершающий «wildcard».

Пример: «1A-2B-3C-*».

[iv] Event Viewer: Applications and Services Logs\ Microsoft\ Windows\ DHCP Server.

AppLocker — укрепляем безопасность вашей сети

Ваши пользователи запускают сомнительное ПО? Вы не в состоянии проконтролировать каждого пользователя? Научитесь предотвращать потенциальные угрозы атак опасного ПО штатными инструментами.

Вопросы безопасности компьютерных сетей были, есть и будут актуальны во все времена, поскольку именно от них зависит успех вашего бизнеса. Одной из самых больших и трудноразрешимых проблем безопасности является злонамеренное ПО. Компьютерные вирусы существуют уже не один десяток лет, и столько же времени идёт неустанная борьба с ними.

Этот вопрос может стать актуальным, когда сотрудник вашей фирмы по выпечке пирожков получает письмо от конкурентов с приложенным файлом. После запуска этого файла (ведь пока его не запустишь — не узнаешь, что там внутри) новый секретный рецепт фирменных пирожков вашей компании уходит к конкурентам. Другая опасность связана с тем, что зловредное ПО нарушает нормальную работу ПК — в связи с чем сотрудники не смогут полноценно выполнять свои задачи, и им приходится бороться с симптомами заражения. Поверьте, клиенты не станут ждать, пока вы решите свои проблемы, а просто уйдут к другим поставщикам.
На сегодняшний день существуют десятки специализированных программ и решений, которые предназначены для защиты от компьютерных вирусов, троянских модулей и другого опасного ПО. Однако, в действительности эффективность подобного подхода остаётся крайне низкой, поскольку чаще всего борьба ведётся лишь с уже известными производителю антивирусной программы версиями зловредного ПО. Когда антивирус обнаруживает угрозу, система зачастую уже скомпрометирована и бороться с последствиями уже бесполезно. Учитывая эту проблему, некоторые поставщики предлагают продукты, которые подходят к решению с другой стороны — пытаются устранить даже потенциальную возможность заражения. В 2001 году Microsoft выпустила первый вариант своей технологии, которая называлась Software Restrition Policies или просто SRP (о ней вы можете прочитать в статье «На страже безопасности — Sotware Restriction Policies» в номере 9/2008 журнала «Системный администратор»). За восемь лет существования этой технологии она по различным причинам так и не смогла завоевать широкую популярность. Практика показала, что управление SRP было далеко не простым, а сама реализация имела известные критические недостатки.
С выходом Windows 7 и Windows Server 2008 R2 Micosoft предлагает другое — более гибкое, удобное и ещё более надёжное средство защиты — AppLocker. Фактически AppLocker является новой архитектурной реализацией того же принципа, который был представлен в SRP. Наиболее заметным изменением стало то, что политика теперь работает не в пользовательском окружении, а в системном. Это практически лишает пользователей возможностей по обходу запретов AppLocker.

Начало работы

Для того, чтобы начать работу с AppLocker, вы должны открыть оснастку редактора групповой политики в секции Computer Configuration → Policy → Windows Settings → Security Settings → Application control Policies → AppLocker.

Рис. 1 — внешний вид консоли AppLocker

В дереве консоли вы увидите несколько дочерних элементов, в которых вы сможете создавать и редактировать правила. Они сгруппированы по типам.

• Executable Rules — могут содержать правила для файлов типов «Application» (с расширением «exe») и «MS-DOS Application» (с расширением «com»). В действительности к данной категории относятся и файлы типа «Screen saver» (с расширением «scr»), так что правила будут применяться и к ним. Однако создавать отдельные правила для этих файлов вы не можете.
• Windows Installer Rules — могут содержать правила для файлов типов «Windows Installer Package» (с расширением «msi») и «Windows Installer Patch» (с расширением «msp»).
• Script Rules — могут содержать правила для файлов типов «Windows Batch File» (с расширением «bat»), «Windows Command Script» (с расширением «cmd»), «Jscript Script File» (с расширением «js»), «PS1 File» (сценарий Windows PowerShell с расширением «ps1») и «VBScript Script File» (с расширением «vbs»).

В основном окне вы можете управлять применением правил, а также видите сводную информацию по их количеству. Чтобы изменить режим применения политики, щёлкните по ссылке «Configure rule enforcement». Для каждого типа правил можно выбрать один из двух режимов работы.

• Enforced — правила принудительно применяются к пользователям. И любой файл, для которого нет подходящего правила, будет заблокирован для запуска;
• Audit Only — режим аудита. Он полезен для определения списка ПО, которое используется пользователями. Когда включен этот режим, политики AppLocker не ограничивают запуск приложений. Но если для запускаемого файла (сценария или приложения) задано правило в политике, в журнал событий AppLocker будет добавлена соответствующая запись. Этот журнал можно просмотреть через оснастку «Event Viewer» по адресу Applications and Service logs → Microsoft → Windows → AppLocker.

Рис. 2 — окно управления режимом работы политики для каждой категории правил

На вкладке «Advanced» того же окна вы можете отдельно настроить применение политик AppLocker к файлам типа «Application extension» — динамически загружаемым библиотекам с расширением «dll». Однако используйте эту функцию с осторожностью, так как после её включения вам придётся создавать отдельные правила для файлов библиотек. А в результате проверки всех библиотек на соответствие правилам скорость работы системы может существенно снизиться.

Рис. 3 — окно управления проверкой файлов библиотек на соответствие правилам

Обратите внимание, что для применения правил в системе должна быть запущена служба «Application Identity». Для создания и редактирования правил это не требуется.

Создание правил

После краткого обзора консоли управления политикой мы можем приступать к созданию правил. К этой задаче существуют три подхода.

• Создание правил вручную;
• автоматическая генерация правил;
• автоматическое создание правил по умолчанию.

Рис. 4 — создание новых правил из контекстного меню каждого типа

В большинстве случаев я рекомендую комбинировать ручное создание правил с автоматической генерацией правил по умолчанию. Это позволит сразу создать относительно безопасную среду Для этого нажмите правой кнопкой на каждой категории и выберите элемент «Create Default Rules», после чего система создаст несколько правил по умолчанию. Пример результата для типа «Executable Files» показан на рис.5.

Рис. 5 — правила, созданные по умолчанию

Правила по умолчанию позволяют всем пользователям запускать любые исполняемые файлы из каталогов «Windows» и «Program Files». А локальным администраторам разрешают запускать вообще всё. Это достаточно щадящие правила, которые впоследствии могут быть отредактированы под ваши нужды. Так же здесь хочу отметить один достаточно важный момент — пока в конкретной категории правил политики нет ни одного правила, вы можете запускать любые файлы, которые подпадают под эту категорию. Создав хоть одно правило, вы сможете запускать только те файлы, которые подпадают под разрешения в созданных правилах.
В результате, если мы работаем под учётной записью обычного пользователя, нам будет разрешено запускать файлы только из системных каталогов. Это относится только к тем расширениям, которые проверяются политикой. Но очень часто этого будет недостаточно, именно поэтому придётся создавать и свои правила. Для этого в контекстном меню нужной категории выберите пункт «Create New Rule...», после чего вы увидите окно создания нового правила. Правила создаются пошаговым мастером, поэтому разобраться в них будет достаточно просто.

Рис. 6 — окно мастера создания правил

В секции «Before You Begin» вы можете прочитать вступление к мастеру и основные инструкции. В секции «Permissions» вы можете задать действие для правила — разрешить или запретить запуск подходящих файлов, а также выбрать группу безопасности, на которую это правило будет распространяться. Это намного удобнее, чем механизм применения политик в SRP. Теперь мы можем создать всего одну политику на уровне домена вместо того, чтобы иметь несколько отдельных политик и управлять их применением с помощью Security Filtering. Важно знать, что политики AppLocker не действуют на служебные учётные записи, например, LocalSystem. Дальше, в секции «Conditions» вы выбираете тип правила. Прежде, чем выбрать что-то из этого списка, следует рассмотреть каждый тип правил.

Правила пути

Правила пути достаточно простые, но их нужно использовать осторожно. Правила этого типа следует использовать только для тех путей, по которым пользователи не имеют права на запись. Ни в коем случае не допускается создание правил путей для каталогов, в которые пользователи могут записывать свои файлы. Ведь в результате им ничего не будет стоить подменить легитимные файлы своими и запускать их. Правила пути обычно используются для приложений, которые установлены не в стандартный каталог (Program Files), а находятся по другому адресу — например, в сетевой папке или на другом томе. Вы можете использовать подстановочные знаки — такие, как «?» и «*», а также специальные переменные окружения.

Переменная пути в AppLocker	Аналог переменной окружения в Windows	Пример
%WinDir%	%WinDir%, %SystemRoot%	“C:\Windows\”
%System32%	n/a	“C:\Windows\System32\”
%OSDrive%	%SystemDrive%	“C:\”
%ProgramFiles%	%ProgramFiles%,%ProgramFiles (x86)%	“C:\Program Files”,“C:\Program Files (x86) ”
%Removable%	n/a	CD or DVD (съёмные накопители)
%Hot%	n/a	Накопители USB (носители данных с «горячим» подключением)

Несмотря на синтаксическое совпадение с некоторыми системными переменными окружения, они таковыми не являются. К сожалению, мы лишены возможности использования системных переменных окружения во избежание их подмены. Например, при настройке SRP системные администраторы в качестве пути к сценариям входа в систему зачастую использовали такие переменные как %LogonServer% (в конструкции вроде «%LogonServer%\NetLogon\Scripts»). Это даёт гарантию подключения к сетевой папке «NetLogon» работающего контроллера домена. Сейчас же для создания подобных правил придётся использовать абсолютные пути вместо относительных.
Но это неудобство было немного компенсировано другой полезной особенностью — теперь мы можем использовать отдельные переменные для съёмных и оптических носителей.

Правила хешей

Это один из наиболее популярных типов правил как в SRP, так и в AppLocker. Правило хеша просто создаёт хеш для файла (с использованием алгоритма SHA256) и записывает его в правило. Данный тип правил следует использовать для файлов, которые расположены в разрешённых для записи пользователям каталогах. Действительно, некоторые программы для корректной работы требуют прав на создание файлов в той же папке, в которой находится сам исполняемый модуль. Для таких сценариев целесообразно использовать правило хеша. В этом случае при повреждении файла, подмены, заражения вирусом — его хеш будет также изменён, и файл окажется заблокирован для запуска. Однако, при частом обновлении программ вам с такой же периодичностью придётся обновлять и соответствующие правила хеша.

Правила издателей

Правила издателей — это следующая ступень эволюции классических правил сертификатов в SRP, которая привнесла несколько удобных нововведений. Правило издателей вы можете создавать просто указав файл с цифровой подписью. При этом следует учесть, что для этого файл должен иметь целостную подпись, а корневой сертификат подписи должен быть помещён в контейнер «Trusted Root Certification Authorites». Если хоть одно из этих условий не выполняется, то создать правило издателя не получится.

Рис. 7— окно со свойстами правила издателя

Если посмотреть на примере Microsoft Office, то мы видим достаточно информации, чтобы достоверно идентифицировать приложение. Такое правило включает поле «Subject» сертификата цифровой подписи, сведения о продукте, внутреннее имя файла и внутреннюю версия файла. Используя ползунок, мы можем задать и более общее правило, которое, например, будет разрешать запускать любой подписанный файл с указанным полем «Subject» (в правиле это поле называется «Publisher») и внутренним именем без ограничения по версии. Или даже любой файл, который подписан таким сертификатом. Также вы можете использовать и вовсе произвольные настройки правил издателей. Для этого установите флажок «Use custom Values» — и все поля станут доступны для редактирования вручную. В том числе, вы можете указывать степень соответствия версии файла как «Exact match», «And above» и «And below». Это можно использовать, когда вы хотите запретить использовать любые версии Excel младше, чем Excel 2003. Тогда вы указываете версию 11.0.0.0 и степень соответствия выставляете в «And above». В таком случае запустятся только версии Excel 2003 и более новые.
Правила издателей удобны для часто обновляемых программных файлов (например, бизнес-приложения или ваши собственные подписанные сценарии). В случае, если после обновления файлы проходят повторный процесс подписывания, они подпадут под уже существующее правило и будут запускаться.

Много правил в одном правиле

Следующим достаточно большим удобством является то, что при использовании правил путей или правил хеша, вы можете добавлять не только по одному файлу, но и группу файлов в одном каталоге. Технологически вы не имеете возможность добавить группу файлов на основе правила издателя, поскольку правило издателей не опирается на физическое местоположение файлов, а их целостность проверяется только при запуске. Когда вы выбрали правило пути или правило хеша, в следующем окне мастера вы можете нажать «Browse Folders», и тогда для правила пути мастер разрешит запускать всё из указанного каталога (это будет заметно по символу подстановки — «*» в конце пути). А для правила хеша мастер найдёт все подходящие файлы в указанной папке и подсчитает для них хеш. При этом важно отметить, что поиск не будет рекурсивным (т.е. не станет включать файлы во вложенных каталогах).
Если вы хотите исключить какие-то файлы из полученного списка, достаточно выделить нужные файлы и нажать кнопку «Remove». Вы не можете использовать отдельные исключения для правила хеша, поскольку любой хеш уникально идентифицирует конкретный файл. Иными словами под одно правило хеша может подпадать только один файл. А добавляя несколько файлов (например, все файлы в каталоге), вы создаёте целый набор отдельных правил хеша. Это следующий положительный момент в организации правил в AppLoker, поскольку эти составляющие правила вы можете группировать по какому-либо принципу. Например, создать одно общее правило хеша, которое будет называться «Microsoft Office», и внутри этого правила добавить по хешу несколько исполняемых файлов из программного пакета. Зачастую бизнес-приложения так же состоят из нескольких исполняемых модулей. Таким образом значительно повышается читабельность политик, удобство управления правилами и снижается вероятность ошибки.
Я рекомендую именно такой сценарий группировки правил — по типу приложений. Для каждого приложения вы создаёте свою коллекцию правил, в которую включаете все необходимые исполняемые модули. Таким образом, при изменении определённого приложения вам будет очень просто найти нужное правило и отредактировать его.

Исключения из правил

В отличие от правила хеша, правила пути и издателя не позволяют уникально идентифицировать файл и обладают достаточно большой областью действия. Поэтому возможны ситуации, когда вы хотите запретить запуск некоторых файлов, которые подпадают под разрешающее правило. Для этого в секции «Exceptions» мастера создания правила вы можете указать исключения.

Рис. 8 — окно «Exceptions» мастера создания правил

Как вы видите на рисунке, исключения можно создавать используя все возможности AppLocker. В порядке исключения вы можете добавлять исключаемые пути, хеши файлов и даже цифровые подписи. Например, вы разрешили все файлы по маске «%PROGRAMFILES%\Microsoft Office\*», используя правило пути. Однако вы хотите запретить запуск программы PowerPoint. Для этого вы можете создать исключение по правилу пути вида «%PROGRAMFILES%\Microsoft Office\Office12\POWERPNT.EXE» или по правилу хеша, указав конкретный файл «PowerPnt.exe».
Другой сценарий может подразумевать, что у вас есть приложение, исполняемые модули которого подписаны различными сертификатами. В таком случае правило издателя будет не очень эффективным решением, и вы приняли решение создать правило пути или правило хеша для всего каталога. Но вы хотите запретить запуск файлов, которые подписаны определённым сертификатом. В данном случае в секции «Exceptions» вы указываете тип исключения «Publisher» и в диалоговом окне поиска выбираете файл с необходимой цифровой подписью. Таким образом вы сможете запускать все файлы из каталога — кроме тех, которые подписаны указанным сертификатом.

Исключения или запреты?

Внимательные читатели могут задать вопрос: а зачем делать исключения, если их можно вынести в отдельные правила запрета? Действительно, на первый взгляд может показаться, что это более простое решение. Однако запреты всегда являются краеугольным камнем в настройке прав.
Применительно к AppLocker здесь есть несколько нюансов, которые следует учитывать при создании запретов. Самый главный из них — порядок применения правил. Для определения возможности запуска файла AppLocker при сортировке правил использует принцип первого попадания (First Match). Это означает, что правила к файлу применяются в строго определённом порядке, и действующим окажется то, которое сработало (т.е. под которое подпал файл) первым. Поэтому знание принципа сортировки правил в AppLocker может сэкономить вам время.
Все правила сортируются отдельно по запретам и разрешениям и проверяются в следующем порядке.

1. Сначала проверяются все явные запреты (в произвольном порядке).
   a) Если файл подпал под явный запрет, то для этого запрета отрабатываются все исключения. Если файл всё ещё подпадает под явный запрет, то файл блокируется для запуска.
   b) Если после обработки исключений больше не подпадает под явный запрет, то берётся следующее запрещающее правило и так продолжается, пока не будут проверены все явные запреты.
2. Если ни одного явного запрета не обнаружено, то проверяются все явные разрешения.
   a) Если файл подпал под явное разрешение, то для этого разрешения отрабатываются все исключения. Если файл всё ещё подпадает под разрешение, то файл будет разрешён для запуска.
   b) Если после обработки исключений файл больше не подпадает под явное разрешение, то берётся следующее разрешающее правило, и процесс повторяется до тех пор, пока файл после фильтрации исключений не подпадёт под разрешение.
3. Если ни одна из итераций не дала однозначный ответ вида разрешено/не разрешено, то файл блокируется для запуска.

Чтобы понять, как это работает, рассмотрим один пример.
На компьютере в каталог по умолчанию установлен пакет Microsoft Office, которым можно пользоваться всем. Но группе «Accountants» необходимо разрешить запускать только программы Word и Excel. Запуск остальных файлов из «Program Files» разрешён без ограничений.
Для решения этой задачи мы должны разрешить весь каталог «Program Files» по правилу пути для группы «Everyone». Поскольку доступ к программам Microsoft Office будет ограничен только для группы «Accountants», мы создаём новое запрещающее правило (с действием «Deny»), которое применяется только к группе «Accountants». Теперь программы из пакета Microsoft Office будут разрешены для запуска всем, кроме группы «Accountants». Чтобы обеспечить запуск только необходимых приложений из этой папки, мы редактируем запрещающее правило и добавляем два исключения (по правилу пути, хеша или издателя) для файлов «Excel.exe» и «Word.exe».
Исходя из порядка сортировки правил, в первую очередь файлы будут проверены на соответствие запрещающему правилу (запрет на каталог Microsoft Office) с учётом исключений. После этого под запретом остаётся весь каталог Mictosoft Office, но без «Word.exe» и «Excel.exe». Если у нас запретов больше нет, то применяется разрешение на каталог «Program Files» для группы «Everyone». Поскольку указанные файлы подходят под это разрешающее правило, они и будут разрешены для запуска. (Разумеется, при условии, что в этом разрешающем правиле нет исключений, действующих на эти файлы).
А вот если члены группы «Accountants» попытаются запустить PowerPoint, то ситуация окажется совершенно другой. Мы снова начинаем с первого шага. Из запрещающего правила отрабатываются исключения, т.е. Word и Excel, а затем файл снова проверяется на соответствие правилу. И даже после удаления исключений PowerPoint всё ещё подпадает под запрет. В таком случае остальные правила не проверяются, а запуск блокируется.

Импорт и экспорт правил AppLocker

В процессе эксплуатации AppLocker вы можете захотеть зафиксировать конфигурацию политик на отдельной рабочей станции перед изменением существующих правил. Одной из причин такого шага может служить необходимость отката к заведомо работоспособной конфигурации на случай, если изменения приведут к непредвиденным последствиям, а так же для использования шаблонов правил. При использовании SRP это зачастую было неразрешимым вопросом, поскольку стандартные шаблоны безопасности (Security Templates) не позволяют заранее настроить правила для SRP и сохранить их в каком-то состоянии. В AppLocker этот недостаток также решён.

Рис. 9 —контекстное меню импорта и экспорта политики AppLocker

В контекстном меню AppLocker вы можете выбрать команду «Export Policy» для экспорта и «Import Policy» для импорта политик. AppLocker сохраняет все правила и настройки в файле XML, который вы можете редактировать даже без доступа к редактору групповой политики. Если в доменной среде вы можете делать резервные копии политик с помощью GPMC, то в условиях рабочей группы (например, домашнего использования) эта возможность будет очень удобным и простым средством сохранения ваших правил AppLocker.

Заключение

В данной статье мы рассмотрели ключевые возможности нового инструмента защиты ПК от выполнения нежелательного (и потенциально злонамеренного) ПО — AppLocker. Также мы рассмотрели методику создания правил на нескольких практических примерах. Изложенный материал является достаточным для начала эффективной работы с AppLocker с целью обеспечения безопасности ваших систем. Если вы заинтересовались данной технологией и хотели бы испытать её в действии, то вы можете загрузить ознакомительную версию Windows 7 Enterprise с сайта Microsoft. Также, более глубокое изучение особенностей работы политики AppLocker вы можете прочитать в блоге автора статьи — http://www.sysadmins.lv

Ссылки

AppLocker Technical Documentation for Windows 7 and Windows Server 2008 R2 — http://www.microsoft.com/downloads/details.aspx?FamilyID=025cf2e8-b0ab-4419-b5bb-86ab2d5eca83
AppLocker Step-by-Step Guide — http://technet.microsoft.com/library/dd723686.aspx
Windows 7 Enterprise 90-day Trial — http://technet.microsoft.com/evalcenter/cc442495.aspx

So, you installed System Center Operations Manager…what next?

So, you decided to install System Center Operations Manager in your environment in order to start monitoring your environment. Or someone else installed Operations Manager for you, and it’s your job to start working with it. What should you do next?

You probably made a design or a design was made and based on that design Operations Manager is installed in your environment. For these steps a lot of documentation is available from Microsoft, a lot of this documentation can be found on the Microsoft website.

- Infrastructure Planning and Design guides: http://go.microsoft.com/fwlink/?LinkId=160871
- Technet – Operations Manager: http://technet.microsoft.com/en-us/opsmgr/default.aspx
- Technet – Operations Manager R2 Design Guide: http://technet.microsoft.com/en-us/library/dd789005.aspx
- Technet – Library: http://technet.microsoft.com/en-us/library/bb310604.aspxhttp://technet.microsoft.com/en-us/library/bb310604.aspx

Keep in mind two things:

1. Beside using Operations Manager as a tool to detect problems in your environment, Operations Manager as a product must be maintained as well.
o Tune your Operations Manager environment
o Update Management Packs
o Add Agents

2. You must seriously invest time in Operations Manager, so that engineers who use the application to detect problems in the environment will soon lose their interest in the product when Operations Manager doesn’t reflect the real situation. When “bogus” messages appear, or problems aren’t detected in System Center Operations Manager, the product will not be taken serious.

Here are some tips which can help you to start tuning your Operations Manager Environment.

Rename your Default Management Pack

By design, when you define an override you will end up saving this override in the Default Management Pack. If you save all of your overrides in one management pack though, you will eventually end up with a serious problem. That’s because you can’t delete a management pack which has another management pack which depends on it. For Example: you need to upgrade your Cluster MP, but first have to remove it because of the changes to the MP, you need to delete your Default MP; this deletes all overrides and all tuning is gone, result: lots of alerts again,etc. If you already have overrides in your default management packs you can use Override Explorer written by Boris Yanushpolsky to track them down, and move them to another management pack.

Keep in mind though, that moving an override to another management pack doesn’t remove the reference in the Manifest section of the (Default) Management Pack. In order to accomplish this you have to do some editing in the XML file as outlined in this blog post: http://blogs.technet.com/momteam/archive/2007/05/03/removing-dependencies-on-the-default-management-pack.aspx

Define Override Management Packs

For the Management Packs which are already available I suggest that you create override Management Packs per MP. Define a naming convention for these kind of Management Packs so that you can easily identify them. Use the name of the Management Pack and the word Override in the name, for example: “Windows Cluster MP – Overrides”.
I would even suggest to make a distinct in override managements packs, one which contains overrides for object you really don’t want to monitor, and another one which contains ‘fixes’ which might be resolved by later Management Packs.

Create a Closed Alerts View

By design, there is no view which contains the Closed Alerts, you may want to create this view though so that you can browse to the closed alerts. Which can help you to determine what was wrong at a certain point of time. Use the filter “resolution state equals 255” to achieve this.

Schedule a backup of your Management Packs

Define a Scheduled task which runs a Powershell script which will make an export of your management packs every night. Having your Management Packs available can help you a lot when you have problems with one of your operational Management Packs, and saves you from restoring the whole Ops DB.

Reference: Using PowerShell to import/export management packs: http://ops-mgr.spaces.live.com/Blog/cns!3D3B8489FCAA9B51!159.entry

Antivirus Exclusions on your Agents

Keep in mind that the Operations Manager Agent executes certain scripts for all kinds of tasks. If a virus scanner is blocking these scripts, the scripts can’t do their job, resulting in lots of errors. These scripts are run from the Health Service State folder, so exclude this folder containing the Operations Manager Agent installation on every Agent and disable things like the McAfee scriptscan functionality.

Firewall Ports

When your clients have the firewall enabled, keep in mind to open the necessary port based on the functionality you need. You can find more information about that in the following articles

Reference: Using a Firewall with Operations Manager 2007: http://technet.microsoft.com/en-us/library/cc540431.aspx

And if you want to install the Operations Manager Agent from the console you will need the following firewall rules enabled.

Reference: How does Computer Discovery Work in OpsMgr 2007?: http://blogs.technet.com/momteam/archive/2007/12/10/how-does-computer-discovery-work-in-opsmgr-2007.aspx

Add Agents and additional Management Packs

Out of the box, System Center Operations Manager is installed with a couple of Management Packs already installed. These Management Packs provide some basic monitoring though, so you may want to install additional Management Packs.
You can find many Management Packs in the System Center Operations Manager Management Pack Catalog, and you can find some community written Management Packs here: http://www.systemcentercentral.com/WIKI/WIKIDetails/tabid/146/indexid/20495/Default.aspx
Keep in mind though that it is a good practice to read the corresponding Management Pack Guide carefully before you import your management pack. They contain information like which discoveries are disabled by default or which overrides to set to get a “working” MP. These Management Pack Guides can be found at the following location:
System Center Operations Manager 2007 Management Pack Guides: http://technet.microsoft.com/en-us/library/dd347500.aspx

From my perspective there are two approaches to fully deploy monitoring to your infrastructure:
- Install Agents on all of your “to-be monitored machines”, and introduce one Management Pack at a time and tune it before continuing to the next MP.
- Add all the Management Packs at once and granularly deploy your Agents, tuning them agent-by-agent.

Don’t do both, because you will end up with a lot of noise by so called “false positives” being generated, and for that noise you will have to figure out if it contains valid errors or that you can discard the error. You do this by either solving a bug, or by defining an override, but having to do this all at once will “drown” you in alerts
Tuning your Operations Manager environment consists of a lot of steps to adjust the MPs. There is no cookbook on how to tune your environment, because how and what to tune depends on your environment. That’s what makes Operations Manager a product that is different for every environment ;)

You may want to start looking at the Critical alerts, check the proposed resolution steps in the alert and try to solve the problem. If you don’t understand the alert try to find more information about the alert on the Internet. There are many good blog posts out there which can help you to determine what the problem is you are experiencing, and how to solve it.

Get involved in the community

One of the big advantages of working with System Center Operations Manager is that it’s supported by a very enthusiastic community and a very involved MS product team. Many problems you will encounter are already described and solved in blog posts, and if not you can post your problem on one of the forums which is monitored by a lot of SCOM guru’s which will try to help you the best they can. Here are some suggestions:

o System Center Central – http://www.systemcentercentral.com
o Operations Manager Online Forums - http://social.technet.microsoft.com/Forums/en-US/category/systemcenteroperationsmanager

Blogs:
o Kevin Holman – http://blogs.technet.com/kevinholman/
o Boris Yanushpolsky - http://blogs.msdn.com/boris_yanushpolsky/
o Marius Satura - http://blogs.msdn.com/mariussutara/
o Stefan Stranger - http://blogs.technet.com/stefan_stranger/default.aspx
o Walter Chomak - http://blogs.technet.com/wchomak/
o Operations Manager http://ops-mgr.spaces.live.com/default.aspx
o Operations Manager Team Blog http://blogs.technet.com/momteam/default.aspx
o Operations Manager Support Team Blog - http://blogs.technet.com/operationsmgr/

Begin building your Distributed Applications

After you performed your initial tuning of the environment, and you feel comfortable with the messages you’re receiving in the SCOM Console, you can take the next step. Start building your Distributed Applications and move from Server monitoring towards Service/Application Monitoring. Here you will discover the true strength of System Center Operations Manager.
When building Distributed Applications, keep in mind that in order to successfully monitor an distributed application you need to monitor all the objects that compose the distributed application. Sometimes this means you might want to consider buying 3rd party management packs which provide this functionality, or create your own management pack.

Download this article in PDF format for easy reading