+7 (812) 325 84 00

+7 (499) 322 07 96

Веб прокси Squid на CentOS 8 в окружении Active Directory 2019

Squid вполне может служить бесплатной альтернативой коммерческим прокси-серверам в небольших сетях. В Интернете есть достаточное количество руководств по интеграции Squid с Active Directory, настройке контроля доступа и другим вопросам. Опыт показывает, что зачастую руководства эти содержат неточности, даже ошибки, иногда прямо противоречат друг другу - отчасти потому, что операционная система и Squid имеют огромное количество настроечных параметров, и одни и те же задачи можно решать несколькими способами.

Статья описывает минимальную рабочую конфигурацию прокси Squid на CentOS Stream 8 в связке с Windows Server 2019 Active Directory, с авторизацией Kerberos, NTLM и, опционально, LDAP.

1.    Описание среды

·         Домен Active Directory - papa.local (NetBIOS имя PAPA), ОС контроллеров домена - Windows Server 2019 Datacenter Edition, функциональные уровни домена и леса – Windows Server 2016;

·         Подсеть - 192.168.44.0/24, шлюз по умолчанию - 192.168.44.2;

·         Контроллеры домена - cntr-dc2.papa.local (IP-адрес 192.168.44.12) и cntr-dc4.papa.local (IP-адрес 192.168.44.28); мастер всех операций - cntr-dc4.papa.local;

·         Службы DNS и WINS (для совместимости) размещены на контроллерах домена;

·         Сервер Squid с одним сетевым интерфейсом, ОС - CentOS Stream 8, имя хоста - cntr-gate4.papa.local, IP-адрес - 192.168.44.35;

·         В домене AD для авторизации Squid создан специальный пользователь PAPA\squid (UPN squid@papa.local) с достаточно стойким паролем без ограничения срока действия, учетная запись размещена в OU Papa.local/Special;

·         Вся инфраструктура – виртуальная Hyper-V (в принципе, это неважно).

2.    Установка CentOS

Установка со стандартного дистрибутива CentOS Stream 8, вариант установки – Minimal Install, задаем пароль для root:


Задаем IP-адрес, шлюз по умолчанию и серверы DNS - контроллеры домена, имя хоста cntr-gate4.papa.local и суффикс поиска DNS papa.local :

Задаем NTP-серверы - используем службу NTP контроллеров домена, временная зона Europe/Moscow:




После установки системы следует перезагрузка.

3.    Предварительная конфигурация и установка Squid

Обновляем систему:

dnf update

Устанавливаем ntpstat и проверяем синхронизацию времени:

dnf install ntpstat

ntpstat

chronyc sources -v

Должны увидеть успешную синхронизацию времени:


Добавляем разрешение порта 3128/tcp для прокси Squid:

firewall-cmd --permanent --add-port=3128/tcp

firewall-cmd --reload

Устанавливаем Squid (для нашей конфигурации достаточно готового пакета из репозитария):

dnf install squid

Объявляем в /etc/squid/squid.conf нашу сеть как локальную:

acl localnet src 192.168.44.0/24

Включаем службу Squid для автоматического запуска:

systemctl enable squid --now

4.    Настройка Kerberos

Сначала мы должны подготовить файл ключей (keytab) для Kerberos. Для этого запускаем на контроллере домена следующую команду:

ktpass /princ HTTP/cntr-gate4.papa.local@PAPA.LOCAL /mapuser squid@PAPA.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass "password" /out proxy.keytab

Регистр символов важен! Пароль указывается в двойных кавычках, значение “password“ взято для примера. Результирующий файл proxy.keytab необходимо скопировать в каталог /etc/squid на системе CentOS (cntr-gate4.papa.local).

Учетная запись PAPA\squid в AD выглядит так:


Все остальное делается на системе CentOS. Устанавливаем необходимые пакеты для поддержки Kerberos:

dnf install cyrus-sasl-gssapi krb5-workstation krb5-devel

Теперь редактируем файл конфигурации Kerberos /etc/krb5.conf. У меня файл получился такой:

# To opt out of the system crypto-policies configuration of krb5, remove the

# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.

includedir /etc/krb5.conf.d/

[logging]

   default = FILE:/var/log/krb5libs.log

   kdc = FILE:/var/log/krb5kdc.log

   admin_server = FILE:/var/log/kadmind.log

[libdefaults]

   dns_lookup_realm = false

   ticket_lifetime = 24h

   renew_lifetime = 7d

   forwardable = true

   rdns = false

   pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt

   spake_preauth_groups = edwards25519

   default_realm = PAPA.LOCAL

   default_ccache_name = KEYRING:persistent:%{uid}

[realms]

PAPA.LOCAL = {

   kdc = cntr-dc2.papa.local

   kdc = cntr-dc4.papa.local

   admin_server = cntr-dc2.papa.local

   admin_server = cntr-dc4.papa.local

}

[domain_realm]

   .papa.local = PAPA.LOCAL

   papa.local = PAPA.LOCAL

После правки файла /etc/krb5.conf перегружаем систему командой reboot.

Теперь нужно проверить корректность работы Kerberos. Для этого, получаем билеты от KDC и проверяем результат (я для примера сначала использую встроенную учетную запись администратора домена AD, но это не обязательно):

kinit Administrator

klist

kinit -V -k -t /etc/squid/proxy.keytab HTTP/cntr-gate4.papa.local@PAPA.LOCAL

klist

Если мы все сделали правильно, то должны увидеть что-то, похожее на это:

Файл ключей proxy.keytab критичен с точки зрения безопасности системы. Поскольку он предназначен специально для сервиса Squid, ограничиваем доступ к нему только для учетной записи службы:

chown squid:squid /etc/squid/proxy.keytab

chmod 400 /etc/squid/proxy.keytab

Теперь можно править файл конфигурации Squid. Модифицируем /etc/squid/squid.conf, для поддержки обязательной аутентификации Kerberos добавляем в него следующие строки:

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/proxy.keytab -s HTTP/cntr-gate4.papa.local@PAPA.LOCAL

auth_param negotiate children 100 startup=0 idle=10

auth_param negotiate keep_alive on

acl authenticated_user proxy_auth REQUIRED

http_access deny !authenticated_user

Регистр, опять-таки, здесь важен. Последние две строчки нужны, чтобы запретить доступ неавторизованным пользователям, сделав авторизацию обязательной.

Перезапускаем Squid, чтобы конфигурация вступила в силу:

service squid restart

Настройка авторизации Kerberos на этом закончена.

5.    Настройка NTLM

Так или иначе, обычно этот старый протокол в доменной среде до сих пор используется, несмотря на его очевидные недостатки. Поэтому, здесь описывается рабочая конфигурация для NTLM тоже. Для поддержки NTLM, мы используем связку Samba/Winbind.

Устанавливаем необходимые пакеты для поддержки Samba и Winbind:

dnf install samba samba-client samba-winbind samba-winbind-clients krb5-workstation

Включаем необходимые службы:

systemctl enable smb

systemctl enable nmb

systemctl start smb

systemctl start nmb

Теперь редактируем файл конфигурации Samba /etc/samba/smb.conf для членства в домене. У меня файл получился такой:

# See smb.conf.example for a more detailed config file or

# read the smb.conf manpage.

# Run 'testparm' to verify the config is correct after

# you modified it.

[global]

   workgroup = PAPA

   password server = cntr-dc4.papa.local

   realm = PAPA.LOCAL

   security = ads

   idmap uid = 10000-20000

   idmap gid = 10000-20000

   winbind use default domain = no

   winbind request timeout = 300

   wins server = 192.168.44.28

   passdb backend = tdbsam

   printing = cups

   printcap name = cups

   load printers = yes

   cups options = raw

[homes]

   comment = Home Directories

   valid users = %S, %D%w%S

   browseable = No

   read only = No

   inherit acls = Yes

[printers]

   comment = All Printers

   path = /var/tmp

   printable = Yes

   create mask = 0600

   browseable = No

[print$]

   comment = Printer Drivers

   path = /var/lib/samba/drivers

   write list = @printadmin root

   force group = @printadmin

   create mask = 0664

   directory mask = 0775

Включаем систему в домен, используя учетную запись Active Directory с правом добавления компьютеров. У меня это встроенная учетная запись администратора:

net ads join -U Administrator

Вводим пароль и проверяем членство в домене:

net ads testjoin

Если мы все сделали правильно, то должны увидеть “Join is OK”:

при этом, в домене AD (по умолчанию в стандартном контейнере Computers) должен создаться объект компьютера для CNTR-GATE4.

Перестартуем службы Samba и включаем Winbind:

systemctl restart smb

systemctl restart nmb

systemctl enable winbind

systemctl start winbind

Проверяем функциональность Winbind:

wbinfo -g

wbinfo -u

Должны увидеть что-то похожее на это:


(это мои примеры. В любом случае, это должны быть валидные списки групп и пользователей домена).

Теперь можно править файл конфигурации Squid. Модифицируем /etc/squid/squid.conf, для поддержки аутентификации NTLM добавляем в него следующие строки:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp --domain=PAPA

auth_param ntlm children 100 startup=0 idle=10

auth_param ntlm keep_alive off

Перезапускаем Squid, чтобы конфигурация вступила в силу:

service squid restart

Настройка авторизации NTLM закончена.

6.    Настройка LDAP (опционально)

Squid позволяет настроить авторизацию также и по протоколу LDAP. В данном примере, доступ предоставляется для членов группы безопасности AD InternetAccess в домене papa.local с помощью стандартного helper’а ext_ldap_group_acl. Для этого в конфигурацию Squid необходимо добавить следующие строки:

external_acl_type ldap_group %LOGIN /usr/lib64/squid/ext_ldap_group_acl -R -b "dc=papa,dc=local" -D "cn=squid,ou=special,dc=papa,dc=local" -K -W /etc/squid/password.txt -f "(&(objectclass=person) (sAMAccountname=%u)(memberof=cn=%g,cn=users,dc=papa,dc=local))" -h cntr-dc4.papa.local

acl InternetAccess external ldap_group InternetAccess

http_access allow InternetAccess all

Для LDAP-запросов к AD здесь мы используем учетную запись PAPA\squid с паролем (можно использовать и другую - право на чтение LDAP в домене по умолчанию имеет любая запись рядового пользователя в группе Domain Users). В данном примере пароль указан в дополнительном файле /etc/squid/password.txt открытым текстом, без символа перевода строки. Файл можно создать в любом текстовом редакторе (вроде vi /etc/squid/password.txt). Из соображений безопасности, доступ к нему следует ограничить для учетной записи службы:

chown squid:squid /etc/squid/password.txt

chmod 400 /etc/squid/password.txt

Альтернативно, можно указать пароль с ключом -W в хелпере прямо в файле /etc/squid/squid.conf, но это небезопасно – пароль здесь необходимо указывать открытым текстом.

После внесения изменения в конфигурацию, Squid необходимо перезапустить:

service squid restart

Одно замечание – пароль в запросах LDAP для учетной записи PAPA\squid до контроллера домена здесь передается по сети открытым текстом. А это может быть риском.

7.    Настройка доступа для группы Active Directory с авторизацией NTLM и Kerberos

Выше были описаны базовые настройки авторизации по Kerberos и NTLM. Чтобы ограничить доступ в Интернет для членов определенной группы (здесь это PAPA\InternetAccess, как в примере для LDAP), необходимо прописать следующие строки в /etc/squid/squid.conf:

external_acl_type InternetAccess_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g InternetAccess@PAPA.LOCAL

external_acl_type InternetAccess_from_ad_ntlm %LOGIN /usr/lib64/squid/ext_wbinfo_group_acl -d

acl InternetAccess_acl_krb external InternetAccess_from_ad_krb

acl InternetAccess_acl_ntlm external InternetAccess_from_ad_ntlm InternetAccess

8.    Базовая аутентификация

Squid поддерживает также базовую аутентификацию с передачей пароля открытым текстом. По понятным причинам, этого лучше не делать, и в этой статье данный метод не рассматривается. Рабочий проверенный пример конфигурации для Squid можно взять здесь (применительно к ПО Kaspersky Web Traffic Security): “Приложение 2. Настройка интеграции сервиса Squid с Active Directory\Настройка Basic-аутентификации”, https://support.kaspersky.com/KWTS/6.1/ru-RU/166445.htm.

9.    Файлы конфигурации для примера из статьи

В приложении (config.7z) собраны рабочие примеры файлов конфигурации для тестовой среды, описанной в статье. Можно использовать AS IS и править:

chrony.conf (/etc/chrony.conf) – файл конфигурации NTP;

resolv.conf (/etc/resolv.conf) – файл конфигурации распознавателя DNS;

krb5.conf (/etc/krb5.conf) – файл конфигурации Kerberos;

smb.conf (/etc/samba/smb.conf) – файл конфигурации Samba;

squid.conf (/etc/squid/squid.conf) - файл конфигурации Squid. Этот пример содержит минимальные настройки для работоспособной авторизации Kerberos и NTLM для неограниченного доступа через Squid для группы безопасности AD PAPA\InternetAccess;

squid_ldap.conf (/etc/squid/squid.conf) – вариант аналогичной конфигурации Squid для работоспособной авторизации LDAP;

kt_pass.cmd – пример команды, выполняемой на контроллере домена AD для генерации файла ключей keytab для CentOS прокси.

Ссылка на конфигурацию:

Config.7z

Альтернативная ссылка на конфигурацию: https://disk.yandex.ru/d/70jIXe7V3yprGQ

Повышение защищенности стандартного рабочего места под Windows

1.    Введение
Недавно консультировал одного крупного и весьма технологичного клиента по вопросу блокировки посторонних приложений на рабочих местах. В результате получился некий шаблон, которым, кажется, стоит поделиться. Изначально речь шла об ограничении списка запускаемых приложений на рабочих столах VDI Citrix XenDesktop, однако, методика может быть с успехом применена в любом доменном окружении, и не только для виртуальных машин.

Операционная система виртуальных рабочих мест была стандартизована - Windows 7 x64, но все сказанное справедливо и для более новых версий Windows. Условие проекта - требовалось по максимуму задействовать штатные средства ОС.

Все системы были в одном домене AD, поэтому имелась возможность применить групповые политики. Я решил для блокировки использовать механизмы SRP (Software Restriction Policies), а не более новые Applocker. Пример практического сравнения технологий – “AppLocker vs Software Restriction Policies”, https://www.sysadmins.lv/blog-ru/applocker-vs-software-restriction-policies.aspx. Требуемый функционал можно реализовать и так, и так, в основу моего выбора легли примерно те же соображения.

2.    “Белый список” приложений

Исходный список приложений, выданный клиентом, был такой:

 

Приложение

 

Путь   и каталог запуска

 

Пульт для работы с   чатом WorskpaceDesktopEdition

 
 

C:\Program Files\GCTI\Workspace Desktop Edition\InteractionWorkspace.exe

 
 

Статистика CCPulse

 
 

C:\GCTI\CCPulse+\CallCenter.exe

 
 

Управление системными   сообщениями в чате KnowledgeManager

 
 

C:\Program Files\GCTI\eServices 8.1.3\Knowledge   Manager\KnowledgeManager.BAT

 

(Использует каталог C:\Program Files\Java\jre6)

 
 

WFM – Управление   расписаниями

 
 

C:\Program Files\NICE_IEX_WFM\totalview\ttv40.exe

 
 

HPSM

 
 

C:\Program Files\HP\Service Manager 7.11\Client\ServiceManager.exe

 
 

Citrix Access Gateway

 
 

C:\Program Files\Citrix\Secure Access Client\nsload.exe

 
 

Skype

 
 

C:\Program Files\Skype\Phone\Skype.exe

 
 

Lync 2010

 
 

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Lync

 
 

Microsoft Office

 
 

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Office

 
 

Internet Explorer

 
 

C:\Program Files\Internet Explorer\iexplore.exe

 
 

Google Chrome

 
 

C:\Program Files\Google\Chrome\Application\chrome.exe

 
 

Mozilla Firefox

 
 

C:\Program Files\Mozilla Firefox\firefox.exe

Если любопытно - это было стандартное рабочее место оператора клиентского call-центра.

3.    Реализация
Политика SRP реализуется с помощью объекта GPO в домене AD в контейнере Computer Configuration и может быть
назначена на целевые OU, содержащие объекты компьютеров рабочих столов VDI, при необходимости, с фильтрацией
по ACL права Apply Group Policy для необходимых учетных записей или групп.

Согласно архитектуре ОС, установка чрезмерно жестких блокировок на системные каталоги (в частности, %Systemroot% и %ProgramFiles%, нарушает функциональность системы в целом. Поэтому, при создании новой политики блокировки SRP с режимом Disallowed по умолчанию, для ОС Windows Server 2008/2008 R2/Vista/7 и выше, ОС сразу же автоматически создает два исключения реестровых путей:

·         %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%;

·         %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%.

Таким образом, по списку разрешенного ПО (таблица выше), двумя первыми правилами ОС по умолчанию фактически покрываются все рабочие приложения, кроме приложения “Cтатистика CCPulse”. Для него создается явное Unrestricted-правило пути “C:\GCTI\CCPulse*” (символ ‘+’ SRP не воспринимает).

Поскольку эти пути вносятся в “белый” список, что автоматически разрешает запуск почти любого ПО из системных каталогов, для предотвращения запуска из них нелегитимного кода, критично отсутствие у оператора административных прав на ОС (а также на подкаталоги “C:\GCTI\CCPulse*”).

Кроме того, в любой установке ОС Windows 7 с настройками прав файловой системы NTFS по умолчанию, в подкаталогах %Systemroot%, есть ряд директорий, в которые рядовой пользователь (член локальной группы Users) имеет права на запись (например, %Systemroot%\Temp). Для таких каталогов необходимо написать явные SRP-правила пути с режимом Disallowed. При наличии правила Unrestricted для вышележащего каталога (пример - %Systemroot%), и правила Disallowed для подкаталога (пример - %Systemroot%\Temp), запрещающее правило в своей области действия имеет приоритет.

Дополнительное разрешающее реестровое правило пути “%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%”, рекомендуемое Microsoft, не используется, ввиду отсутствия данного каталога в защищаемом образе ОС (система 64-разрядная).

Разрешающее правило пути “\\%USERDNSDOMAIN%\Sysvol\” предназначено для доменных скриптов входа, рекомендовано Microsoft для машин в домене AD, и может требоваться для задач централизованного управления.

Разрешающее (Unrestricted) правило для “*.lnk” является рекомендуемым решением Microsoft для запуска ярлыков из оболочки ОС (shell) Explorer.exe, см. статью “Allowing Shortcuts When Using Software Restriction Policies”, http://www.windowsnetworking.com/kbase/WindowsTips/WindowsServer2008/AdminTips/ActiveDirectory/AllowingShortcutsWhenUsingSoftware­RestrictionPolicies.html. Однако, оно не содержит явной угрозы, так как, если ярлык ссылается на программный код по пути Disallowed, результат запуска успешным не будет. Переименование любого исполняемого модуля в LNK-файл в доверенном, либо недоверенном, пути, с его последующим запуском, также не приводит к успеху (хотя, подобная уязвимость действительно существовала в ранних версиях ОС Windows - в частности, 2000/XP/2003).

SRP-блокировка включена в контейнере Computer Configuration, а не User Configuration для максимальной защиты, независимо от того, кто работает в системе. Кроме того, она включена для всех пользователей, включая локальных администраторов, с помощью параметров Enforcement, и для всех программных модулей и DLL-библиотек. Нужно отметить, что параметр “Apply software restriction policies to the following users – All Users“ задает принудительную блокировку для всех контекстов безопасности (включая Local System). Эта максимальная защита теоретически позволяет заблокировать нелегитимный код, даже если он исполняется с правами операционной системы, однако может создать определенные неудобства в обслуживании образа виртуальной машины VDI, если он подпадает под действие политики. Кроме того, в этом варианте, неправильное Disallowed-правило пути вполне может привести ОС в нерабочее состояние. Поэтому следует соблюдать крайнюю осторожность при модификации политики в производственной среде.

Итоговые параметры политики SRP получились такие:

Политика SRP.

Расположение политики: Computer Configuration\Policies\Windows   Settings\Security Settings\Software Restriction Policy

Параметр

Значение

Enforcement\Apply software restriction policies to   the following

All software files

Enforcement\Apply software restriction policies to   the following users

All users

Enforcement\When applying software restriction   policies

Ignore certificate rules

Designated File Types

По умолчанию (не кастомизировалось)

Trusted Publishers

Не определено

Software Restriction Policy\Security Levels

Disallowed - Default Security Level (Software will not run, regardless of access   rights of the user)

Software Restriction Policy\Additional Rules

По списку (см.таблицу ниже)


Правила SRP.
 

Правило

 
 
Режим
 

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot% (реестр, путь)

 
 
Unrestricted
 
 

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir% (реестр, путь)

 
 
Unrestricted
 
 

*.lnk (путь)

 
 
Unrestricted
 
 

\\%USERDNSDOMAIN%\Sysvol\ (путь)

 
 
Unrestricted
 
 

C:\GCTI\CCPulse* (путь)

 
 
Unrestricted
 
 

C:\WINDOWS\Debug (путь)

 
 
Disallowed
 
 

C:\WINDOWS\PCHEALTH\ERRORREP (путь)

 
 
Disallowed
 
 

C:\WINDOWS\Registration (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\catroot2 (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\com\dmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\FxsTmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\spool\drivers\color (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\spool\PRINTERS (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\spool\SERVERS (путь)

 
 
Disallowed
 
 

C:\WINDOWS\System32\Tasks (путь)

 
 
Disallowed
 
 

C:\WINDOWS\SysWOW64\com\dmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\SysWOW64\FxsTmp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\SysWOW64\Tasks (путь)

 
 
Disallowed
 
 

C:\WINDOWS\Tasks (путь)

 
 
Disallowed
 
 

C:\WINDOWS\Temp (путь)

 
 
Disallowed
 
 

C:\WINDOWS\tracing (путь)

 
 
Disallowed
Сформированная политика SRP обеспечивает полную блокировку запуска исполняемого ПО за пределами каталогов “C:\WINDOWS“, “C:\Program Files“, “C:\CGTI\CCPulse*“, и блокировку потенциально нелегитимного ПО в каталоге ОС. В том числе, обеспечивается запрет запуска любых исполняемых модулей из пределов пользовательского профиля. Отсутствие локальных административных прав у оператора и корректное выставление ACL на объекты файловой системы NTFS является обязательным условием эффективности метода.

Для сведения, см. cводный документ “National Security Agency. Application Whitelisting using Software Restriction Policies”, https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf.

Существует также сводная печатная работа по теме блокировки и использования минимальных привилегий при работе с клиентскими ОС Windows: ISBN-13 978-1849680042, PACKT Publishing, “Russel Smith. Least Privilege Security for Windows 7, Vista and XP”, http://www.amazon.com/Least-Privilege-Security-Windows-Vista/dp/1849680043. Данная работа рекомендуется к изучению при реализации любых проектов по повышению безопасности использования рабочих мест Windows в корпоративных сетях.

4.    Общие замечания

Методика позволяет неплохо защититься при условии, что приложения не запускаются из пределов пользовательского профиля и других областей с доступом обычного пользователя на запись. На самом деле, запрет запуска кода из профиля – почти обязательное условие для эффективной защиты рабочего места Windows, в том числе, и от ransomware. Однако, это накладывает ряд ограничений на приложения, в том числе, на новые, написанные специально для Windows 8/8.1/10.

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

   

Также понятно, что никакие политики блокировки не отменяют требования иметь нормальный антивирус на всех рабочих местах. А наличие в нем самом поведенческого анализатора/блокировщика процессов позволяет выстроить дополнительный уровень защиты – обычно в антивирусах бывают расширенные возможности, которых нет в групповых политиках. Только при составлении антивирусных политик нужно проследить, чтобы эти два уровня между собой не “дрались” из-за функциональных пересечений.

5.    Вариант с локальной политикой для недоменного компьютера

Блокировку SRP можно применять и на отдельно стоящей рабочей станции - в этом случае редактируется стандартный объект Local Group Policy через оснастку Gpedit.msc. Приведенные скрины с моей собственной домашней системы в  рабочей группе, ОС – Windows 10 x64. Немного отступил от собственного правила запрета запуска кода из профиля, но я-то знаю, что делаю:




6.    Пример дополнительной функциональности поведенческого анализатора антивируса

У моего клиента был централизованно управляемый Symantec Endpoint Protection, поэтому, в дополнение к компоненту SRP операционной системы, со стороны антивируса была задействована политика поведенческого анализатора Application and Device Control (управление приложениями и устройствами) SEP. Таких политик в SEP Manager может быть любое количество, для разных групп клиентов, и разных локаций. В приведенном примере, ветвь политики “Управление устройствами” на текущий момент не задействована за ненадобностью, а правила ветви “Управление приложениями” приведены ниже:

Политика SEP “Управление приложениями и устройствами“ (управление приложениями).

 

Правило

 

Назначение

 
 

Режим

 

Make all removable drives read-only

 
 

Блокировка записи на сменные носители

 
 

Включено/Рабочий режим

 
 

Block programs from running from removable devices

 
 

Блокировка запуска исполняемых модулей со сменных   носителей

 
 

Включено/Рабочий режим

 
 

ШАБЛОН. Разрешить   запуск доверенных приложений (ОСНОВНЫЕ АРМ)

 
 

Разрешить запуск доверенных приложений по рабочему списку   КЦ. Пустое правило (шаблон)

 
 

Отключено/Тест

 
 

ШАБЛОН. Block applications from running (блокировка через SEP)

 
 

Блокировка нелегитимных приложений через SEP. Пустое правило   (шаблон)

 
 

Отключено/Тест

 
 

Protect client files and registry keys

 
 

Защита критических компонент антивирусного модуля

 
 

Включено/Рабочий режим

 
 

Block writing to USB drives

 
 

Блокировка записи на USB

 
 

Отключено/ Рабочий режим

 
 

Log files written to USB drives

 
 

Протоколирование записи на USB

 
 

Отключено/ Рабочий режим

 
 

Block modifications to hosts file

 
 

Блокировка записи в файл конфигурации распознавателя DNS

 
 

Включено/Рабочий режим

 
 

Block autorun.inf

 
 

Блокировка автозапуска

 
 

Включено/Рабочий режим

 
 

Block access to Autorun.inf - old edition

 
 

Блокировка доступа к файлу автозапуска старой редакции   для процессов антивируса

 
 

Включено/Рабочий режим

 
 

Prevent changes to Windows shell load points

 
 

Блокировка изменений конфигурации оболочки ОС

 
 

Включено/Рабочий режим

 
 

Prevent changes to system using Internet Explorer

 
 

Защита системы от изменений через браузер Internet Explorer

 
 

Включено/Тест

 
 

Prevent modification of system files

 
 

Блокировка модификации системных файлов

 
 

Включено/Тест

 
 

Prevent registration of new Browser Helper Objects

 
 

Блокировка установки объектов BHO

 
 

Включено/Тест

 
 

Prevent registration of new Toolbars

 
 

Блокировка установки дополнительных панелей инструментов   браузера IE

 
 

Включено/Тест

 
 

Lockdown Internet   Explorer

 
 

Поведенческая блокировка браузера IE

 
 

Включено/Тест

 
 

Stop software   installers

 
 

Блокировка установщиков ПО

 
 

Включено/Тест

 
 

Block access to Autorun.inf

 
 

Защита файлов автозапуска (Autorun.inf)

 
 

Включено/Рабочий режим

 
 

Block applications from running from TEMP

 
 

Блокировка запуска исполняемых модулей из временных   каталогов

 
 

Включено/Рабочий режим

В данном примере включена и работает только часть правил. При этом, “Рабочий режим” означает реальную блокировку, а “Тест” – только запись в журналы SEPM на предмет исследования поведения системы на первоначальном этапе внедрения защиты. При необходимости, тестовые правила можно переключить в рабочий режим.

Два правила, отмеченные префиксом “ШАБЛОН” - пустые. Это шаблоны разрешения и блокировки приложений средствами SEP (сейчас аналогичный функционал обеспечен через групповые политики SRP). Шаблоны специально оставлены для возможности быстрой альтернативной реализации в случае необходимости. Однако, использование параллельно обоих методов для блокировки запуска ПО не рекомендуется.

7.    Дополнительные сведения

На сайте поддержки и сообщества Symantec существует много открытых ресурсов, посвященных повышению защищенности ОС Windows штатными и сторонними средствами. В качестве примера приведу ряд статей, посвященных защите от загружаемых вирусов-шифровальщиков:

·         Recovering Ransomlocked Files Using Built-In Windows Tools: http://www.symantec.com/connect/articles/recovering-ransomlocked-files-using-built-windows-tools;

·         Cryptolocker Q&A: Menace of the Year: http://www.symantec.com/connect/blogs/cryptolocker-qa-menace-year;

·         First Response to: Cryptolocker\Ransomcrypt\Encryptor: http://www.symantec.com/connect/articles/first-response-cryptolocker-ransomcrypt-encryptor.

Программное управление уровнями целостности (Integrity Levels) объектов файловой системы

Короткий пост.

Для одной факультативной задачи, потребовалось сделать средство программного управления уровнями целостности (Integrity Level) файловых объектов в операционной системе.

Уровни целостности - технология довольно экзотическая и малоизученная, появились в Windows Vista/2008, используются в них и во всех более поздних версиях клиентских и серверных ОС как один из встроенных механизмов защиты. Пример описания на MSDN – “Windows Integrity Mechanism Design”, https://msdn.microsoft.com/en-us/library/bb625963.aspx.

В итоге не придумал ничего лучше, чем тряхнуть стариной, и написать мини-утилиту командной строки на старом добром Си. Выкладываю как есть, исходный текст совсем не велик, и интуитивно понятен. Библиотеки классов не используются вовсе, стандартные функции тоже по минимуму, хватает Windows API. MIL – это “Manage integrity levels”.

Компилируется в любой современной версии Visual Studio (я использовал Visual Studio Community 2017) как консольное приложение.

MIL.7z ( 2.01 КБ)

Детальный контроль прав доступа к функции Remote Control на клиенте SCCM

Я всегда много рассказывал на семинарах про "тонкую доработку SCCM по потребностям", и призывал к этому слушателей. Приведу хороший пример.

1. Общая постановка задачи
Пару месяцев назад клиент, эксплуатирующий инсталляцию SCCM 2012 R2, обратился с весьма специфическим вопросом.
 
Для нужд удаленной поддержки рабочих мест клиентская служба ТП активно использовала механизм Remote Control (RC) в составе клиента Configuration Manager. Однако, поддержкой разного ПО занимались совершенно разные группы Help Desk; при этом, на рабочем месте могло быть установлено более одного целевого приложения. Стандартный механизм создания коллекций компьютеров с применением соответствующих политик клиента SCCM как ACL для Remote Control не годился, так как настройки прав доступа в политике не кумулятивные; политика, применяемая с наибольшим приоритетом, или последней, “затирает” все остальные. Таким образом, эффективной в каждом конкретном случае становится только одна политика (в нашем случае, для одного из приложений).
 
В сообществе пользователей SCCM этот вопрос к Microsoft (сделать настройки прав доступа к RC объединяемыми для набора нескольких политик) уже поднимался, см. https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/13748199-ability-to-set-multiple-remote-control-privileges. В SCCM Client Settings часть параметров действительно может объединяться из разных политик (некоторые разделы Inventory, например), но к правам доступа RC это, увы, не относится. После детального анализа задачи стало ясно, что штатными средствами ее не решить.
 
Клиент был весьма озабочен вопросами безопасности, и ситуация, когда кто-то получал удаленный доступ к чужому рабочему столу за пределами своей зоны ответственности, была неприемлема. Правильно разграничить доступ подразделений поддержки только к “своему” приложению не получалось, из-за возможности иметь более одного приложения на контролируемой системе. Дело осложнялось еще и тем, что число пользователей одного приложения могло быть большим (до 500 человек и больше); при этом, очень хотелось автоматизировать логику добавления системы с приложением в соответствующую коллекцию компьютеров (с последующим автоматическим назначением на нее ACL для Remote Control). Ручное добавление каждого объекта-компьютера в нужную коллекцию никого не устраивало; приложения тоже были самые разные, от “толстого” клиента 1C до веб-сервиса, не оставляющего никаких следов в системе нигде, кроме кэша браузера в профиле пользователя. Поэтому от идеи инвентаризации каких-либо объектов, уникально идентифицирующих приложение (вроде файла по фиксированному пути или ключа реестра), пришлось отказаться сразу.
Однако, имелись глобальные группы домена AD, каждая из которых содержала всех пользователей, использующих каждое приложение - это и были группы доступа. Сразу же возникла мысль попробовать использовать эти группы и механизм SCCM UDA (User Device Affinity) для построения коллекций компьютеров, к компоненту Remote Control на которых бы предоставлялся доступ соответствующих групп Help Desk.

2.   Условия

Для примера рассмотрим следующий сценарий, близкий к реальным условиям клиента. Имеется четыре приложения – 1C, Directum, CRM, Invest, для поддержки которых необходимо организовать доступ разных групп службы ТП.

Глобальные группы доступа пользователей к приложениям: DOMAIN\Access_1C, DOMAIN\Access_Directum, DOMAIN\CRM_Access, DOMAIN\Access_Invest;  

Соответствующие (создаваемые в рамках решения) коллекции компьютеров в SCCM: 1C, Directum_5_3, PC_Remote_control_CRM, PC_Remote_control_Invest;
Соответствующие глобальные группы учетных записей пользователей ТП, которым предоставляется доступ к Remote Control для
компьютеров в целевых коллекциях: DOMAIN\SCCM-RC_Access_1C, DOMAIN\SCCM-RC_Access_Directum, DOMAIN\SCCM-RC_Access_CRM, DOMAIN\SCCM-RC_Access_Invest.
Решение строим для этих условий.

3.    Формирование коллекций компьютеров
Механизм сопоставления User Device Affinity требует требует включения в политиках домена параметров аудита Audit account logon events и Audit logon events, как описано в статье “How Automatic User Device Affinity Works in SCCM 2012”, https://blogs.technet.microsoft.com/sudheesn/2015/03/05/how-automatic-user-device-affinity-works-in-sccm-2012. Сбор данных из журналов безопасности осуществляется SCCM автоматически. Порог срабатывания (время работы пользователя в системе, по прошествии которого он становится “Primary User”), контролируется через политику клиента SCCM, раздел “Сопоставление пользователей и устройств”, например, так:


Приступаем к созданию коллекций. Пример для коллекции для компьютеров с CRM:

Коллекция формируется на основе запроса WQL:

Сам запрос WQL:

Идея запроса взята отсюда: “ConfigMgr User Device Affinity (UDA) Collection Query”, https://deploymentramblings.wordpress.com/2017/05/22/configmgr-user-device-affinity-uda-collection-query/. При выполнении этого запроса формируется коллекция компьютеров, основные пользователи (Primary Users в терминологии SCCM) входят в доменную группу DOMAIN\CRM_Access.

Итак, по результатам настройки UDA у нас есть четыре коллекции, которые динамически и в реальном времени формируют списки компьютеров, за которыми работают пользователи соответствующих приложений. Первая часть автоматизированного решения получена.
4. Контроль доступа к Remote Control

Доступ к функции SCCM Remote Control на управляемой системе, в общем случае, контролируется членством в локальной группе "Пользователи удаленного управления Configuration Manager" (в русской версии SCCM). В нее попадают объекты безопасности, прописанные в политике клиента SCCM в разделе “Средства удаленного управления”, параметр “Пользователи средств удаленного управления и удаленного помощника”. При установке значения этого параметра, перечисленные в нем пользователи и группы попадают в локальную группу "Пользователи удаленного управления Configuration Manager" на компьютере, к которому применяется политика. Но, как уже говорилось, эффективная политика – только одна, поэтому нам стандартный механизм помочь не может.

Однако, опытным путем установлено, что если параметр “Пользователи средств удаленного управления и удаленного помощника” в политике клиента SCCM оставить пустым, вот так:

, то клиент SCCM на управляемой системе перестает контролировать требуемую локальную группу вовсе. Это приводит нас к идее реализовать контроль над группой по-другому - например, универсальным централизованным скриптом, запускаемым на клиентской стороне, скажем, периодически по планировщику.

Именно такое решение и было применено – скрипт на WSH с помощью подсистемы WMI подключается к локальным экземплярам классов клиента SCCM, и динамически проверяет принадлежность системы к каждой из анализируемых коллекций, при необходимости добавляя в локальную группу "Пользователи удаленного управления Configuration Manager" операционной системы десктопа требуемую глобальную группу доступа для Help Desk.

“Подводный камень” заключается в том, что простого способа проверить список коллекций, к которым принадлежит компьютер, с помощью локальной подсистемы WMI - нет (по крайней мере, я пока не придумал). Такая проверка возможна только, если подсоединиться по сети к подсистеме WMI самого сервера SCCM. Но очень хочется исполнять скрипт с правами локальной системы, а не сетевой учетной записи - ведь если подсоединяться к SCCM с локальной системы с помощью сетевой УЗ с паролем, это почти наверняка так или иначе приведет к ослаблению системы безопасности. Учетная же запись системы по сети подсоединиться к SCCM для проверки списка коллекций не может - для такого запроса у нее не хватает прав на уровне DCOM, а ослаблять защиту DCOM без крайней необходимости не стоит, по той же причине.

Эта задача решается с помощью переменных коллекции. Пример того, как это реализовано, для уже упомянутой коллекции PC_Remote_control_CRM:


То есть, для каждой проверяемой коллекции (и только для нее одной в рамках инсталляции SCCM), мы дополнительно определяем специальную переменную с префиксом Collection_RC_, с именем и значением, соответствующим имени самой коллекции. Переменные коллекции, в отличие от самого списка коллекций, “спускаются” в локальный WMI клиента при каждом обновлении политики; наличие их в репозитарии WMI мы проверяем программным способом.

Скрипт ManageSCCMRCAccess.vbs приведен в приложении к статье, предоставляется AS IS. Работоспособность проверена на всех версиях Windows, содержащих подсистему WMI, то есть, он гарантированно работает на Windows XP и выше - иначе говоря, на всех системах Windows, для которых существует клиент SCCM. Логика скрипта отражает условия нашей задачи (имена коллекций и групп), но он может быть адаптирован по потребностям для любого количества комбинаций “коллекция-группа доступа”. Для запроса данных SCCM используются классы и методы WMI, для управления локальной группой – интерфейс ADSI. Перед каждой проверкой коллекций производится предварительная чистка группы "Пользователи удаленного управления Configuration Manager". Это сделано для отработки ситуации, когда приложение более не используется (компьютер пропадает из коллекции), это приводит к отзыву права подключения у соответствующей группы ТП. Установка константы DEBUGLOG=True задает протоколирование работы скрипта в простой текстовый лог C:\SCCM_RC_Config.log – включить отладку полезно на случай, если что-то пошло не так.

5. Запуск скрипта

Скрипт размещается в сетевой папке с правами только для чтения для группы Domain Computers, запускается планировщиком Task Scheduler операционной системы раз в час, обнаруженные изменения вступают в силу немедленно. Этого оказалось достаточно, чтобы построить систему управления правами доступа к Remote Control, практически не требующую вмешательства администратора. Единственное, что нужно – добавлять пользователей в глобальные группы доступа к приложениям DOMAIN\Access*, но это как раз та операция, которая контролируется персоналом ИТ.

Никто, кстати, не мешает использовать любые другие способы периодического запуска скрипта, например, с помощью самого SCCM.

Скриншоты задания планировщика приведены ниже, они тривиальны. Задача назначается на целевые рабочие станции с помощью доменного GPO, раздел “Preferences”:






Отдельное замечание касается использования объектов планировщика в Group Policy Preferences. В механизме GPP уже давно обнаружена уязвимость, делающая хранение паролей в них небезопасным – см. бюллетень Microsoft Technet MS14-025 https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2014/ms14-025. В поддерживаемых версиях ОС Windows возможность хранения пользовательских паролей в GPP принудительно отключена модулями коррекции, распространяемыми через Windows Update или WSUS, и это правильно. Однако, поскольку мы запускаем задачу от системы, к нам проблема отношения не имеет.
6. Замечания

  • Все ссылки на реальную инфраструктуру клиента в скрипте и скриншотах изменены;
  • Решение тестировалось в среде SCCM 2012 R2, но оно полностью применимо и к SCCM 2016 – основные подсистемы в новой версии почти не поменялись;
  • Для анализа объектов WMI в системе Windows, из известных мне средств, удобнее всего использовать утилиту WMI Explorer от CodePlex, см. https://archive.codeplex.com/?p=wmie.
ManageSCCMRCAccess.7z ( 2.06 КБ)

Гостевой роутер для виртуальных стендов

По работе мне постоянно приходится иметь дело с виртуальными стендами. Бывает и так, что приходится моделировать среды из нескольких IP-подсетей, между которыми необходимо обеспечить маршрутизацию пакетов. В статье описывается часть моих решений применительно к хост-системе Windows, однако, с незначительными изменениями, они могут применяться и в других средах (VMware vSphere/ESXi, например).

1. Хост-система.
Традиционно я использую в качестве хост-системы Windows Server, на которой поднимается либо Hyper-V, либо VMware Workstation/Player, с необходимым числом виртуальных сетей. Долгое время я пытался организовывать маршрутизацию между гостевыми сетями через хост c с поднятой на нем службой RRAS, однако в конце концов от этой идеи пришлось отказаться. Взаимодействие гипервизора даже с RRAS на одной системе порождает трудноуловимые сетевые проблемы; если же пытаться использовать  решения типа TMG либо Kerio (имеющие, в числе прочего, функционал программной маршрутизации), добавляются еще и трудности сосуществования гипервизора и достаточно глубокого брандмауэра. И, в любом случае, такая маршрутизация нормально не заработает без NAT (т.е. объявления одного из интерфейсов хост-системы “внешним”), что на хосте не всегда приемлемо. Проблем может добавить еще и нагромождающийся на все это хостовой антивирусный модуль, неважно даже, какой именно - такие антивирусы обычно имеют собственный сетевой компонент.
Решение, к которому я пришел за долгие годы экспериментов – организовывать роутер в гостевой VM. Гостевая VM создается с необходимым количеством сетевых интерфейсов (multihomed), и в ней уже поднимается маршрутизатор. Мы рассмотрим как вариант с гостевой ОС Windows Server 2016 с RRAS, так и с гостевым маршрутизатором на CentOS (любой UNIX можно так приспособить; у меня CentOS только потому, что он гарантированно работает в Hyper-V).
Отдельное замечание касается файрволльного модуля в антивирусе хост-системы. Трафик даже между гостевыми виртуальными сетями, так или иначе, через него проходит. Поэтому, может понадобиться некая настройка брандмауэра антивируса для корректной обработки трафика, не подпадающего под правила - “Unmatched IP Traffic” (правила относятся к хост-системе). В Symantec Endpoint Protection клиенте, например, эта настройка выглядит так:

Fig 1. SEP FW Settings.jpg
Переходим к конфигурациям VM.
2. Виртуальный маршрутизатор на Windows Server 2016 RRAS, гипервизор VMware Workstation 12.
Имеем хост-систему Windows Server с установленной VMware Workstation 12 и неким набором виртуальных машин в разных подсетях. Конфигурация виртуальных сетей VMware, к примеру, такая:

Fig 2. VMware virtual networks.jpg

Для стендовых виртуальных машин мы используем сети VMNet1 (192.168.121.0/24), VMNet2 (192.168.122.0/24), VMNet3 (192.168.44.0/24). VMNet0 – это мост в физическую сеть (используются адреса в подсети 192.168.250.0/24). Роутер VM будет осуществлять маршрутизацию между ними всеми, поэтому у созданной VM программного RRAS-маршрутизатора (ROUTER1) четыре интерфейса:

Fig 3. Router VM network settings.jpg

В VM ROUTER1 устанавливаем операционную систему Windows Server 2016. На ней поднимаем роль Remote Access, служба Web Application Proxy, как и компонент DirectAccess, нам не понадобятся:
Fig 4. OS Roles.jpg

После установки конфигурируем службу RRAS и запускаем ее. В задачу узла входит только маршрутизация пакетов, поэтому RRAS у нас работает в режиме LAN Routing Only:

Fig 5. RRAS Settings.jpg

Ни маршрутизация по требованию, ни удаленный доступ VPN нам не нужны. Сетевые интерфейсы в оснастке RRAS выглядят так:

Fig 6. Interfaces.jpg

(видно, что Ethernet0 – это мост в физическую сеть, то есть, если можно так выразиться, “uplink”).

Конфигурация интерфейсов по Ipconfig / all:
Windows IP Configuration
Ethernet adapter Ethernet0:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::f9c2:c00d:b442:efc0%18
  IPv4 Address. . . . . . . . . . . : 192.168.250.10
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . : 192.168.250.1
Ethernet adapter Ethernet1:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::f875:715a:74c2:8463%10
  IPv4 Address. . . . . . . . . . . : 192.168.44.2
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :
Ethernet adapter Ethernet2:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::bdd5:7d16:7b99:b456%14
  IPv4 Address. . . . . . . . . . . : 192.168.122.2
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :
Ethernet adapter Ethernet3:
  Connection-specific DNS Suffix  . :
  Link-local IPv6 Address . . . . . : fe80::58b8:5340:3b0b:9593%2
  IPv4 Address. . . . . . . . . . . : 192.168.121.2
  Subnet Mask . . . . . . . . . . . : 255.255.255.0
  Default Gateway . . . . . . . . . :

Только Ethernet0 имеет шлюз по умолчанию. Казалось бы, все должно работать, однако, у Windows Server RRAS есть одна особенность – не удается заставить работать маршрутизацию без NAT (в Linux это возможно). Нам нужен интерфейс, объявленный внешним с точки зрения трансляции адресов. Идеальный кандидат на эту роль – Ethernet0. Поэтому, его мы объявляем как Public, а остальные – как Private:

Fig 7. NAT Settings.jpg

Таблица маршрутизации, выдаваемая через команду route print, получается такая (строки протокола IPv6 для краткости не приводим):
===========================================================================
Interface List
18...00 0c 29 01 88 59 ......Intel® 82574L Gigabit Network Connection
10...00 0c 29 01 88 63 ......Intel® 82574L Gigabit Network Connection #2
14...00 0c 29 01 88 6d ......Intel® 82574L Gigabit Network Connection #3
 2...00 0c 29 01 88 77 ......Intel® 82574L Gigabit Network Connection #4
 1...........................Software Loopback Interface 1
16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
15...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 5...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
17...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #4
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination  Netmask    Gateway Interface  Metric
   0.0.0.0    0.0.0.0    192.168.250.1   192.168.250.10    257
 127.0.0.0  255.0.0.0   On-link   127.0.0.1    331
 127.0.0.1  255.255.255.255   On-link   127.0.0.1    331
 127.255.255.255  255.255.255.255   On-link   127.0.0.1    331
    192.168.44.0    255.255.255.0   On-link 192.168.44.2    281
    192.168.44.2  255.255.255.255   On-link 192.168.44.2    281
  192.168.44.255  255.255.255.255   On-link 192.168.44.2    281
   192.168.121.0    255.255.255.0   On-link     192.168.121.2    281
   192.168.121.2  255.255.255.255   On-link     192.168.121.2    281
 192.168.121.255  255.255.255.255   On-link     192.168.121.2    281
   192.168.122.0    255.255.255.0   On-link     192.168.122.2    281
   192.168.122.2  255.255.255.255   On-link     192.168.122.2    281
 192.168.122.255  255.255.255.255   On-link     192.168.122.2    281
   192.168.250.0    255.255.255.0   On-link    192.168.250.10    257
  192.168.250.10  255.255.255.255   On-link    192.168.250.10    257
 192.168.250.255  255.255.255.255   On-link    192.168.250.10    257
 224.0.0.0  240.0.0.0   On-link   127.0.0.1    331
 224.0.0.0  240.0.0.0   On-link     192.168.122.2    281
 224.0.0.0  240.0.0.0   On-link    192.168.250.10    257
 224.0.0.0  240.0.0.0   On-link     192.168.121.2    281
 224.0.0.0  240.0.0.0   On-link 192.168.44.2    281
 255.255.255.255  255.255.255.255   On-link   127.0.0.1    331
 255.255.255.255  255.255.255.255   On-link     192.168.122.2    281
 255.255.255.255  255.255.255.255   On-link    192.168.250.10    257
 255.255.255.255  255.255.255.255   On-link     192.168.121.2    281
 255.255.255.255  255.255.255.255   On-link 192.168.44.2    281
===========================================================================
Persistent Routes:
 Network Address    Netmask  Gateway Address  Metric
         0.0.0.0    0.0.0.0    192.168.250.1  Default

Полученная конфигурация полностью рабочая, и позволяет VM ROUTER1 маршрутизировать пакеты между подсетями 192.168.121.0/24, 192.168.122.0/24, 192.168.44.0/24, 192.168.250.0/24, а также из первых трех подсетей в физическую сеть и, при необходимости, в Интернет. Естественно, для виртуальных машин в этих подсетях, именно интерфейсы VM ROUTER1 (то есть 192.168.121.2, 192.168.122.2 и 192.168.44.2) нужно указывать в качестве шлюзов по умолчанию.
К слову сказать, в Windows Server 2012/R2 настройки точно такие же. Компонент RRAS в Windows Server 2016 по сравнению с предыдущими версиями не изменился.

3. Виртуальный маршрутизатор на CentOS 6.4, гипервизор Windows Server 2016 Hyper- V.
Сценарий очень похожий. Хост-система Windows Server 2016 с установленной ролью Hyper-V и набором виртуальных машин в разных подсетях. В числе прочих, есть три виртуальных коммутатора типа InternalPapapach, Bugravsk и Puksyalovo, и коммутатор BRIDGED типа External (мост в физическую сеть - “uplink”):

Fig 1. HyperV virtual networks.jpg

Виртуальные сети типа Internal имеют такую адресацию: Papapach - 192.168.44.0/24, Bugravsk - 192.168.41.0/24, и Puksyalovo - 192.168.40.0/24. VM роутера UNIX (CNTR-1- ROUTER) будет осуществлять маршрутизацию между всеми ними, поэтому у нее четыре интерфейса:

Fig 2. Router VM network settings.jpg

Устанавливается ОС CentOS 6.4 с инсталл-профилем Minimal. Далее нам понадобятся следующие пошаговые руководства по конфигурированию сети, маршрутизации и NAT:
·  "Home Lab: CentOS 6.3 as a firewall and Router", http://www.itadmintools.com/2012/10/home-lab-centos-63-as-firewall-and.html;
·  "Moo Trader – IT Infrastructure", http://www.keymoo.info/trading/wp-content/uploads/2012/08/Steps-to-configure-a-CentOS-router.pdf;
·  "Linux Static IP Address Configuration", https://www.cyberciti.biz/faq/linux-configure-a-static-ip-address-tutorial.
Дополнительно про NAT:
·  "Quick-Tip: Linux NAT in Four Steps using iptables. By Frank Wiles", http://www.revsys.com/writings/quicktips/nat.html;
·  "Red Hat Enterprise Linux  4 : Security   Guide  . Chapter 7. Firewalls. 7.4. FORWARD and NAT Rules", https://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-fwd.html;

Конфигурация сети (вывод команды ifconfig) такая:
eth0 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:07  
   inet addr:192.168.250.10  Bcast:192.168.250.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:507/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:648 errors:0 dropped:0 overruns:0 frame:0
   TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:54842 (53.5 KiB)  TX bytes:2260 (2.2 KiB)

eth1 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:08  
   inet addr:192.168.44.2  Bcast:192.168.44.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:508/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:264 errors:0 dropped:0 overruns:0 frame:0
   TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:28478 (27.8 KiB)  TX bytes:15707 (15.3 KiB)

eth2 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:09  
   inet addr:192.168.40.2  Bcast:192.168.40.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:509/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:144 errors:0 dropped:0 overruns:0 frame:0
   TX packets:86 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:12794 (12.4 KiB)  TX bytes:3828 (3.7 KiB)

eth3 Link encap:Ethernet  HWaddr 00:15:5D:FA:05:0A  
   inet addr:192.168.41.2  Bcast:192.168.41.255  Mask:255.255.255.0
   inet6 addr: fe80::215:5dff:fefa:50a/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:225 errors:0 dropped:0 overruns:0 frame:0
   TX packets:65 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:1000
   RX bytes:25729 (25.1 KiB)  TX bytes:9569 (9.3 KiB)

lo  Link encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   inet6 addr: ::1/128 Scope:Host
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

“Рабочими” являются интерфейсы eth0-eth3. Eth0 смотрит в физическую сеть (то есть, подключен к виртуальному коммутатору BRIDGED типа External). Остальные интерфейсы подключены к коммутаторам типа Internal, и каждый из них относится к соответствующей подсети виртуального стенда. IP-адреса этих интерфейсах указываются в других VM в качестве шлюзов по умолчанию.

Включаем NAT для интерфейса eth0. Таблица iptables (файл / etc/ sysconfig/ iptables) получается такой:

# Generated by iptables-save v1.4.7 on Mon Jan 30 23:45:45 2017
*filter
:INPUT ACCEPT [1438:192141]
:FORWARD ACCEPT [8777:3124578]
:oUTPUT ACCEPT [1745:143062]
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
COMMIT
# Completed on Mon Jan 30 23:45:45 2017
# Generated by iptables-save v1.4.7 on Mon Jan 30 23:45:45 2017
*nat
:PREROUTING ACCEPT [5401:731115]
:POSTROUTING ACCEPT [2490:181208]
:oUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Jan 30 23:45:45 2017
В CentOS маршрутизация будет работать и без NAT. Однако, наличие  NAT позволяет, в случае необходимости, публиковать порты.

Вывод команды route:

Kernel IP routing table
Destination     Gateway   Genmask   Flags Metric Ref    Use Iface
192.168.44.0    *   255.255.255.0   U     0 0  0 eth1
192.168.250.0   *   255.255.255.0   U     0 0  0 eth0
192.168.40.0    *   255.255.255.0   U     0 0  0 eth2
192.168.41.0    *   255.255.255.0   U     0 0  0 eth3
link-local *   255.255.0.0     U     1002   0  0 eth0
link-local *   255.255.0.0     U     1003   0  0 eth1
link-local *   255.255.0.0     U     1004   0  0 eth2
link-local *   255.255.0.0     U     1005   0  0 eth3
default   192.168.250.1   0.0.0.0   UG    0 0  0 eth0

Шлюз по умолчанию в системе указывается только для eth0, это позволяет маршрутизировать трафик VM в Интернет.
Полученная конфигурация полностью рабочая, и по функциональности аналогична приведенной в разделе 2.

4. Заключение
Вместо программного маршрутизатора RRAS или CentOS можно было бы использовать “псевдо-аппаратный” на эмуляторе GNS3 (https://www.gns3.com). GNS3 – это полнофункциональный эмулятор Cisco, который, в отличие от Packet Tracer, можно использовать в кастомизированной виртуальной среде. Изначально он доступен в качестве VMware VM, но существуют и способы его адаптации под Hyper-V (Google в помощь). Использование GNS3 позволяет привнести в стенд еще и логику Cisco устройств - возможности для экспериментирования здесь безграничные.

Особенности диагностики процесса SCCM 2012 R2 Client Push Install

Недавно я разворачивал систему SCCM 2012 R2 в достаточно крупной организации. В числе прочего, столкнулся с довольно неочевидной проблемой при распространении клиентов Configuration Manager методом Push Install.

Операция Client Push Install, в общем случае, работает одновременно для всех клиентов в области обнаружения в сайте; есть возможность только отдельно выбрать, ставить ли клиента на машины с ОС рабочих станций, серверов, и с установленными ролями системы сайта SCCM (а также указать, выполнять ли установку на DC). Для детального контроля списка целевых машин предпочтительнее использовать другие варианты установки клиента (через групповые политики, например).

В данном случае SCCM клиентов нужно было ставить везде и сразу, поэтому вариант Push Install подходил. Однако, из-за особенностей работы в конкретном окружении, часть пользовательских машин была недоступна достаточно продолжительное время. По умолчанию, SCCM повторяет попытку автоматической push-инсталляции раз в час в течении недели – см. пост на форуме  https://social.technet.microsoft.com/Forums/en-US/cf3a6a7a-01a2-4425-8032-2639e25c0e81/manually-force-a-client-installation-retry?forum=configmanagerdeployment. В логе сервера сайта ccm.log попытки push-установки для недоступных машин протоколируются вот так (это пример):

---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:30.403-180><thread=4288 (0x10C0)>
---> Attempting to connect to administrative share '\\SPBM115-WSKHALE\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:30.403-180><thread=4288 (0x10C0)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.520-180><thread=4912 (0x1330)>
---> The device MSKTSV-WS11014N does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.521-180><thread=4912 (0x1330)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.522-180><thread=4912 (0x1330)>
---> Attempting to connect to administrative share '\\MSKTSV-WS11014N.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:34.522-180><thread=4912 (0x1330)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.653-180><thread=5152 (0x1420)>
---> The device T430SI-ALEXANDR does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.654-180><thread=5152 (0x1420)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.655-180><thread=5152 (0x1420)>
---> Attempting to connect to administrative share '\\T430si-Alexandr.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:36.655-180><thread=5152 (0x1420)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.989-180><thread=6500 (0x1964)>
---> The device SPBO123-WS21502 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.991-180><thread=6500 (0x1964)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.991-180><thread=6500 (0x1964)>
---> Attempting to connect to administrative share '\\SPBO123-WS21502.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:42.991-180><thread=6500 (0x1964)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.340-180><thread=12752 (0x31D0)>
---> The device SPBM115-WS40101 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.341-180><thread=12752 (0x31D0)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.342-180><thread=12752 (0x31D0)>
---> Attempting to connect to administrative share '\\spbm115-ws40101.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:43.342-180><thread=12752 (0x31D0)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.219-180><thread=8644 (0x21C4)>
---> The device SPBHDQ-WS31504 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.220-180><thread=8644 (0x21C4)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.221-180><thread=8644 (0x21C4)>
---> Attempting to connect to administrative share '\\spbhdq-ws31504.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:47.221-180><thread=8644 (0x21C4)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.330-180><thread=2804 (0xAF4)>
---> The device SPBN85-WS1006 does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.331-180><thread=2804 (0xAF4)>
---> Trying the 'best-shot' account which worked for previous CCRs (index = 0x0)~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.332-180><thread=2804 (0xAF4)>
---> Attempting to connect to administrative share '\\spbn85-ws1006.etalon.local\admin$' using account 'ETALON\svc_SCCMInstall'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:13:49.332-180><thread=2804 (0xAF4)>
---> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account ETALON\svc_SCCMInstall (00000035)  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:14:00.767-180><thread=13204 (0x3394)>
---> The device SPBM115-WSSAV does not exist on the network. Giving up~  $$<SMS_CLIENT_CONFIG_MANAGER><10-11-2015 21:14:00.768-180><thread=13204 (0x3394)>

Операцию Client Push Install можно форсировать вручную с сервера SCCM, выполняющего установку, путем генерации запроса CCR с помощью утилиты ClientPushGenerator.exe (лежит в папке установки SCCM по пути \AdminConsole\bin\ClientpushGenerator.exe). Соответствующая процедура описана здесь:
Запрос к БД SCCM из первого поста отображает время и код завершения последней операции установки:

Fig1.jpg

Последняя попытка инсталляции на 10-THINK (пример недоступной в сети машины) завершилась с ошибкой 53, это стандартный код для “Network path not found”. CCR-запрос пролежал в очереди положенное время (неделю), и истек по таймауту.

Итак, генерируем новую CCR-запись для машины 10-THINK, как описано в статье. В логе ccm.log видим следующее:

Successfully retrieved information for machine 10-THINK fr om DB $$
Execute query exec [sp_CP_GetPushRequestMachineIP] 2097152894~ $$
Execute query exec [sp_CP_GetPushRequestMachineResource] 2097152894~ $$
Execute query exec [sp_CP_GetPushMachineName] 2097152894~ $$
Received request: "2097152894" for machine name: "10-THINK" on queue: "Incoming". $$
Request "2097152894" for machine "10-THINK" doesn't exist in DB or has expired and will not be stored in queue "Processing" . $$
STATMSG: ID=3011 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_CLIENT_CONFIG_MANAGER" SYS=SPbv-srvSCCM.etalon.local SITE=S01 PID=17128 TID=7108 GMTDATE=Ср окт 21 09:31:07.672 2015 ISTR0="10-THINK" ISTR1="162" ISTR2="168" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 $$
Deleted request "2097152894", machine name "10-THINK" $$
То есть, сходу оно не заработало. Выяснилось, что CCR-запросы, генерируемые утилитой ClientPushInstall. exe, игнорируются при наличии для клиента истекшей записи в таблице ClientPushMachine _ G. Поэтому, перед выдачей CCR-запроса, таблицу надо подчистить – или дождаться стандартной операции очистки при обслуживании БД SCCM, но таймаут ротации таких записей достаточно долгий.
Поэтому, делаем такой запрос к SCCM базе (в моем случае, для клиента 10-THINK):

DELETE FR OM ClientPushMachine_G WH ERE Name like '10-THINK'

См. статью “Remove Client Push records in Configuration Manager 2012”, http://systemcenterme.com/remove-client-push-records-in-sccm-2012/.
И уже после этого повторно генерируем CCR-запись с помощью Client Push Generator. Теперь в логе ccm. log видим следующее:

Received request: "2097152894" for machine name: "10-think" on queue: "Incoming".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:41.830-180><thread=7108 (0x1BC4)>
Stored request "2097152894", machine name "10-think", in queue "Processing".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:41.831-180><thread=7108 (0x1BC4)>
Execute query exec [sp_CP_SetPushRequestMachineStatus] 2097152894, 1~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:41.845-180><thread=7108 (0x1BC4)>
----- Started a new CCR processing thread. Thread ID is 0x2100. There are now 1 processing threads  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.849-180><thread=7108 (0x1BC4)>
Submitted request successfully  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.850-180><thread=7108 (0x1BC4)>
Getting a new request from queue "Incoming" after 100 millisecond delay.  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.850-180><thread=7108 (0x1BC4)>
Waiting for change in directory "C:\Program Files\Microsoft Configuration Manager\inboxes\ccr.box" for queue "Incoming", (30 minute backup timeout).  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.851-180><thread=7108 (0x1BC4)>
======>Begin Processing request: "2097152894", machine name: "10-think"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.850-180><thread=8448 (0x2100)>
Execute query exec [sp_IsMPAvailable] N'S01'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.873-180><thread=8448 (0x2100)>
---> Trying each entry in the SMS Client Remote Installation account list~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.874-180><thread=8448 (0x2100)>
---> Attempting to connect to administrative share '\\10-THINK\admin$' using account 'ETALON\admin'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.875-180><thread=8448 (0x2100)>
---> Connected to administrative share on machine 10-THINK using account 'ETALON\admin'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.953-180><thread=8448 (0x2100)>
---> Attempting to make IPC connection to share < \\10-THINK\IPC$ > ~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.953-180><thread=8448 (0x2100)>
---> Searching for SMSClientInstall.* under '\\10-THINK\admin$\'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:43.957-180><thread=8448 (0x2100)>
---> System OS version string "6.1.7601" converted to 6,10  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.464-180><thread=8448 (0x2100)>
---> Unable to connect to WMI (root\ccm) on remote machine "10-THINK", error = 0x8004100e.  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.490-180><thread=8448 (0x2100)>
~'PushClientEvenIfDC' flag is set. Skipping DC checks.  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.490-180><thread=8448 (0x2100)>
---> Creating \ VerifyingCopying existence of destination directory  \\10-THINK\admin$\ccmsetup.~   $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.492-180><thread=8448 (0x2100)>
---> Copying client files to  \\10-THINK\admin$\ccmsetup.~   $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.495-180><thread=8448 (0x2100)>
---> Copying file "C:\Program Files\Microsoft Configuration Manager\bin\I386\MobileClient.tcf" to "MobileClient.tcf"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.499-180><thread=8448 (0x2100)>
---> Copying file "C:\Program Files\Microsoft Configuration Manager\bin\I386\ccmsetup.exe" to "ccmsetup.exe"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.520-180><thread=8448 (0x2100)>
---> ForceReinstall flag is set to true  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.680-180><thread=8448 (0x2100)>
---> Created service "ccmsetup" on machine "10-THINK".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:44.694-180><thread=8448 (0x2100)>
---> Started service "ccmsetup" on machine "10-THINK".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.187-180><thread=8448 (0x2100)>
---> Deleting SMS Client Install Lock File '\\10-THINK\admin$\SMSClientInstall.S01'~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.189-180><thread=8448 (0x2100)>
Execute query exec [sp_CP_SetLastErrorCode] 2097152894, 0~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.236-180><thread=8448 (0x2100)>
---> Completed request "2097152894", machine name "10-think".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.239-180><thread=8448 (0x2100)>
Deleted request "2097152894", machine name "10-think"  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.239-180><thread=8448 (0x2100)>
Execute query exec [sp_CP_SetPushRequestMachineStatus] 2097152894, 4~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.241-180><thread=8448 (0x2100)>
Execute query exec [sp_CP_SetLatest] 2097152894, N'10/21/2015 10:21:45', 1~  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.244-180><thread=8448 (0x2100)>
<======End request: "2097152894", machine name: "10-think".  $$<SMS_CLIENT_CONFIG_MANAGER><10-21-2015 13:21:45.246-180><thread=8448 (0x2100)>

Begin Processing request – это именно то, что нам надо, при доступности сетевого ресурса \\10-THINK\Admin$ для учетной записи инсталляции процесс запускается сразу. Клиент через положенное время встал:

Fig2.jpg

Проблема здесь в том, что для каждого такого клиента просроченные записи нужно удалять вручную. Можно, в принципе, попытаться придумать какой-нибудь хитрый запрос к базе данных для удаления только нужных клиентов по коду завершения предыдущей операции CCR. И, конечно, надо соблюдать осторожность при прямой работе с БД Configuration Manager!

А в остальном - методика рабочая.

Автоматизированное распространение клиента Lotus Notes с настроенной конфигурацией

1. Постановка задачи
Некоторое время назад пришлось выступить консультантом по решению достаточно специфической задачи.
Предприятие разворачивало корпоративную почтовую систему на базе IBM Domino 8. Рабочих мест – до 800, впоследствии Lotus предполагалось использовать также для организации документооборота. Парк рабочих станций был разношерстным, в большом количестве присутствовали системы еще Windows 2000 Professional, были также XP/Vista/7, как 32-, так и 64-разрядные.
В процессе установки Notes очень хотелось передать клиенту некоторые настройки – как минимум, параметры подключения к серверу Domino, чтобы не тратить время на указание параметров связи на каждом клиенте вручную. Помимо этого, нужно было разворачивать дистрибутив клиентской части только с определенным набором компонент, и обеспечивать SSO - синхронизацию пароля Notes ID с паролем работающего пользователя Windows, избавив его от необходимости помнить отдельный пароль в почтовый клиент, и вводить его каждый раз.
Служба каталогов AD была, системы управления конфигурациями и распространения ПО – как обычно, нет. Требовалось организовать автоматизированное развертывание клиента имеющимися средствами.
Определенная проблема возникала также из-за разнородности клиентских ОС (особенно порадовало наличие Windows 2000; предприятие, кстати, было режимным). Вендорская матрица совместимости клиентов Notes (http://www-01.ibm.com/support/docview.wss?rs=475&uid=swg27007909) гласит, что последняя совместимая с Windows 2000 версия клиента Notes – не старше 7.0.4, а актуальной для заказчика на момент установки была 8.5.2 (встает на Windows XP SP2 и старше). Поэтому, было принято решение создать набор настроенных пакетов для установки:
· Lotus Notes 7.0.4, русская версия (для Windows 2000);
· Lotus Notes 8.5.2 x86, русская версия (для 32 и 64-разрядных Windows XP/Vista/7);
Логика выбора конкретной версии пакета для установки на каждом клиенте я решил реализовывать универсальным скриптом.
Кроме того, на клиенты Lotus Notes 8.5.2 в процессе инсталляции хотелось сразу же ставить еще и пакет обновлений FixPack 2 (http://www-01.ibm.com/support/docview.wss?uid=swg24028680; кстати, механизм SSO на клиенте 8.5.2 без установленного FP на 64-битной системе не работает).  Для клиента Notes 7.0.4 FixPack’ов не имелось.

2. Настройка пакетов
Для настройки пакетов unattended-установки клиента Notes служит утилита InstallShield Tuner. Сам процесс настройки очень подробно описан в пошаговом руководстве “The great Lotus Notes installation guide” (http://www.lotus-expert.com/en/articles/sntt-customize-client-installation.html), переписывать его не буду. Скажу только, что, для моей задачи, мне хватило следующих разделов:

· Preparations (страница A) – для подготовки дистрибутива. В качестве настроечной станции для запуска InstallShield Tuner я использовал виртуальную машину с русской версией Windows 7 Enterprise SP1 x86, никаких проблем не возникло. Замечание из предыдущего опыта – для настройки пакетов установки локализованных версий клиента Notes, всегда лучше использовать установку ОС соответствующей локали, иначе впоследствии, при развертывании пакета на целевых системах, возможны проблемы с кодировкой. В частности, я сталкивался с тем, что названия служб Notes в операционной системе в этом случае регистрировались “крякозябрами”.
JDK мне не понадобился;

· Changing the Installation Features (страница 5) – здесь необходимо выбрать компоненты для установки в составе клиента. В моем случае достаточно было стандартного набора без офисной части, клиент Sametime также не был нужен;

· Adding Notes. ini Options (страница 6) – здесь задается возможность передачи собственных параметров в файл notes. ini настройки клиента (см. ниже страницу 8, Scriptable setup). Поэтому, важный момент - необходимо установить параметр VDIR_INI, как описано в руководстве;

· Multi- user vs. single- user installation (страница 7) – в корпоративном окружении, в доменной среде используем вариант multi-user. В этом случае все настройки клиента хранятся в профиле пользователя Windows;

· Scriptable setup, страница 8. Здесь создается INI-файл с теми настройками, которые при установке отображаются в конфигурационный файл notes. ini. В частности, таким образом можно передать клиенту параметры подключения к серверу Domino, так, чтобы при первом запуске клиента никакие данные, кроме ID-файла не запрашивались. Это сильно минимизирует риск ошибок при начальной настройке.
Для автоматизации подключения к серверу почты (без IM), опций Domino. Port, Domino. Name, Domino. Server, AdditionalServices и AdditionalServices. NetworkDial минимально достаточно. Поэтому у меня получился такой файл company_notes.cfg, размещаемый в подкаталоге plugins кастомизированного пакета:

Domino.Port=TCPIP
Domino.Name=CM01/FGUP
Domino.Server=1
AdditionalServices=-1
AdditionalServices.NetworkDial=0
Нужно понимать, что для того, чтобы это заработало правильно, необходимо обеспечить корректную работу механизмов разрешения имен Notes поверх TCP/IP. Иначе может получиться так, что при первом запуске клиента документ соединения (connection document) будет создан неверно, и это потом придется исправлять на каждом клиенте вручную. О разрешении имен необходимо позаботиться заранее;

· Use the .mst (страница 13). Здесь приводится командная строка, которая применяет созданный файл преобразований (transform) к установочному пакету. Она нам понадобится при создании скрипта установки (см. ниже). То есть, мне нужен вариант 13. I. A ( Batch files).
Больше никакие разделы из данного руководства мне не понадобились. Installshield Tuner необходимо использовать для обоих пакетов (7.0.4 и 8.5.2). На выходе получаем по одному MST (transform) для каждого пакета, вся логика настройки стандартного дистрибутива содержится в них.

Для справки несколько дополнительных ссылок:
“Automating Notes installation using a silent install”, https://www-01.ibm.com/support/knowledgecenter/SSKTMJ_8.0.1/com.ibm.help.domino.admin.doc/DOC/H_AUTOMATING_INSTALLS.html;
“Setting up Notes installation using scriptable setup”, https://www-01.ibm.com/support/knowledgecenter/SSKTMJ_9.0.1/admin/inst_settingupnoteswithascriptablesetup_c.dita.

В результате сборки, у меня получилась следующая структура пакетов, размещаемая на сетевом дистрибутивном ресурсе в домене AD (под корнем \\SERVERNAME\Distr):

· Distr\Notes\7.0.4 – дистрибутив клиента Notes 7.0.4 (включая MST-файл);
· Distr\Notes\8.5.2 – дистрибутив клиента Notes 8.5.2 (включая MST-файл);
· Distr\Notes\8.5.2.FP2 – дистрибутив Notes 8.5.2 FixPack 2;
· Distr\Notes\Shortcuts\7.0.4 – ярлыки клиента Notes 7.0.4;
· Distr\Notes\Shortcuts\8.5.2\x86 – ярлыки клиента Notes 8.5.2 для 32-разрядной ОС;
· Distr\Notes\Shortcuts\8.5.2\x64 – ярлыки клиента Notes 8.5.2 для 64-разрядной ОС.

3. Универсальный VBS -скрипт установки
Скрипт можно загрузить из приложения (файл Install.7z), и при необходимости адаптировать. Хотелось бы сделать несколько замечаний:
· Разрядность ОС (логика введена для копирования ярлыков) определяется по системной переменной PROCESSOR_ARCHITECTURE, а версия ОС – по выводу встроенной команды ver командного интерпретатора cmd. exe;
· Скрипт определяет наличие клиента Notes на целевой системе по присутствию файла notes. exe в соответствующем каталоге. Если файл обнаружен, ничего не делается;
· Опытным путем установлено, что при подобной инсталляции (скриптом, запускаемым с правами системы из объекта групповой политики AD, в сочетании с пакетом клиента Notes для автоматизированной установки), операция установки проходит отлично, но, почему-то, в профилях пользователей не создаются ярлыки для программ. Поэтому я просто подготовил отдельные наборы эталонных ярлыков (файл Shortcuts.7z) для клиентов Notes 7 и 8, для x86 и x64-систем, для “Главного меню” и “Рабочего стола”, и по завершении операции установки копировал их явно командой xcopy в необходимые каталоги. Метод оказался вполне рабочим, никаких проблем не возникло;
· В процессе установки (асинхронной), хотелось оповестить работающего пользователя о выполняемой процедуре и предстоящей перезагрузке. Еще в Windows 2000 для этого существовала утилита msg. exe (выдает всплывающее сообщение на консоль), однако, здесь применен другой подход – для Windows 2000, из системы Windows XP SP3 взята утилита shutdown. exe, которая, по завершении установки, в случае, если нужна перезагрузка, выдает на пользовательский экран модальное окно о завершении работы системы, и инициирует перезапуск через 2 минуты. Перезагрузка же необходима для того, чтобы заработала служба единого входа в Lotus Notes клиент (SSO).
В Windows XP и позже утилита shutdown. exe есть штатно.
Соответствующие команды в скрипте такие:

RestartCmd = "shutdown.exe -r -f -t 120 -c " & Chr(34) & "Система будет перезагружена, приготовьтесь к завершению работы!" & Chr(34)
objShell.Run RestartCmd,0,FALSE

· Операция установки 8.5.2 FixPack 2 для Windows 2000 не нужна, так как для этой ОС устанавливается более старый клиент;
· Чтобы скрипт не был “черным ящиком”, введено простое протоколирование операций установки в текстовый файл на каждой системе во временный каталог (в файл %TEMP%\runresult.tmp). Это позволяет отследить, что именно происходило, если что-то пошло не так. Выглядит лог примерно так (вариант успешной установки клиента 8.5.2):

ЛОГ СКРИПТОВОЙ УСТАНОВКИ NOTES
13.12.2012 17:52:52
Инициализация скрипта установки...
Обнаружена операционная система Windows Vista и выше
Система имеет 64-разрядную архитектуру, путь установки Notes C:\Program Files (x86)\IBM\Lotus\Notes\notes.exe
Попытка установки клиента версии 8.5.2.
13.12.2012 18:03:05
Установщик вернул код 0
Попытка установки 8.5.2 Fixpack 2.
13.12.2012 18:06:23
Установщик вернул код 0
Путь общего пользовательского профиля C:\ProgramData
Копируем ярлыки главного меню в C:\ProgramData\Microsoft\Windows\Start Menu\Programs
xcopy "\\DM1-DC01\Distr\Notes\Shortcuts\8.5.2\x64\Lotus Applications" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Lotus Applications" /E /I /R /Y
Копирование вернуло код 0
Копируем ярлыки рабочего стола в C:\ProgramData\Desktop
xcopy "\\DM1-DC01\Distr\Notes\Shortcuts\8.5.2\x64\Lotus Notes 8.5.lnk" "C:\ProgramData\Desktop" /R /Y
Копирование вернуло код 0
Инициирована перезагрузка системы.
Скрипт завершен.
13.12.2012 18:06:28

Все имена серверов и организации в скрипте и примере конфигурации, конечно, изменены.

4. Замечания по установке клиента Notes
По завершении установки, однократный визит на каждую рабочую станцию все-таки нужен – для того, чтобы выдать пользователю его ID-файл с начальным паролем (который потом синхронизируется с паролем Windows). ID-файлы для каждого пользователя нужно предварительно подготовить, это стандартная задача администратора Domino. Но, в любом случае, предоставление Notes клиенту ID-файла – простая операция, занимающая минимум времени, а все остальное автоматизировано.
Дальнейшие настройки Notes клиента (после подключения к предварительно сконфигурированному серверу) можно выполнять уже с помощью политик Domino. В частности, можно задать список доступных баз данных на рабочей области Notes клиента.
Клиенты Lotus Notes от версии к версии, в сущности, меняются мало, поэтому, уверен, эта методика установки будет актуальной еще долгое время.

5. Групповая политика AD
Здесь реализация стандартная. Скрипт назначается как стартовый на контейнер Computer Configuration объекта групповой политики. Дополнительно, так как установка занимает достаточно длительное время, в ветви административных шаблонов (Computer Configuration\ Policies\Administrative Templates\System\Scripts) устанавливается два параметра:
· Maximum wait time for Group Policy ScriptsEnabled, 0 (значение 0 означает, что скрипт не будет прерван принудительно, и расширение Script CSE на клиентской стороне в любом случае дождется его завершения);
· Run startup scripts asynchronously  – Enabled , задает выполнение скрипта в фоновом режиме (асинхронно по отношению к процедуре входа в систему):


GPO Script Settings.jpg

Ну и традиционное замечание: групповая политика установки применяется при следующей перезагрузке целевой рабочей станции; дабы избежать падения производительности сети и сервера с дистрибутивом, крайне рекомендуется создать специальную группу безопасности в AD, и включать в нее целевые учетные записи компьютеров поэтапно, используя для созданных групповых политик фильтрацию по ACE “Apply Group Policy” (опция Security Filtering консоли GPMC) для этой группы.

Shortcuts.7z ( 4.15 КБ) Install.7z ( 2.67 КБ)

Опыт траблшутинга SEP 12.1 Client AutoUpgrade

Опять о том же.

Получил достаточно интересный опыт применения технологии AutoUpgrade для развернутого решения SEP 12.1 для обновления клиентов. Требовалось обновить инсталляцию c RU3 до RU5.

Технология AutoUpgrade  вскользь упоминалась в предыдущем посте (“Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик AD”, http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php).

Полностью процесс обновления SEP описан здесь – “Upgrade or migrate to Symantec Endpoint Protection 12.1.5” https://support.symantec.com/en_US/article.TECH224034.html. Начинать надо с обновления серверной части.

Здесь речь пойдет о двух специфических моментах, связанных с обновлением клиентов (собственно технологией AutoUpgrade). Сама процедура обновления описана в статье “Upgrade Symantec Endpoint Protection 12.1 clients using AutoUpgrade”, https://support.symantec.com/en_US/article.TECH96789.html.

1.
Для того, чтобы обновление успешно запустилось на группе, по факту нужно установить несколько параметров распространения пакета в следующие значения (на скрине пример нужных настроек):



· Сохранить существующие функции клиента при обновлениифлаг снят;
· Расписание обновленияфлаг снят;
· Время рассылки обновлений0 дней.

Последние два параметра инициируют немедленную рассылку пакета (при следующей пульсовой передаче). А если не снять первый флаг, пакет обновления может быть отклонен клиентом.

Соответствующие вопросы обсуждаются на форумах Symantec Connect, например, здесь: http://www.symantec.com/connect/articles/upgrade-clients-sep-121-auto-upgrade-feature

2.
В процессе развертывания, некоторые разрозненные клиенты RU3 (порядка 4%), все равно явно отклонили пакет обновления RU5, записав об этом в лог. Выглядело это вот так (в свойствах клиента):



Чтобы найти причину, в конце концов понадобилось включить SMC/Sylink Debugging на тестовом клиенте (“Enable sylink debugging for Endpoint Protection clients”, https://support.symantec.com/en_US/article.TECH104758.html). Выяснилось, что в дебаг логе клиента SMC c:\ programdata\symantec\symantec endpoint protection\12.1.3001.165\Data\Logs\debug.log в момент загрузки пакета обновления фиксируются следующие строки:

2015/04/23 23:46:12.822 [4068:4180] unmatched language type.  the requested auto-upgrade cancelled.
2015/04/23 23:46:12.822 [4068:4180] Upgrade package not needed by SMC. .checking if opstate to be sent or not.

Анализ показал, что на проблемных системах ошибочно определялась ситуация, описанная в статье “AutoUpgrade fails if the language of the assigned package does not match the language of the currently installed client”, https://support.symantec.com/en_US/article.TECH153398.html - несовпадение языков установленного клиента и назначенного пакета обновления. Причем, в реальности, никакого несовпадения не было.

SEP клиент 12.1 RU3 отслеживает свою локализацию по двум параметрам реестра в ключе  HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC : HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\ProductLocale (тип REG_DWORD) и HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\Language (тип REG_SZ).

На русских версиях клиента параметры должны быть такие: ProductLocale =0x00000419 (1049), и Language =”Russian”.

Оказалось, что на проблемных системах RU3, отклонивших обновление до RU5, параметр Language почему-то установился в “ English”, хотя и локаль клиента, и операционная система были русские. Видимо, SEP клиент RU3 так определил язык при изначальной инсталляции. Почему – неизвестно; возможно, причиной было наличие какого-то специфического стороннего программного компонента либо настройки, или еще что-то в этом роде.

Workaround заключается в том, чтобы вручную через реестр сменить параметр HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\Language на "Russian”, затем перезапустить клиент командами smc –stop и smc –start (делать это нужно с правами  администратора; при остановке клиента спрашивается пароль на выгрузку SEP, если он установлен), и затем переобъявить пакет обновления до RU5 на группу средствами SEP Manager. Решение помогает сразу.

ПРИМЕЧАНИЕ.
Для очень больших групп, немедленное развертывание клиента теоретически может вызвать лаг сети и сервера, о чем SEPM честно предупреждает при публикации пакета. Однако я с какими-либо проблемами производительности на инсталляции порядка 650 клиентов, распределенных по примерно 7 группам, не столкнулся.

Распространение SEP 12.1 с помощью групповых политик. Вариант для беспроводных соединений с авторизацией по входу пользователя в домен

Cтатья описывает несколько видоизменное решение из предыдущего поста (“Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик AD”, http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php).

В процессе того же внедрения, обнаружилась специфическая именно для данной инфраструктуры проблема. Заказчик в офисе активно использовал Wi-Fi, и более половины парка рабочих станций составляли ноутбуки, работавшие только по беспроводному соединению; причем, авторизация системы на точках доступа внутренней сети происходила только после входа пользователя в домен (для выдачи сертификатов авторизации использовалась служба AD CS).

В ОС Windows политики, назначенные на контейнер Computer Configuration, запускаются в обработку, в общем случае, еще до момента входа пользователя в систему (и до появления стандартного приглашения на вход по Ctrl-Alt-Del). Поэтому предложенный ранее метод для беспроводных клиентов не работал - так как, на момент инициализации и применения политик, системы еще не были авторизованы в сети, и не имели доступа к файловым ресурсам с дистрибутивами. В то же время, для проводной сети все работало отлично.

Поэтому решили инициировать запуск скрипта установки альтернативным методом – путем добавления задачи в планировщик Task Scheduler операционной системы через механизм Group Policy Preferences (GPP). Поскольку все клиенты работали под управлением Windows 7/8, проблем с совместимостью параметров GPP со старыми версиями ОС не возникло.

Процесс по шагам:

1.
Для того, чтобы создать нужное задание в планировщике, в GPO в контейнере Computer Configuration\Preferences\Control Panel Settings\Scheduled Tasks создаем новое задание командой New\Scheduled Task (At least Windows 7), и устанавливаем такие параметры задания (вкладка General):


Доменная учетная запись SEPInstall должна иметь административные права на целевой рабочей станции, доступ на чтение к файловому ресурсу с дистрибутивом и постоянный пароль на время развертывания (пароль сохраняется в свойствах назначенного задания);

2.
Триггер старта задания устанавливаем, например, так:


Так как задача запускается периодически, в скрипт должна быть добавлена какая-то логика определения уже успешной установки, дабы процедура не запускалась снова и снова (см. мой комментарий к предыдущему посту);

3.
На вкладке Actions устанавливаем запуск скрипта:


Обращаю внимание, что, пакетов будет два - для x86 и x64 версий клиента (см. предыдущий пост http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php), поэтому политик GPO и скриптов установки опять таки должно быть по паре, для систем разной разрядности. То есть, все, что говорилось в ранее о таргетировании с помощью WMI-фильтров на 32- и 64-разрядные системы, в силе - повторяться не буду;

4.
Ниже рабочие примеры вкладок Conditions и Settings, оттестированные в реальном окружении:



5.
И, наконец, сами скрипты для установки клиента – те же, что уже публиковались (http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php?commentId=1590). По сути, методика может использоваться и для систем с обычным (проводным) подключением. Теперь можно отказаться и от перезагрузки системы для запуска процедуры инсталляции (задача добавляется в планировщик сразу же при очередном цикле применения GPO).

ЗАМЕЧАНИЯ.

· Идея взята отсюда - http://www.grouppolicy.biz/2010/01/how-to-schedule-a-delayed-start-logon-script-with-group-policy.
Но - есть определенные нюансы безопасности при хранении учетных данных назначенных заданий в объектах GPO, и в самом планирощике Task Scheduler. В принципе, это может быть проблемой, так что решение предоставляется AS IS.
В любом случае, по завершении развертывания, соответствующие объекты групповых политик и планировщика желательно удалить, а пароль служебной учетной записи инсталляции – поменять;

· Для синхронизации применения групповых политик с моментом входа пользователя в систему существуют альтернативные решения, см. многочисленные посты по теме на http://social.technet.microsoft.com/Forums/windowsserver/en-US/home. Но, по ряду причин, в данном конкретном случае применять их было нежелательно. Поэтому и придуман вариант с GPP;

· Опять-таки - решение не заменит полноценную систему управления конфигурациями, даже для установки ПО. Для серьезных ИТ-инфраструктур она обязательна!

Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик Active Directory

Во время одного внедрения антивирусного решения Symantec Endpoint Protection 12.1 в достаточно крупной сети (порядка 1000 клиентов под разными версиями ОС Windows, один сервер SEP Manager), потребовалось организовать автоматизированное развертывание клиентов SEP.

Symantec Endpoint Protection, в общем, не предоставляет для этого собственных средств. Консоль SEPM имеет исчерпывающий функционал по генерации пакетов развертывания, и интерактивный интерфейс для push-инсталляции, предполагающий, что клиент доступен по сети в момент установки. В большой среде такое, фактически ручное, “проталкивание” клиента, конечно, неэффективно.  

Кроме того, по установленным регламентам, рабочие станции были достаточно строго закрыты брандмауэром Windows Firewall, что делало доступ к ним через сеть по протоколам RPC/SMB невозможным. Обычные методы удаленной инсталляции антивирусных клиентов с сервера (это справедливо не только для SEP, но и, скажем, для Trend Micro OfficeScan, Kaspersky Security, и т.д.) предполагают соблюдение, как минимум, следующих условий:

·   Доступность удаленного хоста по RPC/SMB, что, в случае брандмауэра Windows Firewall, означает включенные стандартные правила группы “Общий доступ к файлам и принтерам” для входящих подключений;
·   Доступность административного общего ресурса ADMIN$ на удаленном хосте;
·   Отключенный простой общий доступ к файлам (см. “How to disable simple file sharing and how to set permissions on a shared folder in Windows XP”, http://support.microsoft.com/kb/307874/en-us) на удаленном хосте;
·   Запущенную на удаленном хосте службу Remote Registry (в новых версиях ОС Windows по умолчанию отключена);
·   Начиная с ОС Windows Vista, некоторые специфические настройки UAC (см. “Description of User Account Control and remote restrictions in Windows Vista”, http://support.microsoft.com/kb/951016).

В контексте клиента SEP, требования подробно описаны вот здесь:
·   “Push install Symantec Endpoint Protection 12.1 clients using Remote Push”, http://www.symantec.com/business/support/index?page=content&id=tech164327;
·   “Preparing Windows and Mac computers for remote deployment”, http://www.symantec.com/business/support/index?page=content&id=HOWTO80805.

В данном случае условия частично не выполнялись. Полноценной системы управления конфигурациями (Microsoft SCCM, Symantec Altiris, и т.п.), как обычно, не было, поэтому решено было обойтись средствами AD. Решение описано ниже.

1.
Клиент SEP - стандартный для всех версий клиентских ОС Windows, но отдельный для разрядностей x86 и x64. Способа подготовить единый пакет для обеих разрядностей не существует, поэтому необходимы два пакета. Клиенты для ОС Windows можно найти в распакованном виде в структуре дистрибутива ПО Symantec Endpoint Protection. В моем примере (для билда RU3, дистрибутив скачан с Symantec FileConnect, распакован в папку C:\Distribs\SEP 12.3\unpack), они лежат в локальных папках:

C:\Distribs\SEP 12.3\unpack\Symantec_Endpoint_Protection_12.1.3_Part1_Installation_RU\SEP
и
C:\Distribs\SEP 12.3\unpack\Symantec_Endpoint_Protection_12.1.3_Part1_Installation_RU\SEPx64

для x86 и x64 соответственно.

Сначала необходимо создать административную установку клиентов x86 и x64 в сети на сетевом ресурсе (общей папке), доступной с клиентских рабочих станций. Папка и файловая система NTFS должны иметь разрешения, как минимум, Read для учетных записей компьютеров AD (обычно достаточно разрешения Read для группы Domain Computers на общем ресурсе). Это важно, так как пакет будет назначаться (assign) для учетной записи компьютера, что обеспечит и независимость от наличия пользовательских административных прав, и автоматическую установку при следующем старте системы.

Для того, чтобы подготовить административную установку пакета x86, необходимо из каталога C:\Distribs\SEP 12.3\unpack\Symantec_Endpoint_Protection_12.1.3_Part1_Installation_RU\SEP запустить msiexec /a Sep.msi. Откроется мастер установки, в котором нужно указать единственный параметр – целевой каталог в удаленном общем ресурсе. В моем примере создана структура типа \\SERVER1\SHARE1\SEPClient, и в нем папки x86 и x64 для двух разных пакетов. То есть, для пакета x86 целевым ресурсом будет \\SERVER1\SHARE1\SEPClient\x86.
Для пакета x64, аналогично, из каталога C:\ Distribs\ SEP 12.3\ unpack\ Symantec_ Endpoint_ Protection_12.1.3_ Part1_ Installation_ RU\ SEPx64 запустить команду msiexec / a Sepx64.msi, и указать целевой ресурс:
\\SERVER1\SHARE1\SEPClient\x64.

2.
Пакеты созданы, но пока “отвязаны” от сервера SEPM (так как взяты непосредственно из дистрибутива). Их надо “натравить” на наш конкретный сервер SEPM, иначе они поставятся как неуправляемые (unmanaged). Чтобы клиенты установились как управляемые (managed), нужно скопировать в пакеты конфигурационный файл SyLink.XML. Это файл привязки, он содержит ссылку на сервер управления SEPM и его цифровой сертификат SSL.

Мы предполагаем, что сервер SEPM уже развернут – а это значит, что образец такого файла есть в инсталляции серверной части. Идем в папку установки SEPM на сервере управления, нас интересует каталог % Program Files (x86)%\Symantec\Symantec Endpoint Protection Manager\ data\outbox\agent. В нем находится, как минимум, одна подпапка с именем _UID_, где UID - это уникальный идентификатор пакета, например, 8F171749C0A85C820163FBAA230DBF18 (реально для разных версий клиента папок будет несколько). Заходим в любую такую папку, и копируем из нее файл Sylink.XML (они одинаковые для всех UID-папок). Этот файл нужно положить в корни каталогов с сформированными намиранее административными установками клиента - то есть, в нашем примере, в папки \\SERVER1\SHARE1\SEPClient\x86 и\\SERVER1\SHARE1\SEPClient\x64.

Примечание. Инсталляционный пакет клиента также можно брать не из дистрибутива, а экспортировать из установленного SEPM стандартными средствами консоли SEP Manager. Здесь эта процедура не рассматривается. Она описана в ряде статей Symantec Support Knowledge Base, в частности, в статье “Creating custom client installation packages in the Symantec Endpoint Protection Manager console”, http://www.symantec.com/business/support/index?page=content&id=TECH102817. Для возможности установки клиента через групповые политики необходимо выбрать вариант экспорта в формате .MSI (а не .EXE) Экспорт пакетов также документирован в Symantec Endpoint Protection Administration Guide (для SEP 12.1 RU5, руководство лежит по ссылке http://www.symantec.com/business/support/index?page=content&id=DOC7698). Пакеты из SEPM можно экспортировать со списком включаемых компонент и c настройками (в частности, задавать целевую клиентскую группу, применяемые политики, и т.д.), и также распространять их средствами AD. Такой вариант может быть даже предпочтительным, так как дает гораздо больший контроль.

Мы же, в своем примере, генерируем “нулевой” пакет непосредственно из дистрибутива. Клиенты, поставленные таким образом (со стандартным файлом SyLink.XML), попадут в клиентскую группу по умолчанию, и к ним применится стандартный набор параметров.

3.
Дальнейшие шаги, в сущности, похожи для установки любого ПО, назначаемого через групповые политики. Необходимо создать два объекта GPO с помощью консоли Group Policy Management. Политик будут две – отдельно для x86 и x64 клиента. В нашем примере они называются так:
·   “Install SEP x86 Managed Client” – для 32-битного клиента;
·   “Install SEP x86 Managed Client” – для 64-битного клиента.

Обе политики назначаем на один и тот же целевой контейнер AD, в котором располагаются учетные записи компьютеров (предполагается, что там есть клиенты разной разрядности). В политику нужно включить следующие параметры:

· Сам пакет. Пакеты назначаются (тип Assigned) на контейнер Computer Configuration (не User Configuration), то есть, на раздел GPO Computer Configuration\Policies\Software Settings\Assigned Applications. Для 32-разрядной политики назначаем пакет \\SERVER1\SHARE1\SEPClient\x86\sep.msi, для 64-разрядной - пакет\\SERVER1\SHARE1\SEPClient\x64\sep64.msi. Настройки пакетов по умолчанию, файлы преобразований (transform) не используются;
· Параметр Computer Configuration\Policies\Administrative Templates\System/Logon\Always wait for the network at computer startup and logonВключить (задает синхронную установку); · Параметр Computer Configuration\Policies\Administrative Templates\Windows Components/Windows Installer\Always install with elevated privileges – Включить (установка выполняется с максимальными привилегиями).

Больше ничего в политиках конфигурировать не надо. Последние два параметра в отчете GPMC выглядят вот так:



4.
Далее, пакеты необходимо таргетировать на системы соответствующей разрядности. Для этого проще всего воспользоваться WMI-фильтрами. Пример рабочего решения - http://serverfault.com/questions/18670/group-policy-preferences-that-only-target-32bit-or-64bit-os. Фильтры нужно создать с помощью консоли Group Policy Management, в моем примере они называются “x86 System” и “x64 System”. Фильтр “x86 System”.

Фильтр “x86 System”:


Фильтр “x64 System”:


Теперь назначаем фильтры на политики с помощью GPMC:
· Политика “Install SEP x86 Managed Client” – WMI-фильтр “x86 System”;
· Политика “Install SEP x64 Managed Client” – WMI-фильтр “x64 System”.

5.
Групповая политика установки SEP-клиента применится при следующей перезагрузке целевой рабочей станции. Дабы избежать лага в производительности сети и файл-сервера, на котором размещены установочные пакеты, крайне рекомендуется создать специальную группу безопасности в AD, и включать в нее целевые учетные записи компьютеров поэтапно (например, пачками по 50 штук за раз), и использовать для созданных групповых политик фильтрацию по ACE “Apply Group Policy” (опция Security Filtering консоли GPMC) для этой группы. Таким образом можно контролировать развертывание на вполне приемлемом уровне.

ЗАМЕЧАНИЯ.
·       Решение не заменит полноценную систему управления конфигурациями, даже для установки ПО. Однако, при ее отсутствии, этим способом можно выполнять достаточно масштабные развертывания;
·       Установка синхронная, до ее завершения пользователь лишен возможности войти в систему. Поэтому перед роллапом людей надо предупреждать;
·       Подобная методика может, в принципе, быть использована для распространения не только клиента SEP, но и для любых других, не очень больших по размеру, пакетов .MSI;
·       После начального развертывания SEP клиентов, подключенных к серверу SEPM, в дальнейшем для апгрейда на более новые  версии (скажем, с 12.1 RU3 до 12.1 RU5), групповые политики использовать необходимости уже нет. Можно вместо этого задействовать возможности SEP Manager для автоматического развертывания обновленной версии клиента поверх установленной старой. Для обновления это работает.
Фото:

Бэкап Exchange 2007 под Windows Server 2008 R2 штатными средствами ОС

Недавно создавал небольшую организацию Exchange 2007 для одного из заказчиков. Сервер Exchange был всего один, он же являлся по совместительству одним из контроллеров домена AD. Операционная система - Windows 2008 Server R2 Standard. Exchange 2007, соответственно - SP3 (так как более ранние сборки Exchange 2007 на Windows Server 2008 R2 не работают).

Нормального программного обеспечения для резервного копирования (Symantec Backup Exec, Microsoft DPM и т.д), как обычно, не имелось, поэтому пришлось настраивать бэкап штатными средствами Windows; помимо бэкапа данных Exchange, хотелось также делать и копию System State.

Решение вышло до предела примитивное, но две особенности хотелось бы отметить.

1)
Windows Backup 2008 (см. http://technet.microsoft.com/en-us/library/cc770266(WS.10).aspx ) НЕ умеет бэкапить в сеть при выполнении операции Scheduled Backup (для планирования таких операций в Windows 2008 используется не Windows Task Scheduler, а собственный планировщик утилиты) - поддерживается только бэкап на локально подключенные (в том числе USB) диски. Это новшество (а также захват управления томом, используемым в качестве целевого устройства, и хранение полной резервной копии системы в VHD-формате) введено для оптимизации процесса создания полной
резервной копии и восстановления системы из нее, но в реальной жизни порядком мешает - достаточно посмотреть комментарии "простого народа" к статье по приведенной выше ссылке :|

Обойти данную проблему можно, "обернув" задание бэкапа в вызов из командной строки утилиты Wbadmin, которая имеет несколько иной набор конфигурационных параметров, и может бэкапить в сеть - ну почему нельзя было сделать того же в графической версии, почему? - и уже эту "обертку" запланировать на исполнение с помощью обычного Task Scheduler. А возможность передачи параметров из планировщика в командный файл позволяет организовать одновременное хранение нескольких резервных копий, которые пишутся по дням (нужно просто создать несколько заданий для разного времени, и передавать разные целевые каталоги в качестве параметра). Получается примерно следующее (копируем данные 6 раз в неделю, храним 2 копии с перезаписью каждый второй день):

В планировщике:
по Пн, Ср, Пт запускаем задание "C:\Admin\Scripts\E7KBackup.CMD 135 >> Backup.log"
а по Вт, Чт, Сб запускаем задание "C:\Admin\Scripts\E7KBackup.CMD 246 >> Backup.log"

E7KBackup.CMD - это и есть "обертка" для Wbadmin. Выглядит она так:

@Echo off
Echo "Begin Backup"
Echo "Date:"
date /T
Echo "Time:"
time /T
Echo "Copying to \\ISA\Backup\VSS\%1"
c:\windows\System32\wbadmin.exe start backup -backupTarget:\\BACKUPSERVER\Backup\VSS\%1 -include:E: -vssFull
Echo "Date:"
date /T
Echo "Time:"
time /T
Echo "Finished."


Значащая только одна строка (8-я), остальные введены для создания простого лога, который может отслеживать администратор. Базы данных и журналы транзакций группы хранения в данном случае лежат на диске E: ; параметр -vssFull предписывает полный бэкап VSS с обрезкой журналов транзакций по завершении операции копирования. "\\BACKUPSERVER\Backup\VSS\%1" (целевая папка копирования)разворачивается в

"\\BACKUPSERVER\Backup\VSS\135" и
"\\BACKUPSERVER\Backup\VSS\246" - это пути, по которым хранятся копии, создаваемые по четным и нечетным дням недели.

2)
Бэкап System State из Wbadmin вызывается синтаксисом wbadmin.exe start systemstatebackup, в который можно было бы включить (с помощью ключа -include:E: ) и БД Exchange. Однако на практике совместное (в одном задании) выполнение операций VSS для Exchange writer и многочисленных VSS-writer'ов системы приводило к следующей ошибке Error 9782 от источника MSExchangeIS:



Как ни странно, помогло разнесение бэкапов Exchange и System State по разным заданиям (с небольшим интервалом по времени) с помощью
аналогичной технологии. Обертка для бэкапа System State вышла такая:

@Echo off
Echo "Begin System State Backup"
Echo "Date:"
date /T
Echo "Time:"
time /T
Echo "Copying to \\ISA\Backup\VSS\SS\%1"
c:\windows\System32\wbadmin.exe start systemstatebackup -backupTarget:\\BACKUPSERVER\Backup\VSS\SS\%1 -quiet
Echo "Date:"
date /T
Echo "Time:"
time /T
Echo "Finished."


И последнее замечание: поскольку VSS-бэкап работает только для целого тома, приведенный выше скрипт бэкапа БД Exchange (E7KBackup.CMD) предполагает, что, кроме данных Exchange, на диске E: ничего нет (что и было так). В противном случае использование ключей "-include:E: -vssFull" будет засорять резервную копию посторонней информацией и, возможно, сильно увеличит ее размер.

VSS бэкап Windows Server 2008 Hyper-V из командной строки штатными средствами ОС без использования Windows Backup

Во время очередного внедрения Hyper-V возникла задача регулярного бэкапа работающих виртуальных машин. При этом, промышленного ПО резервного копирования с поддержкой систем виртуализации от Microsoft (Symantec Backup Exec, Microsoft DPM или аналогичного) у заказчика не было - все ресурсы резервировались с помощью различных версий Windows Backup и самописными скриптами. Стандартного ПО управления виртуальными системами Microsoft (System Center Virtual Machine Manager), имеющего интерфейс PowerShell, также не имелось.

Виртуальные машины были запущены круглосуточно, поэтому бэкап простым копированием файлов VM из каталога Hyper-V был невозможен в принципе. В числе виртуальных машин был и контроллер домена (Windows Server 2003), что делало невозможным использование снимков Snapshots для этой системы. Как известно, при восстановлении контроллера домена из снимка Hyper-V возможно явление рассинхронизации USN (USN rollback), для Windows Server 2003 описанное в статье "875495 - How to detect and recover from a USN rollback in Windows Server 2003", http://support.microsoft.com/kb/875495.

Поэтому оптимальным вариантом был бэкап виртуальных машин с помощью Windows Server 2008 VSS из родительского раздела. Windows Server 2008 RTM не имеет VSS-провайдера для Hyper-V, поскольку при выходе Windows 2008 Hyper-V еще не был в релизе; однако, после выхода Hyper-V такой провайдер появился. Это провайдер инсталлируется в систему при установки роли Hyper-V, но после этого он должен еще быть зарегистрирован в системе администратором. Необходимые действия описаны в статье 958662 ("How to back up Hyper-V virtual machines from the parent partition on a Windows Server 2008-based computer by using Windows Server Backup", http://support.microsoft.com/kb/958662. В этой статье имеется ссылка на MSI хотфикс, делающий нужную работу автоматически, и инструкции по правке реестра вручную.

Windows Backup в Windows Server 2008 имеет одну не очень приятную особенность - для выполнения бэкапа VSS она требует, чтобы резервировался весь том, на котором находятся данные, с которых делается снимок. Однако, в данном конкретном случае, на диске с
виртуальными машинами также лежало порядка 400 Гб статических данных, которые резервировались самостоятельно и с другим графиком. Дабы в каждую копию VM не писалось почти лишних полтерабайта, очень хотелось вытащить только требуемые данные, но при этом именно в виде снимка VSS. В результате экспериментов родилась следующая методика.

Windows Server 2008 имеет стандартную утилиту командной строки diskshadow (описана здесь - http://technet.microsoft.com/ru-ru/library/cc772172(WS.10).aspx). Она позволяет создавать VSS-снимки логического тома "на лету" и монтировать их в каталог файловой системы, наподобие точек монтирования томов. Это позволяет нам смонтировать VSS-согласованный снимок тома и скопировать из него только ту часть данных, которая относится к Hyper-V, в согласованном состоянии, НЕ ПРЕРЫВАЯ РАБОТЫ ВИРТУАЛЬНОЙ МАШИНЫ.

Состояние (state) виртуальной машины в данном случае будет то, которое допускается гостевой системой - то есть, гости без установленных компонент интеграции, Windows 2000 и XP на время снятия снимка переводятся в Saved State; кроме того, не допускается использование динамических дисков. В моем случае, резервированию подлежали только машины под Windows Server 2008 и 2003 с установленными IC и фиксированными дисками, так что проблемы это не создало.

Diskshadow имеет скриптовой интерфейс наподобие diskpart, что дает возможность запустить утилиту из командной строки, передав ей текстовый файл со скриптом в качестве параметра. Поскольку VSS-копия создается на время работы скрипта, хорошо бы было прямо из него вызвать необходимые команды для копирования данных в хранилище резервных копий - то есть, рекурсивно вызвать командный интерпретатор. И такая возможность есть - это diskshadow скрипт-команда exec. Подробное описание скриптового языка смотреть в описании команды по приведенной ссылке.

Для работы с хранилищем резервных копий (в моем случае - удаленной папкой в сети) можно использовать любое удобное для этого средство, например всем известную утилиту Robocopy (http://ru.wikipedia.org/wiki/Robocopy).

В результате получается следующее "наколенное" решение по онлайн-бэкапу виртуальных машин:

1) Скрипт "Backup.CMD" - ставится на исполнение в Windows Task Scheduler, учетная запись запуска должна иметь права копирования в целевую папку, так как вся задача запускается в ее контексте безопасности, и запускаться с повышенными привилегиями в локальной системе:

REM Online Hyper-V VM backup
REM Run under native 64-bit environment only
REM Use the diskshadow command to support "live" Hyper-V backup though VSS
REM For recovery, restore backup folder to original location with permissions, then restart "Hyper-V Virtual Machine Management" service on host system
REM For example use Robocopy with /SEC or /COPYALL
diskshadow /s Backup.TXT > Backup.LOG
del /f *.cab


2) Скрипт "Backup.TXT" - исполняется из Diskshadow.exe, передается ей в качестве параметра с ключом /s; наследует контекст безопасности Backup.CMD:

# Буква диска S: и должна быть свободна !!!
delete shadows all
set context persistent
set verbose on
add volume e: alias HVDisk
create
expose %HVDisk% S:
exec Copy_To_Store.CMD
delete shadows all


(в моем случае виртуальные машины находятся в папке E:\VM родительской системы, скрипт экспортирует созданный VSS-интерфейс к диску E: как S:

3) Скрипт "Copy_To_Store.CMD" - вызывается изнутри Diskshadow.exe, выполняет всю логику копирования, которая может быть любой. В моем случае он запускает Robocopy с нужными параметрами:

robocopy S:\VM "z:\Backup\VMBackup" /COPYALL /MIR /NP /XF *.ISO /R:2 /W:5
REM Dummy command to clear the robocopy errorlevel
verify >nul


Вот и все. Перед и после своего исполнения, exec скрипт diskshadow выполняет очистку имеющихся теневых копий, дабы копировалась только необходимая (delete shadows all). Также, на финише выполняется очистка метаданных VSS (в виде файлов CAB).

Лог Backup.log создается для того, чтобы администратор мог отслеживать, что реально происходит в процессе бэкапа. Пример такого лога за один сеанс приведен ниже:

Microsoft DiskShadow, версия 1.0
© Корпорация Майкрософт (Microsoft Corporation), 2007
На компьютере: SERVER0, 18.01.2010 15:29:38

-> # Source is http://serverfault.com/questions/55789/command-line-backup-of-running-hyper-v-images-using-volume-shadow-copies-vss-an
-> # Буква диска S: и должна быть свободна !!!
-> delete shadows all
В системе не найдены теневые копии.
-> set context persistent
-> set verbose on
-> add volume e: alias HVDisk
-> create
Исключение модуля записи "BITS Writer", поскольку исключены все его компоненты.
Исключение модуля записи "Shadow Copy Optimization Writer", поскольку исключены все его компоненты.
Компонент "\Initial Store" модуля записи "Microsoft Hyper-V VSS Writer" исключен из архивации,
так как ему требуется том C:\, отсутствующий в наборе теневых копий.
Компонент "\BCD\BCD" модуля записи "ASR Writer" исключен из архивации,
так как ему требуется том C:\, отсутствующий в наборе теневых копий.
Компонент "\Registry" модуля записи "Registry Writer" исключен из архивации,
так как ему требуется том C:\, отсутствующий в наборе теневых копий.
Компонент "\WMI" модуля записи "WMI Writer" исключен из архивации,
так как ему требуется том C:\, отсутствующий в наборе теневых копий.
Компонент "\COM+ REGDB" модуля записи "COM+ REGDB Writer" исключен из архивации,
так как ему требуется том C:\, отсутствующий в наборе теневых копий.
Модуль записи "ASR Writer" теперь полностью исключен из архивации, поскольку исключен
недоступный для выбора компонент верхнего уровня "\BCD\BCD".
Модуль записи "Registry Writer" теперь полностью исключен из архивации,
поскольку он не содержит компоненты, которые можно включить.
Модуль записи "WMI Writer" теперь полностью исключен из архивации,
поскольку он не содержит компоненты, которые можно включить.
Модуль записи "COM+ REGDB Writer" теперь полностью исключен из архивации,
поскольку он не содержит компоненты, которые можно включить.

* Включение модуля записи "Microsoft Hyper-V VSS Writer":
+ Добавление компонента: \8DA86C8E-0A54-4B5F-9388-8BAB8ED8984C
+ Добавление компонента: \D20DF20A-7C8C-4C09-8D45-EC8108C99A9F

Псевдоним HVDisk для теневой копии с кодом {484f49e3-e1ba-4645-b228-b2c718326a1e} установлен в качестве переменной среды.
Псевдоним VSS_SHADOW_SET для набора теневых копий с кодом {d8f83e24-a6e2-41a7-8564-9abc2e51b892} установлен в качестве переменной среды.
Вставленный файл Manifest.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл BCDocument.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл WM0.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл WM1.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл WM2.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл WM3.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл WM4.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл WM5.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл WM6.xml в CAB-файл 42-18.01.2010-15_--_SERVER0.cab
Вставленный файл DisFBCB.tmp в CAB-файл 42-18.01.2010-15_--_SERVER0.cab

Запрос всех теневых копий с этим кодом набора теневых копий {d8f83e24-a6e2-41a7-8564-9abc2e51b892}

* Код теневой копии = {484f49e3-e1ba-4645-b228-b2c718326a1e} %HVDisk%
- Набор теневых копий: {d8f83e24-a6e2-41a7-8564-9abc2e51b892} %VSS_SHADOW_SET%
- Исходное число теневых копий = 1
- Имя исходного тома: \\?\Volume{3a6faea4-de71-11de-9714-02215ecb8917}\ [E:\]
- Время создания: 18.01.2010 15:30:50
- Имя устройства теневой копии: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
- Исходный компьютер: SERVER0.giproruda.local
- Обслуживающий компьютер: SERVER0.giproruda.local
- Недоступен
- Код поставщика: {b5946137-7b9f-4925-af80-51abd60b20d5}
- Атрибуты: No_Auto_Release Persistent Differential

Количество перечисленных теневых копий: 1
-> expose %HVDisk% S:
-> %HVDisk% = {484f49e3-e1ba-4645-b228-b2c718326a1e}
Теневая копия успешно предоставлена в качестве точки подключения S:\.
-> exec Copy_To_Store.CMD

C:\Admin\Скрипты\VMBackup>robocopy S:\VM "z:\Backup\VMBackup" /COPYALL /MIR /NP /XF *.ISO /R:2 /W:5

-------------------------------------------------------------------------------
ROBOCOPY :: Robust File Copy for Windows
-------------------------------------------------------------------------------

Начало: Mon Jan 18 15:42:48 2010

Источник : S:\VM\
Назначение : z:\Backup\VMBackup\

Файлы: *.*

Исключенные файлы: *.ISO

Параметры: *.* /S /E /COPYALL /PURGE /MIR /NP /R:2 /W:5

------------------------------------------------------------------------------

0 S:\VM\
Новая папка 0 S:\VM\Hyper-V\
Новая папка 0 S:\VM\Hyper-V\SERVER5\
Новая папка 1 S:\VM\Hyper-V\SERVER5\Virtual Machines\
Новый файл 14768 8DA86C8E-0A54-4B5F-9388-8BAB8ED8984C.xml
Новая папка 2 S:\VM\Hyper-V\SERVER5\Virtual Machines\8DA86C8E-0A54-4B5F-9388-8BAB8ED8984C\
Новый файл 2.0 g 8DA86C8E-0A54-4B5F-9388-8BAB8ED8984C.bin
Новый файл 20.0 m 8DA86C8E-0A54-4B5F-9388-8BAB8ED8984C.vsv
Новая папка 1 S:\VM\Hyper-V\Virtual Machines\
Новый файл 14972 D20DF20A-7C8C-4C09-8D45-EC8108C99A9F.xml
Новая папка 2 S:\VM\Hyper-V\Virtual Machines\D20DF20A-7C8C-4C09-8D45-EC8108C99A9F\
Новый файл 2.0 g D20DF20A-7C8C-4C09-8D45-EC8108C99A9F.bin
Новый файл 20.0 m D20DF20A-7C8C-4C09-8D45-EC8108C99A9F.vsv
Новая папка 4 S:\VM\Virtual Hard Disks\
Новый файл 48 desktop.ini
Новый файл 32.0 g SERVER2.VHD
Новый файл 51.0 g SERVER5_C.VHD
Новый файл 10.0 g SERVER5_Y.VHD

------------------------------------------------------------------------------

Всего Скопировано Пропущено Несоответствий Сбоев Дополнительно
Папок: 8 7 1 0 0 0
Файлов: 10 10 0 0 0 0
Байт: 97.039 g 97.039 g 0 0 0 0
Время: 0:40:45 0:40:39 0:00:00 0:00:06

Скорость: 42719893 байт/сек
Скорость: 2444. 451 МБ/мин.

Конец: Mon Jan 18 16:23:34 2010

C:\Admin\Скрипты\VMBackup>REM Dummy command to clear the robocopy errorlevel

C:\Admin\Скрипты\VMBackup>verify 1>nul
-> delete shadows all
Удаление теневой копии {484f49e3-e1ba-4645-b228-b2c718326a1e} на томе \\?\Volume{3a6faea4-de71-11de-9714-02215ecb8917}\ от поставщика {b5946137-7b9f-4925-af80-51abd60b20d5} [Атрибуты: 0x00520009]...

Количество удаленных теневых копий: 1


Лог формируется в кодировке командной строки (MS-DOS).

Идея взята отсюда : http://serverfault.com/questions/55789/command-line-backup-of-running-hyper-v-images-using-volume-shadow-copies-vss-an, и доработана по потребности.

P.S. Для должной регистрации восстановленных VM, проще всего после операции восстановления перезапустить службу "Hyper-V Virtual Machine Management" в родительской системе, в моем случае это было вполне приемлемо. Машины после восстановления будут в остановленном состоянии; последствия запуска в гостевой системе будут подобны запуску после сбоя питания. К сожалению, восстановить машину в запущенном виде с сохранением состояния невозможно, однако в остальном метод вполне рабочий.

Но, конечно, правильнее все таки использовать не Windows Backup, а нормальные средства резервного копирования.

Новый механизм сканирования в Trend Micro OfficeScan 10

Вопросы
Выпустив новую версию своего основного корпоративного антивирусного продукта для защиты конечных точек - OfficeScan (OSCE) 10.0, компания Trend Micro сделала то, о чем говорила уже достаточно давно. Теперь в OfficeScan для антивирусной проверки файлов на защищенной системе можно использовать как традиционный (conventional scan) метод сканирования файлов на основе сигнатур (pattern), так и сканирование "в облаке" - этот новый метод называется smart scan.
Технология Smart Scan, входящая в "облачную" инициативу Trend Micro Smart Protection Network, в контексте файлового антивируса позволяет (теоретически) повысить скорость обнаружения новых вредоносных кодов за счет отказа от фиксированного паттерна, обновляемого с достаточно большой (10-15 часов) задержкой, снизить нагрузку на сетевой сегмент (паттерн не нужно передавать с антивирусного сервера на каждый защищаемый узел), а также оптимизировать использование памяти сканером реального времени (полное содержимое паттерна более не должно распаковываться в оперативную память системы - к примеру, сегодняшняя Windows-версия 6.575.00 основного паттерна Trend Micro имеет размер 33.6 Мбайт в упакованном виде). Каким образом это реализовано?

Как это работает
В инфраструктуре OfficeScan 10, включающей технологию smart scan, появляется еще один, фактически независимый, серверный компонент - Smart Scan Server, представляющий собой сетевой паттерн-сервер, тот самый "облачный" элемент. Клиенты, настроенные на использование smart scan (так называемые smart clients), отправляют на Smart Scan Server сигнатуры анализируемого файла. Сервер анализирует сигнатуры и отправляет клиенту ответ о статусе файла (в простейшем случае вариантов два - заражен или нет, однако нельзя забывать и про эвристику. На самом деле, ответ включает полную информацию о вредоносном коде, а также ActiveAction - что Trend Micro рекомендует с ним делать).

Здесь сразу же возникает масса вопросов. Во-первых - если, к примеру, антивирусный клиент настроен на проверку каждого файла при любом обращении, неужели каждая такая проверка будет порождать отдельный запрос на smart scan сервер? Во-вторых, что именно передается на сервер - уж не проверяемый ли файл целиком (а как иначе его можно проверить на вредоносное содержание) - но если это так, то о какой экономии пропускной способности сети может идти речь? Кроме того, откуда smart scan сервер берет информацию, если сигнатуры не используются?
Что касается последнего вопроса, ответ прост. Паттерн по прежнему используется - чудес не бывает. Это так называемый Smart Scan Server Pattern - обновление, которое smart scan сервер должен загрузить (с сайта Trend Micro ActiveUpdate, с сервера Control Manager организации или откуда-либо еще). Однако, во-первых, он обновляется значительно чаще, чем традиционный (конфигурируемый интервал обновления составляет всего 15 минут), во-вторых, он доступен всем smart-клиентам сразу по загрузке сервером (так как размещен на стороне сервера и не требует полного копирования на клиентскую сторону).
На клиенте работает так называемый smart query filter - "умный" компонент, который определяет, нужно ли в данный момент проверять данный файл (скажем, если паттерн на smart scan сервере не обновлялся, а файл не модифицировался с момента последней проверки - проверка не нужна). Кроме того, используется интеллектуальный проприетарный алгоритм, позволяющий исключить отправку полной копии файла на сервер (выглядит это примерно так - "удаленно определить, есть ли в сигнатурной базе smart scan сервера сигнатура данного файла";). При этом, smart scan паттерн и результаты его работы (на основании уже выполненных запросов) кэшируется (все-таки!) на клиенте на случай, если в какой-то момент он станет автономным, отключившись от сети, и доступа к smart scan серверу не будет.
Для передачи хэшей передаваемых файлов на smart scan сервер клиент использует протокол DNS. В этом ничего нового нет - подобный метод уже использовался ранее в OSCE 8 для запроса репутации посещаемых веб-сайтов в реальном времени (при активном компоненте Web Threat Protection), а в IMSS 7.0 таким же образом (с помощью DNS-запросов) на серверы репутации Trend Micro передавались хэши предполагаемых спам-сообщений (это был один из методов проверки электронных писем в составе Spam Prevention Solution), не говоря уже о "классическом" использовании DNS в Network Reputation Services (выполнение запросов к черным спискам IP-адресов отправителей SMTP как DNS-запросов). Поскольку запросы DNS обычно не блокируются ни для каких конечных клиентов, дополнительных требований по организации сетевого взаимодействия smart-клиента и сервера нет.
Smart Scan сервер может быть запущен на OfficeScan сервере как отдельная служба (в сочетании с традиционным компонентом OfficeScan Master Service) - так называемый integrated-режим. Однако он может быть развернут и автономно (режим standalone), на виртуальном appliance (представляет собой специальную виртуальную машину VMware под управлением CentOS) - это предоставляет дополнительную гибкость при проектировании и сопровождении системы. Smart Scan серверов может быть больше одного (в этом случае клиент в случае недоступности какого-либо из серверов будет перебирать оставшиеся по конфигурируемому списку). Для меняющих расположение (покидающих корпоративную сеть или перемещающихся внутри ее) клиентов список smart scan серверов может быть динамическим (например, привязанным к конкретному сетевому сегменту). Для roaming-клиентов можно использовать Smart Scan серверы, размещенные в облаке общего доступа Trend Micro (наподобие, как roaming-клиенты могли использовать Trend Micro ActiveUpdate без специальной переконфигурации в предыдущих версиях OfficeScan).
Оба метода (conventional scan и smart scan) могут быть использованы параллельно в рамках одной инсталляции. Антивирусный клиент является унифицированным - то есть, один и тот же клиент OSCE 10 может работать и как обычный, и как smart-клиент, без переинсталляции или перезагрузки. Переключение режимов осуществляется в реальном времени, с помощью привычной веб-консоли администрирования сервера OfficeScan.

Выводы и советы
Решение, конечно, смелое и для защиты конечных точек, предлагаемой Trend Micro, концептуально новое. Как и всегда в таких случаях, понятно недоверие заказчиков (особенно в контексте такого "деликатного" вопроса, как антивирусная защита) к подобным инновациям. Уверен, что ни один серьезный системный администратор не бросится внедрять данную технологию во вверенной ему сетевой инфраструктуре, не потратив времени на предварительное исследование вопроса и пилотное тестирование. И это абсолютно правильно. Здесь, пожалуй, можно провести некую аналогию со всем известным антивирусным ПО Microsoft Forefront - я не сомневаюсь ни его действенности, ни в хороших перспективах, но известные лично мне внедрения пока можно пересчитать по пальцам, а ведь продукт существует (под брендом Microsoft) уже почти три года.
В любом случае, в рамках конкретной инфраструктуры, при планировании внедрения технологии Smart Scan нужно начинать с тестирования в пилотной зоне, которая по своему составу должна быть максимальна приближена к "боевой". Причем тестирование должно занимать, думаю, не менее двух месяцев - особенно сейчас, когда технология еще относительно свежая - за меньший период необходимую информацию и статистику использования просто невозможно собрать.
Внедрение также должно быть постепенным. Клиенты могут переключаться из одного режима в другой в любой момент. Smart Scan сервера тоже могут быть добавлены в сеть, когда это потребуется. Кстати говоря, Smart Scan может быть поднят и на conventional-сервере OSCE 10 уже после его развертывания - без переинсталляции, соответствующая процедура называется "Integrated Smart Scan Server Reactivation" и описана в Smart Scan Getting Started Guide на странице 3-25. Документ обязателен к изучению всеми "заинтересованными лицами" и на данный момент доступен по ссылке http://www.trendmicro.com/ftp/documentation/guides/OfficeScan10_PDF_SmartScanGSG.zip .

P.S. 3 ноября 2009 в офисе Поликом Про будет проводится семинар по тематике Trend Micro. Один из докладов будет посвящен как раз новым возможностям продукта OfficeScan 10. Подробности на http://www.polikom.ru/seminar/5493/, милости просим.
Фото:

Опыт решения проблемы нестартующего сервера Oracle IRM License Service в составе системы Oracle IRM под управлением Windows

Проблема возникла в связи с внедрением системы Oracle IRM, а именно компонента License Server версии 10gR3, при использовании в качестве
базы данных бесплатной версии СУБД Oracle 10 - Oracle 10 XE (если можно так выразиться, это аналог SQL Express от Microsoft), на платформе Windows Server 2003 R2 SP2. Заключалась проблема в том, что при старте службы (как при загрузке системы, так и при последующих попытках старта вручную) сервис завершался с ошибкой 7003 (Service-specific error). Какая-либо иная информация в логах ОС не регистрировалась.

Ошибки 7003 service-specific error в ОС Windows обычно специфичны для конкретного приложения, поэтому предварительный поиск по открытым ресурсам каких-либо вразумительных результатов не дал. Однако, изучение статей на Oracle Metalink (теперь My Oracle Support), а именно "451541.1: License server startup procedure" и "451859.1: What is license server error 7003", навело на мысль, что проблема могла заключаться в именно в базе данных, хотя обе службы БД - как слушатель (OracleXETNSListener), так и сама БД (OracleServiceXE), в системе значились как стартовавшие.

При попытке запустить Licensing Service интерактивно (из консоли сервера IRM) служба выдавала следующую ошибку:

SealedMedia Exception
Description: Database Failure
Code: 7003
Comment: The database reported the error '[Oracle][ODBC][Ora]ORA-12514:
TNS:listener does not currently know of service requested in connect descriptor'

Это было уже "теплее", и исследования по данной ошибке явили на свет давно существовавшую проблему, описанную в том числе и в Microsoft Technet Support Knowledge Base, в статье "841180: Oracle database service startup process stops responding", http://support.microsoft.com/kb/841180

Проблема освещалась и независимыми источниками, для примера:
http://entertheit.blogspot.com/2007/09/oracle-service-doesnt-autostart.html
http://ora-12514.ora-code.com/

Суть проблемы сводится к тому, что Oracle Database, начиная еще с версии 8, имеет проблему с инициализацией на ОС Windows Server 2003 и R2 с установленным патчем из бюллетеня MS04-011 и его производными, причем, насколько удалось выяснить, хотфикса, решающего данную проблему, не существует.

Коротко говоря, при этой проблеме БД не запускается и не может корректно обслуживать клиентские запросы, несмотря на успешный с точки зрения Service Control Manager старт обеих служб, пока с достаточными правами (в начальной конфигурации - с правами создателя БД) не будет выполнен инициализационный скрипт самого
Oracle, в случае Oracle XE это "C:\oraclexe\app\oracle\product\10.2.0\server\BIN\StartDB.BAT" (для пути инсталляции по умолчанию).

Таким образом, проблему можно решить, синхронизировав выполнение данного скрипта со стартом системы; однако, при этом, он должен отрабатывать до запуска самого License Server. Последовательность выполнения должна быть такой:

- старт служб Oracle (OracleXETNSListener и OracleServiceXE); старт скрипта StartDB.BAT;
- старт IRM License Server (служба Oracle_Information_Rights_Management_Server).

При этом, службы должны (по крайней мере в конфигурации по умолчанию - которая, кстати, в производственном внедрении не рекомендуется), запускаться из контекста ОС - либо (рекомендуется) из контекста специально назначенной для этого учетной записи службы. В то же время, скрипт StartDB.BAT должен выполняться с правами администратора БД Oracle XE. На платформе Microsoft по умолчанию это пользователь Windows, установивший БД (хотя такая конфигурация опять-таки не рекомендуется, мы рассмотрим именно ее в целях упрощения примера). Попытка же исполнить скрипт из-под NT Authority\SYSTEM просто выдает ошибку вида Oracle ERROR: ORA-01031: insufficient privileges.

Варианты процедуры старта (по крайней мере самые распространенные) могут быть такими:

1. Задача Task Scheduler, запускаемая по событию ОС System Start (будет исполняться с правами заданного в свойствах задания пользователя, он должен дополнительно иметь в системе привилегию "Log On As A Batch Job";

2. Установка дополнительного параметра в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (будет исполняться с правами операционной системы);

3. Создание специального сервиса, синхронизирующего запуск в нужной последовательности,с помощью утилиты Srvany из Windows 2003 Resource Kit. Похожая методика описана в статье Technet "841180: Oracle database service startup process stops responding". использование связки srvany + Instsrv описано в статье Microsoft Technet Knowledge Base "How To Create a User-Defined Service", http://support.microsoft.com/kb/137890 . Мы остановимся именно на этом варианте.

Рабочее решение может быть, к примеру, таким:
- службы OracleXETNSListener, OracleServiceXE, Oracle_Information_Rights_Management_Server переводятся с типа старта Automatic на тип старта Manual (Demand);
- С помощью InstSrv/Srvany создается новая служба OracleStartup,запускаемая с правами, достаточными для запуска StartDB.BAT (в простом случае пользователь, установивший Oracle XE, в реальном случае - специальный пользователь с минимально необходимым набором прав).

Пример пакетного файла для конфигурирования служб:

rem Работает с Oracle XE, для большого Oracle изменить названия служб
"C:\Program Files\Windows Resource Kits\Tools\instsrv.exe" OracleStartup "C:\Program Files\Windows Resource Kits\Tools\SRVAny.exe"
sc config "OracleServiceXE" start= demand
sc config "OracleXETNSListener" start= demand
sc config "Oracle_Information_Rights_Management_Server" start= demand

Параметры новой службы, прописаные в ключе Parameters сервиса, будут такими:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OracleStartup\Parameters]
"Application"="C:\\Admin\\Scripts\\Ora_Start\\ORAStart.CMD"
"AppDirectory"="C:\\Admin\\Scripts\\Ora_Start"

Полностью ставить пакет Windows Server 2003 Resource Kit на сервер нет необходимости, достаточно взять два требуемых файла - Instsrv.exe и Srvany.exe.
Скрипт, синхронизирующий старт License Service (ORAStart.CMD) выглядит следующим образом:

c:
cd C:\oraclexe\app\oracle\product\10.2.0\server\BIN
call C:\oraclexe\app\oracle\product\10.2.0\server\BIN\StartDB.BAT
net start Oracle_Information_Rights_Management_Server

При этом, службы OracleXETNSListener и OracleServiceXE стартуют внутри StartDB.BAT.

Последний момент - в зависимости службы Oracle_Information_Rights_Management_Server (параметр реестра DependOnService) прописывается служба OracleStartup. Этим обеспечивается корректный старт службы License Service в случае необходимости ее ручного перезапуска при работающей системе.

P.S. В процессе тестирования системы Oracle IRM под Windows установлено, что проблема имеет "плавающий" характер (по крайней мере, на виртуальных стендах VMware), и может возникать внезапно и эпизодически. Однако, приведенная методика является универсальной и позволяет гарантированно застраховаться от неприятностей.

Семинар по построению эффективной и безопасной инфраструктуры на базе технологий Oracle