Очень часто люди задают вопросы по поводу безопасности своих локальных машин, терминальных серверов и постоянно ищут средство защиты систем от поражения вирусами, троянами и просто контроля запуска узкого числа инсталлированных приложени. И каждый раз снова и снова приходится отвечать тремя словами на этот вопрос, а именно - Software Restriction Policies. Данная политика совмещает себе как простоту реализации, так и эффективность её работы. В критических случаях пользователю разрешено запускать только те приложения, которые явно разрешил запускать администратор. Данная технология не нова, поэтому подробно расписывать её здесь не буду, а лишь обозначу ключевые отличия реализации данной политики в Windows Vista/Windows Server 2008 от реализации в WindowsXP/Windows Server 2003.

Политика включается как обычно:

• локальная - Start -> Run... -> secpol.msc -> Software Restriction Policies
• доменная - Group Policy Object Editor -> Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies

Итак, какие изменения у нас появились по сравнению с предыдущими версиями:

1. в Security Levels добавился новый уровень безопасности Basic User;
2. в Additional Rules удалены 2 правила по умолчанию, которые разрешают запуск EXE файлов в папках Windows и Windows\System32;
3. при использовании правил Hash Rule теперь вместо MD5 (как в предыдущих версиях) используется более стойкий алгоритм хэширования Sha256, но при этом сохранилась совместимость со старыми клиентами XP/2003 (будет храниться 2 хэша - MD5/Sha1 и Sha256);
4. в Enforcement добавился Enforce/Ignore Certificate Rule;

Казалось бы, пустяк, но я считаю, что тут есть о чём поговорить. Итак, сначала поговорим о новом действии политики как Basic User. Данное действие политики было специально заделано под User Account Control (UAC) и которое совместно с UAC филтрует права пользователя на запуск. Если политики UAC распространяются на все приложения без исключения, то комбинирование действия по умолчанию UAC и при использовании Software Restriction Policies позволяет запретить повышение привелегий для некоторых приложений. Иными словами, даже если запустить приложение с повышенными привилегиями, они всё равно будут отфильтрованы.

Пример 1.

Рассмотрим поведение политики Basic User для установки действия Basic User для программы CMD.EXE:

Сперва при отключенной политике выполню команду, которая включает режим Hibernate для компьютера. Для этого нажимаю на ярлыке CMD правой кнопкой и выбираю Run As Administrator и получаю предупреждение UAC:

соглашаюсь и получаю консоль командной строки, в которой набираю следующую команду и исполняю:

 

данная команда включает режим Hibernate (возможно не самый удачный пример) и ошибок не вернула.

Действие общей политики здесь неважно, поэтому перейдём сразу к Additional Rules. Для этого я создал Hash Rule для CMD.EXE как показано на картинке:

 

Теперь снова запускаю консоль CMD с повышенными привилегиями и повторяю процедуру:

хоть я и просил повышенные привилегия для исполнения команды, но действие Basic User не дало этой возможности и отфильтровало мои права до обычного пользователя. Т.е. мы видим, что Basic User ни за что не позволяет выполнить приложение в привилигированном режиме!

Пример 2.

В предыдущем примере я добровольно пытался запустить приложение с повышенными привилегиями. В результате никакого повышения не получилось и приложение запустилось в обычном режиме. А теперь рассмотрим запуск приложения, которое требует повышенния привилегий через UAC. Для этого я буду использовать запуск консоли Computer Management с возможностью изменения настроек консоли. Я удалил правило для CMD.EXE и создал такое же правило для консоли compmgmt.msc:

И при нажатии правой кнопкой на Computer -> Manage получил запрос на повышение прав от UAC с чем я и согласился:

и снова действие Basic User отфильтровало мои повышенные права и выдало такое окошко. Как видно из скриншота политика блокировала запуск консоли. Ещё раз повторюсь, запуск данной консоли с возможностью изменения настроек без повышения прав через UAC невозможно, что мы и видим на рисунке.

Резюме: Действие политики SRP Basic User не позволяет ни в коем случае выполнить приложение с повышенными привилегиями. Если это доступно, то приложение запускается в обычном режиме, как показано на примере 1 или вообще запрещает запуск, если приложение для запуска требует повышенных прав, как это видно на примере 2.

Примечение: Когда первый раз я стал изучать политику SRP на своём нотебуке с Windows Vista был неприятно удивлён, когда при активации политики Disallowed у меня сохранялась возможность запуска .EXE файлов напрямую из проводника и .LNK из меню Start -> Run... . Я помню по XP/2003, что политика активировалась в момент при выборе действия политики. Здесь же я обнаружил что политика применилась лишь частично, игнорировав .EXE и .LNK файлы. Этим вопросом я озадачил Александра Станкевича, который позднее подсказал, что наблюдал такое же поведение на 2008 сервере до тех пор, пока не перезагрузил компьютер. Поэтому при инициализации политики для её полной активации нужно перезагрузить компьютер! Когда политика проинициализирована перезагрузка больше не требуется до полной отмены политики и все изменения применяются на лету. О чём, кстати сообщается в правом окне политики SRP, когда политика удалена или не создана (эхх, невнимательный какой).

Ну и ещё добавлю небольшую заметку по интеграции политик SRP с UAC. В Enforcement есть опция применения политики SRP For All Users except Administrators, т.е. применение политики ко всем пользователям, кроме администраторов. Данная опция работает только для приложений, которые запущены с повышенными привилегиями. Это вполне логично, т.к. даже локальный администратор работает в системе с правами обычного пользователя (ситуацию, когда UAC отключён совсем я не рассматриваю, ибо это не есть хорошо), поэтому в обычной работе политика в любом случае будет воздействовать на него. Это важно понимать, т.к. не совсем явная вещь и её легко упустить из виду.

Что касается Enforce/Ignore Certificate Rule, то тут наверное нету смысла объяснять, что это. По умолчанию правила сертификатов проверяются в первую очередь и если у вас они не используются, то включение обработки правил сертификатов может значительно снизить скорость запуска приложений.

Порядок (приоритет) применения правил политики SRP:

1. Certificate Rules
2. Hash Rules
3. Path Rules
4. Default Rule

поэтому отключение правил сертификатов, когда они не используются будет весьма кстати. Напомню, что Certificate Rule может использоваться не только для фильтрации подписанных приложений, но и для разрешения запуска подписанных доверенными сертификатами скриптов.

И на последок дам 3 .REG файла, которыми я пользуюсь в работе для управления политикой:

SRP_Enable - включает действие политики в Disallowed:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"DefaultLevel"=dword:00000000

SRP_Disable - включает действие политики в Unrestricted:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"DefaultLevel"=dword:00040000

SRP_Basic - включает действие политики в Basic User:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00020000

Я обычно кладу эти 3 файла (теперь 3, до этого использовались только SRP_Enable и SRP_Disable) в папку Windows и на рабочий стол администраторской учётной записи создаю ярлыки для них:

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

Ну и хочу поделиться маленькой приятной особенностью, которая появилась сейчас. Администраторы, которые работали с политикой SRP в системах XP/2003 испытывали головную боль при обновлении серверов и рабочих станций. Проблема была в самом механизме работы инсталляторов апдейтов, которые в корне произвольного тома создавали папки с произвольными именами, в которые распаковывались апдейты и затем устанавливались. Такая схема не представляла возможным создание правил для SRP, чтобы без отключения политики установить апдейты. Поэтому во время апдейтов приходилось отключать политику и после включать её обратно. В Windows Vista и Windows Server 2008 это уже не так! Я сегодня же проверил возможность установки обновлений с Windows Update при включенной политике SRP Disallowed. И все 16 обновлений спокойно установились и политику отключать не пришлось. Это хороший плюс для Windows Vista!

Вроде осветил основные изменения политик Software Restriction Policies и ничего не забыл. Если забыл что-то, то пните ;)

упс, чуть не забыл, официальную ссылку на TechNet:

Using Software Restriction Policies to Protect Against Unauthorized Software

В продолжении темы создания защищённого соединения посредством IPSec с аутентификацией сертификатами хочется продолжить разговор о реализации сего в условиях рабочей группы. Когда все машины находятся в домене, тогда реализация сильно упрощается. Но если у нас нету домена, либо часть машин находится в домене, а другая часть вне домена. Тем более сейчас современные мобильные телефоны, КПК всё чаще оснащаются L2TP клиентами и которые ну никак не могут быть членами домена. Для выдачи сертификатов таким клиентам стандартное решение не подходит.

Для выдачи сертификатов недоменным клиентам (под управлением любых ОС поддерживающих цифровые сертификаты, как Windows, Linux, Windows Mobile,  Symbian, и т.д.) понадобится Enterprise CA или Standalone CA, который установлен на Windows Server 2003 Enterprise Edition или Datacenter Edition. На Windows Server 2003 Standard/Web Edition данная функция не поддерживается.

Начнём с настройки и запроса сертификатов на сервере, где размещён Certification Authority. Помимо службы Certificate Services должен быть установлен веб-сервер IIS с поддержкой Active Script Pages. Дело в том, что запрос сертификатов для недоменных клиентов через оснастку Certificates не поддерживается, а только через веб-интерфейс CA. Но сначала нужно подготовить темплейт для выдачи сертификатов. Для этого нужно запустить оснастку Certification Authority. В оснастке выделить Certificate Templates, потом в меню Action выбрать Manage. Откроется консоль с доступными шаблонами. Для IPSec нам потребуется шаблон IPSec (Offline Request), который необходимо скопировать (нажать правой кнопкой и Duplicate Template). В открывшемся окне редактирования шаблона нужно сделать следующее:

• во вкладке General указать имя шаблона (например, IPSec non-domain), срок действия сертификатов по этому шаблону
• во вкладке Request Handling выставить чек-бокс напротив Allow private key to be exported и в списке CSPs (список криптопровайдеров) переключить переключатель на Request can use any CSP available on the subject's computer. На усмотрение можно выбрать минимальную длину ключа.

после чего сохранить шаблон. Эту оснастку уже можно закрывать, она больше не понадобится. Теперь можно вернуться обратно в оснастку Certification Authority на позицию Certificate Templates и в Action выбрать New -> Certificate Template to Issue, где в списке выбрать только что созданный шаблон. Теперь нужно выждать время или перезапустить службу Certification Authority (в этой же оснастке), после чего можно приступать к запросу сертификатов. Для доменных компьютеров сертификаты по прежнему запрашиваются как обычно, через оснастку Certificates. Для всех остальных - только через веб-интерфейс. Сконфигурированный по умолчанию веб-интерфейс CA находится по адресу:

http://<servername>/certsrv

и должна открыться стартовая страница веб-страницы Certification Authority:

В этом окне нужно нажать на Request Certificate, после чего в следующем окне нажать на Advanced certificate request. На следующей странице нажать на верхнюю ссылку Create and submit a request to this CA. Откроется страница формирования запроса сертификата.

В списке Certificate Template выбрать нами созданный шаблон (в нашем случае, это IPSec non-domain) и в поле Name ввести FQDN имя компьютера (это имя обязательно должно соответствовать полному имени компьютера), для которого предназначается сертификат и выставить галочку напротив Store certificate in the local computer certificate store, после чего нажать Submit. Далее нужно согласиться с предупреждениями и нажать Intstall this certificate и снова согласиться на предупреждение. Данную процедуру нужно повторить для каждого компьютера, который будет использовать IPSec и цифровые сертификаты. Когда все сертификаты будут запрошены веб-страницу CA можно закрыть.

Если используется Standalone CA, то нужно вернуться в оснастку Certification Authority и в разделе Pending Requests одобрить все запросы на сертификаты. Enterprise CA по умолчанию сам обрабатывает запросы и выдаёт сертификаты. Теперь нужно экспортировать сертификаты на внешний носитель (включая корневой сертификат данного CA). Для этого нужно запустить оснастку Certificates для Computer Account. Все запрошенные и установленные сертификаты хранятся в контейнере Personal. Зайдя в этот контейнер нужно выбрать каждый сертификат и в меню Action выбрать Export. В мастере экспортирования нужно будет только переключить переключатель, что нужно экспортировать и закрытый ключ для сертификата и задать пароль который потребуется при импорте сертификата. Данную процедуру нужно провести для всех сертификатов, которые нужно перенести на другие компьютеры. Когда все сертификаты экспортированы в файлы с расширением *.pfx на носитель или файловый ресурс (это может быть и FTP) нужно так же скопировать корневой сертификат данного CA. Для CA корневой сертификат располагается как правило в корне системного тома. Данный сертификат потребуется всем машинам для установки доверия этому CA и личный сертификат для конкретного компьютера. На этом работа на сервере CA закончена. Можно приступать к импорту сертификатов на клиентские компьютеры. Например, это будет компьютер в рабочей группе под управлением Windows XP Professional (процедура импорта в Windows Server 2003 и Windows Vista будет аналогичной).

Для импорта на сторонний компьютер потребуется 2 сертификата - корневой CA и персональный сертификат для данного компьютера. Для этого нужно запустить оснастку Certificates с указанием Computer Account. После чего выделить контейнер Trusted Root Certification Authorities, и в меню Action нажать Import. В ходе работы мастера импорта корневого сертификата нужно будет указать на сертификат с расширением *.crt и согласиться со всеми предупреждениями. После импорта сертификата список доверенных корневых CA обновится автоматически и там должен появиться CA, который издал компьютерные сертификаты для работы с IPSec. Если всё в порядке, то можно импортировать компьютерный сертификат для данного компьютера. Для этого нужно выделить контейнер Personal и в меню Action нажать Import. В процессе импортирования нужно будет указать *.pfx файл и ввести пароль, который был указан при экспорте сертификата с сервера CA. Следует убедиться, что сертификат импортирован успешно. При двойном клике можно ещё раз проверить параметры сертификата и убедиться, что с ним всё в порядке.

После этого при создании политики IPSec в разделе Authentication Metods следует выбрать Certificates и в списке выбрать CA, чей сертификат был импортирован нами для установки доверия. Дальше уже реализация IPSec и управление сертификатами (в том числе и отзыв) ничем не отличается от порядка, описанного в предыдущей статье.

з.ы.при написании статьи был использован материал How to create offline L2TP/IPSec Certificates, который я немного переработал и упростил (плюс перевод на русский язык :))

Жизнь - штука коварная и достаточно сложная. Постоянно озадачивает чем-нибудь. На сей раз она озадачила вопросом безопасных коммуникаций через интернет и внутри предприятия. Задача звучит донельзя просто - обеспечить безопасную коммуникацию двух некоторых узлов для одного сервиса. В условиях задачи помимо шифрования так же требуется обеспечить взаимную проверку участников обмена данными. Тут за решением далеко ходить не надо - это IPSec. На первый взгляд всё просто, но в процессе реализации пришлось столкнуться с некоторыми не всегда очевидными и интересными моментами.

Итак, имеется домен Active Directory и два узла внутри домена. На узле А размещёна некоторая служба (будь то терминальные службы, будь то незащищённый FTP). Узел Б должен быть единственным узлом, который имеет право доступа к службе на условном сервере. При этом весь трафик данной службы подлежит обязательному шифрованию и проверке целостности/неизменности пакетов во время передачи данных. В первую очередь предстояло подумать на предмет надёжной аутентификации обоих узлов. Если говорить про IPSec, то он предлагает 3 варианта аутентификации:

• Kerberos
• Certificates
• Shared Key

Kerberos в данном случае не поможет, т.к. он позволит аутентифицировать любой компьютер в сети, для которого есть разрешённая учётная запись в Active Directory. Shared Key - просто и гламурно, но не сильно безопасно. Вариант с цифровыми сертификатами в данном случае выглядит более предпочтительным, но и наиболее сложным в плане реализации и поддержке. Для этих целей потребуется развернуть (если его ещё нету) или использовать существующий Enterprise Certification Authority (Enterprise CA). Посредством этого CA необходимо издать для обоих компьютеров сертификат, у которого в поле Purposes указано Server/Client Authentication. Для этого достаточно с каждого компьютера запустить оснастку Certificates для локального компьютера, в меню View выбрать Options и там выставить переключатель в Certificate Purpose. После чего нажать правой кнопкой на Server или Client Authentication (в зависимости от роли компьютера) и выбрать Request New Certificate. В списке доступных шаблонов можно выбрать шаблон IPSec, который идеально подходит для наших целей. Если данный шаблон не предлагается в мастере, то необходимо зайти в оснастку Certification Authority выделить Certificate Templates. Далее Action -> New -> Certificate Template to Issue. Для проверки можно убедиться, что сертификаты выданы можно просмотреть секцию Issued Certificates в оснастке Certification Authority. Напомню, если кто-то не знает, то IPSec может работать только с сертификатами компьютеров, т.к. он работает на сетевом уровне модели OSI, который находится ниже уровня пользователя и приложений. Поэтому работа IPSec для пользователя полностью прозрачна.

Теперь можно приступать к реализации политики IPSec. Для данной статьи для защиты был выбран протокол RDP (вместо него можно использовать любой другой). Для запуска консоли IPSec можно запустить консоль secpol.msc и в самом низу будет IP Security Policies. В правой секции нажимаем правой кнопкой и выбираем создание новой политики. Копками Next-Next проходим создание политики, по ходу заполняя нужные поля. Назовём эту политику Custom. Создавать Default Response Rule не обязательно. После создания новой политики мы получим примерно такое окно:

Как известно, по умлочанию дефолтное правило IPSec - запрещено всё, что не разрешено. Поэтому для начала нужно разрешить протекание всего трафика для компьютера, иначе ничего работать не будет. Поэтому в основном окне политики нажимаем кнопку Add и кнопками Next двигаемся вперёд. В окне Tunnel Endpoint указываем, что данное правило не использует туннель IPSec, далее в списке IP Filter List выбираем уже готовое правило All ICMP Traffic и выбираем для него действие Permit. Ту же самую процедуру проделываем и для правила All IP Traffic (в списке IP Filter List). В результате мы должны получить вот такую картину:

 

если оставить всё как есть, то после применения политики ничего не изменится, т.к. весь трафик разрешён, как IP, так и ICMP. Эту операцию необходимо выполнить на обоих компьютерах-участников защищённого соединения. Теперь нужно создать правило прохождения трафика RDP. Сначала возьмём условный сервер. Возвращаемся к окну редактирования основной политики. Для этого снова нажимаем Add и доходим до окна IP Filter List без изменений. В окне IP Filter List нажимаем кнопку Add. В окне редактора правил вводим созвучное название правилу, например, RDP Server и сбоку ещё раз нажимаем Add. В окне IP Filter Description and Mirrored property убеждаемся, что выставлен чек-бокс напротив Mirrored. Суть этой галочки в том, что она позволяет как получать запрос, так и отправлять ответ используя одно и то же правило. В нашем примере RDP трафик для сервера характеризуется следующими характеристиками:

• Source Address = указать конкретный адрес клиента, которому разрешено (или нужное выбрать из списка)
• Destination Address = My IP Address. Т.к. этот компьютер является сервером, то получать основные запросы будет он.
• Protocol Type = TCP (в списке протоколов есть RDP, но это совсем не то, о чём вы подумали :) )
• Source Port = Any
• Destination Port = по дефолту 3389 для RDP

применяем все изменения и возвращаемся снова в окно IP Filter List, где выбираем новое правило - RDP Server. Переходим кнопкой Next на окно действия фильтра. Можно выбрать Require Security, но для практики мы создадим самое жёсткое действие - HardSecurity, поэтому нажимаем кнопку Add, вводим название, далее шаблон действия - Negotiate Security, следующее окно пропускаем без изменений и доходим до окна IP Traffic Seccurity. Здесь мы можем выбрать режим защиты. Можно выбрать следующее:

• Integrity and Encryption - обеспечивает максимальную защищённость, как шифрование, проверка подлинности, проверка целостности пакетов, проверка очереди отправки пакетов и т.д. Для шифрования будет использоваться метод 3DES (Triple Data Encryption Standart), а целостность и проверка подлинности будет проводиться за счёт алгоритма SHA1 (Secure Hash Algoritm).
• Integrity only - обеспечивает проверку целостности, подлинности, очерёдности следования пакетов. Обеспечивается алгоритмом SHA1
• Custom - можно вручную настроить алгоритмы проверки целостности и подписания пакетов и алгоритмы шифрования.

В условиях статьи использовался Integrity and Encryption. Когда создание действия фильтра сделано, в окне Filter Action (куда мы вернёмся после создания нового действия фильтра) и нажимем Next. Т.к. мы выбрали Negotiate Security (согласование безопасности), то в окне Authentication Metod нужно выбрать метод аутентификации участников соединения. Т.к. мы находимся в домене, где есть Enterprise CA и для компьютеров уже изданы сертификаты, то выбираем метод аутентификации сертификатами. При нажатии кнопки Browse откроется список всех доступных CA, для которых на локальном компьютере есть корневые сертификаты и которым данный компьютер доверяет. Поэтому сертификаты компьютерам может выдавать не только доменный Enterprise CA, но и любой доверенный. Т.к. сертификаты для компьютеров выдал доменный CA, то в списке нужно указать именно его. Если всё сделано правильно, то основное окно политики должно выглядеть примерно так:

Ту же самую процедуру проделываем и на клиенте за одной лишь разницей: при создании нового фильтра в отличии от сервера меняются местами Source Address и Destination Address. Всё остальное делается точно так же. Когда всё будет завершено кнопкой Ok закрываем основное окно редактора политики. Применить политику легко - правой кнопкой на политику и нажать Assign. Следует отметить, что политика применяется мгновенно. Если применить политику только на одном компьютере, то коммуникации по протоколу RDP не произойдёт, поскольку второй участник соединения не будет знать как согласовывать безопасность и его подлинность не удастся проверить. Если теперь применить созданную политику на всех компьютерах-участниках защищённого соединения, то RDP трафик станет шифрованный с проверкой подлинности каждого пакета. Пользователь не будет знать, что RDP трафик защищён, всё будет предельно прозрачно для пользователя.

Теперь можно перейти к насущным вопросам реализации IPSec

Необходимо понимать, что на пути между двумя узлами не должно быть NAT-маршрутизаторов. Дело в том, что NAT изменяет заголовки пакетов, после чего пакеты по мнению IPSec будут считаться повреждёнными и будут дропаться. Для Windows XP SP2, Windows Server 2003, а для Windows 2000 в виде отдельного обновления есть возможность использования NAT-Traversal (NAT-T), который обеспечивает прохождение IPSec трафика через NAT-маршрутизаторы. Подробнее об этом и ограничениях можно почитать тут:

http://support.microsoft.com/kb/818043
http://support.microsoft.com/kb/885407
http://support.microsoft.com/kb/885348
http://support.microsoft.com/kb/926179

И немного о сертификатах

Если сертификат компьютера в CA будет по каким-то причинам отозван, то в теории коммуникация посредством этого сертификата будет невозможно. Но на практике всё не совсем так. Дело в том, что даже если зайти в CA домена и отозвать один из сертификатов, которые были изданы для IPSec (или оба сертификата), то защищённое соединение будет установлено с использованием отозванного сертификата! Как так? Здесь нужно учитывать два момента:

1. если сертификат отозван, то он незамедлительно помещается в список отозванных сертификатов - CRL (Certificate Revocation List). Но компьютеры в сети смогут узнать о том, что сертификат отозван не ранее очередного времени публикации полного списка CRL или DeltaCRL. По умолчанию полный список CRL в Windows Server 2003 публикуется раз в неделю. А Delta CRL - раз в сутки. До времени публикации одного из списков CRL отозванный сертификат можно будет ещё использовать. К слову говоря, Windows 2000 не умеет считывать Delta CRL, поэтому для Windows 2000 можно будет использовать отозванный сертификат только после очередной публикации полного списка CRL (по дефолту может занять до недели). Чтобы принудительно опубликовать список CRL вне расписания нужно зайти в консоль CA и на разделе Revoked Certificates на жать Publish. После чего выбрать какой тип CRL (полный или только дельта) публиковать.
2. особенности проверки компьютерами списков CRL. Вот тут остановлюсь подробнее.

Как работают различные системы со списками CRL при проверке сертификата (адреса, по которым доступны списки CRL публикуются в самом сертификате):

• Windows 2000 - при проверке сертификата по умолчанию НЕ проверяет списки CRL на предмет отозванности сертификата.
• Windows XP/Windows Server 2003/Windows Vista - по умолчанию проверяют списки CRL на предмет отозванности сертификатов. Но, при недоступности этого списка для проверки сертификата руководствуются только содержимым самого сертификата!

Для того, чтобы включить принудительную проверку списков CRL и блокировать использование сертификата при недоступности списка CRL можно пойти двумя путями:

netsh ipsec dynamic set config strongcrlcheck value=2

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

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent\Oakley

необходимо изменить (или создать, если отсутствует) параметр типа DWORD с именем StrongCRLCheck. Значение этого параметра может принимать 3 значения:

• 0 - списки CRL не проверяются. Решение о принятии/отклонении сертификата принимается на основе только самого сертификата.
• 1- списки CRL проверяются. Если же список CRL недоступен, то решение о принятии/отклонении сертификата принимается на основе только самого сертификата.
• 2 - списки CRL проверяются. Если список CRL будет недоступен на момент проверки сертификата - сертификат будет отклонён и признан как недействительный.

Вот, в принципе, и всё, о чём я хотел сегодня рассказать. Может, несколько сумбурно, просто старался акцентировать внимание на наименее очевидные моменты реализации развёртывания IPSec с использованием цифровых сертификатов.

Обозреватель компьютеров – Computer Browsing

Достаточно часто в интернете возникают вопросы и проблемы с отображением компьютеров в сетевом окружении. Как показывает практика, проблема на самом деле возникает не в сетевом окружении, а в том, что многие пользователи не знают или не понимают принцип работы службы обозревателя компьютеров. Хотя в интернете размещено достаточно много хорошего материала по теме обозревателя, но зачастую он непонятен не то, чтобы рядовому пользователю, но и нередко системным администраторам. Так же значительная часть материала написана на английском языке, что для рядовых пользователей может составлять трудность. Служба обозревателя компьютеров используется уже более 10 лет, но вопросы по ней задаются до сих пор. Хочется оговориться, что служба обозревателя и сетевое окружение сейчас является устаревшей моделью доступа в доменной среде Active Directory и Microsoft постепенно отказывается от неё в сторону распределённой файловой системы DFS (Distributed File System). Это оправданное решение, т.к. служба обозревателя генерирует достаточно много широковещательного трафика (в следствии чего падает пропускная способность сети и снижается безопасность сети), имеет множество ограничений и имеет негарантированные (неконтролируемые) моменты в своей работе. В данной статье я постараюсь достаточно доступно и понятно рассмотреть работу службы обозревателя, особенности различных организаций (имплементаций) и связанные с ней проблемы.
Для начала разберём несколько понятий и терминов. Как известно, список компьютеров в сети можно посмотреть заглянув в сетевое окружение (My Network Places). Если всё настроено как надо, то мы видим список компьютеров и можем заходить на любые из них и просматривать расшаренные на них папки и принтеры. Как же организовывается такая схема?

Возьмём некоторую локальную сеть в которой есть один домен широковещания, т.е. один компьютер или узел может найти другого по широковещательному запросу или как его ещё называют - броадкасту (broadcast). Широковещательные запросы свободно проходят через хабы и свитчи и ограничиваются лишь маршрутизаторами, которые не пропускают широковещательные пакеты в другие сети. Если все узлы в сети подключены к свитчу (или свитчам, между которыми на пути нету маршрутизаторов и соединены прямым кабелем), то каждый узел может общаться широковещательными пакетами с любым другим узлом в данной сети. Чаще всего все эти компьютеры будут входить в одну рабочую группу, по умолчанию именуемую Workgroup. В кратце ситуация происходит следующим образом: при запуске компьютеров в сети начинают происходить выборы главного компьютера, который будет отвечать за списки компьютеров в сетевом окружении и которого называют главным обозревателем или мастер-браузером (master browse server). В выборах участвуют только компьютеры с запущенной службой Computer Browser. После выбора мастер-браузера выбираются ноль или больше резервных обозревателей или резервных браузеров (backup browse server), которые будут обслуживать клиентов. Мастер-браузер (здесь и далее термин "браузер" будет использоваться для обозначения главного обозревателя компьютеров или резервного обозревателя). После прохождения всех выборов каждый узел с запущенной службой Server объявляет себя мастер-браузеру, чтобы тот включил его в общий список компьютеров. Когда все узлы объявят себя мастер-браузеру, то тот в свою очередь сформирует список для сетевого окружения. Регулярно, через некоторый интервал времени (от 1 до 12 минут) компьютер обращается к мастер-браузеру за списком резервных обозревателей. Получив его, компьютер произвольно выбирает одного из резервных браузеров и запрашивает уже у него список компьютеров в сети. Если же резервных браузеров нету, то сам мастер-браузер будет обслуживать клиента и передавать ему списки компьютеров. Именно этот список можно видеть в папке My Networks Places. Так всё выглядит в общем случае, но мы сейчас разберём весь механизм работы обозревателя более подробно.

Для корректной работы обозревателя требуется наличие компьютера под управлением Microsoft Windows 9x/3.x for Workgroups (данная статья пишется под среду Windows 2000/XP/2003/Vista) и выше со включенным клиентом Client for Microsoft Networks и включенном транспортном протоколе NetBIOS и запущенной службой Server и Workstation.



Здесь показано и выделено место в свойствах сетевого адаптера, где выставляется параметр Client for Microsoft Networks. В следующем окне показано, как включить NetBIOS over TCP/IP (или как его называют NetBT или совсем просто NBT. Здесь и далее буду использовать сокращения). Как уже сказано выше, в качестве транспорта для трафика сетевого окружения будет использоваться транспорт NetBIOS поверх TCP/IP.

Переключатель должен быть выставлен либо в Default (тогда настройки этого параметра будут регулироваться либо DHCP сервером или явно разрешено при статической адресации), либо явно разрешён, игнорируя настройки DHCP сервера. Далее, на каждом компьютере запускаем службы Server и Workstation (по умочанию они включены). Запустить их можно зайдя в консоль services.msc. Так же в свойствах этих служб следует убедиться, что режим запуска стоит Automatic. Если у вас установлен брандмауэр, то вам необходимо в нём настроить разрешения для NetBIOS трафика. Если используется Windows Firewall (встроенный в ОС Windows XP SP2 и выше), то в нём, во вкладке Exceptions необходимо выставить галочку напротив File and Printer Sharing, как это показано на рисунке:

Если же используется другой брандмауэр, который не поддерживает стандартную опцию исключения NetBIOS, то необходимо открыть следующие входящие порты:
1)137 UDP;
2)138 UDP;
3)139 TCP;
4)445 TCP.

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

• наличие включенного клиента сетей Microsoft (Client For Microsoft Networks) в свойствах сетевой карты;
• наличие включенного NetBIOS over TCP/IP в свойствах TCP/IP протокола;
• созданного исключения в брандмауэре для File and Printer Sharing или ручное конфигурирование входящих и исходящих портов.
• запущенной на всех компьютерах, к или с которых предполагается доступ по сети и сетевое окружение - службы Server и Workstation;

Теперь необходимо выбрать несколько компьютеров на роль кандидата главного обозревателя сети или мастер-браузера. Не вдаваясь в глубокие рассуждения, скажу, что для этих целей не стоит(!) использовать компьютеры у которых активированы несколько сетевых карт, т.е. multihomed компьютер. Тут введу ещё одно понятие:
Сочетание 3-х вещей:

• конкретной сетевой карты;
• конкретного сетевого протокола;
• признака поддержки NetBIOS на этой карте и на этом протоколе.

в терминологии NetBIOS называется LANA ("сетевой адаптер NetBIOS"). Так вот, multihomed компьютер - это компьютер, у которого больше одного LANA. Необходимо избегать работу мастер браузеров, эмуляторов PDC контроллеров домена и серверов WINS на multihomed компьютерах. Дело в том, что такой режим работы может привести к непрогнозируемым и негарантированным результатам работы. О некоторых проблемах multihomed серверов можно узнать здесь:

http://support.microsoft.com/kb/191611/ru
http://support.microsoft.com/kb/188305/ru# (см.вторую часть)
http://support.microsoft.com/kb/181774
http://support.microsoft.com/kb/166159

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

1)мастер-браузер (master browse server) - Как уже говорилось выше, в сети (в логической группе) должен быть один главный обозреватель, который будет собирать списки компьютеров и их расшаренных ресурсов в единый список, который называется список обозревателя (browse list) для всей рабочей группы или домена, если он является так же и доменным обозревателем (о нём написано ниже). Мастер-браузер практически никогда не обслуживает клиентов, за него это делают резервные браузеры. Поэтому мастер-браузер лишь собирает сведения от клиентов и пересылает копию списка обозревателя резервным браузерам, с которыми уже непосредственно контактируют клиенты. Мастер-браузер выбирается в сети посредством выборов. О самом процессе выборов будет написано ниже.

2)доменный мастер-браузер (domain master browse server) – это тот же главный обозреватель сети, но его область действия не ограничивается одной рабочей группой, а всем доменном. Исходя из названия можно предположить, что данный браузер будет доступен только в условиях домена Active Directory. Доменный мастер-браузер имеет право собирать списки компьютеров и расшаренных ресурсов со всех удалённых подсетей (которые находятся за маршрутизатором) в пределах всего домена. Эта роль всегда назначается первому контроллеру домена или контроллеру домена, который держит FSMO роль – эмулятор PDC (PDC Emulator), т.к. только эмулятор PDC имеет некоторые особенные возможности, которыми не обладают другие браузеры. Доменный мастер-браузер выбирается посредством условных выборов и эта роль всегда закрепляется за эмулятором PDC. Почему условно – лишь для соблюдения формальности и избежания ситуации, когда может быть одновременно два доменных мастер-браузера. Как правило доменный обозреватель совмещает и роль мастер-браузера в своей подсети. Так же добавлю, что во всём домене может быть только один контроллер, который держит FSMO роль эмулятора PDC. В случае выключения контроллера домена, который является эмулятором PDC, то в домене не назначаются новые выборы и домен остаётся без доменного мастер-браузера, а только резервные браузеры, которыми как правило становятся дополнительные контроллеры домена.

3)резервный браузер (backup browse server) – это браузер, который проигрывает выборы на роль мастер-браузера. Резервные браузеры периодически (с интервалом от 1 до 12 минут) получают копии списка обозревателя от мастер-браузера и по требованию клиента отправляют ему этот список. Резервные браузеры не составляют сами этот список, а только получают его от главного обозревателя. В случае, если из сети выйдет мастер-браузер или тот перестанет отвечать копиями списка обозревателя резервные браузеры форсируют новые выборы мастер-браузера.

4)потенциальный браузер (potential browser) – это то тот же самый кандидат в мастер-браузеры, за исключением того, что при полном комплекте резервных браузеров (о комплектации сети браузерами будет сказано ниже) он прекращает быть браузером и становится клиентом до первого требования главного обозревателя, когда необходимо повысить свою роль до резервного обозревателя. Роль потенциального браузера можно определять в реестре:

HKLM\System\CurrentControlSet\Services\Browser\Paramters

И там есть ключ MaintainServerList, который может принимать 3 значения:

• No – этот параметр предохраняет компьютер от участия в выборах. Т.е. этот компьютер никогда не станет мастер-браузером или резервным браузером.
• Yes – этот параметр позволяет компьютеру участвовать в выборах и иметь шансы на роль главного обозревателя сети. При подключении этого компьютера к сети он автоматически становится резервным браузером и первым делом попытается связаться с мастер-браузером для получения списка компьютеров. Если мастер-браузер не будет обнаружен, то этот компьютер форсирует выборы мастер-браузера.
• Auto – этот параметр так же позволяет компьютеру участвовать в выборах, но это значение делает его потенциальным обозревателем или потенциальным браузером. При включении потенциального браузера в сеть он в первую очередь пытается связаться с мастер-браузером, чтобы узнать свою роль в сети. Чтобы не заполнять сеть большим числом браузеров есть определённое правило расчёта мастер-браузеров и резервных браузеров по отношению к общему количеству компьютеров в сети. Это правило выписано в примечании. Если сети в результате её расширения (например, компьютеры по очереди подключаются к сети) требуется дополнительный резервный браузер, то мастер-браузер назначает дополнительным резервным браузером компьютер, который является потенциальным браузером. В случае, если необходимости в дополнительном резервном браузере нету, то потенциальный браузер переходит в статус клиента и не обслуживает списки компьютеров. Но по первому требованию мастер-браузера он может взять на себя роль резервного браузера. Если же потенциальный браузер подключается к сети в которой ещё нету мастер-браузера, то потенциальный браузер форсирует новые выборы. Данный параметр реестра не даёт компьютеру никакого преимущества в выборах.

Примечание: Здесь привожу значения, которые регулируют количество браузеров в сети:

• на 1 компьютер – только один мастер-браузер
• от 2 до 31 компьютера – 1 мастер-браузер и 1 резервный браузер
• от 32 до 63 компьютеров – 1 мастер-браузер и 2 резервных.

На каждые последующие 32 компьютера полагается по одному дополнительному резервному браузеру. Дополнительные резервные браузеры назначаются как правило из списка потенциальных браузеров. Так же хочу отметить, что в обычном режиме нет необходимости изменять данный параметр реестра без острой на то необходимости, а оставить всё как есть и использовать данные значения реестра в информативных целях.
5)предпочтительный браузер (preferred master browser) – это специально настроенный кандидат в мастер-браузеры, который всегда выигрывает выборы. Ввиду этого факта, настройку данного типа браузера стоит выполнять только при чётком понимании процесса выборов и когда в этом есть необходимость. Настроить предпочтительного обозревателя можно в реестре:

HKLM\System\CurrentControlSet\Services\Browser\Parameters

В котором надо изменить параметр REG_SZ (а если его нету, то создать) IsDomainMaster и его значение выставить в True. Если же значение отсутствует или выставлено в False, или No, то компьютер такой ролью обладать не будет. К слову, первый контроллер домена в сети или держатель роли эмулятора PDC носит статус предпочтительного браузера. И при наличии в домене нескольких контроллеров, держатель роли эмулятора PDC при любом раскладе выиграет выборы, т.к. только он может быть доменным мастер-браузером.

На заметку: Казалось бы, зачем объявлять новые выборы, если предпочтительный браузер всё равно выиграет их? Дело в том, что в любой момент времени в одной логической сети не может быть больше одного мастер-браузера, поэтому при любых объявлениях выборов текущий мастер-браузер обязан понизить себя до резервного барузера и в этот момент до окончания выборов в сети главного обозревателя не будет. Когда в сети появится предпочтительный обозреватель, то он объявляет себя мастер-браузером и сигналом объявления выборов делает себя единственным мастер-браузером, т.к. по правилам, при получении сигнала о начале выборов текущий мастер-браузер должен понизить свою роль.

Внимание!!! вышеупомянутые параметры реестра не следует изменять без острой необходимости в этом. Изменение данных значений может вызвать конфликты обозревателей в сети и необходимо отслеживать, чтобы в сети было бы не более одного предпочтительного обозревателя.

Следовательно, службу Computer Browser следует включить в режим Automatic только на тех компьютерах, которые должны быть либо главными обозревателями, либо резервными. Выше мы говорили о 5, а не 2-х ролях, но остальные 3 роли являются лишь расширениями основных двух ролей – главного и резервых браузеров. На остальных же компьютерах выставить Manual или Disabled. При запуске компьютеров в сети все компьютеры с запущенной службой Computer Browser приступают к выборам главного обозревателя сети (остальные мирно слушают эфир и ждут окончания выборов). В общем случае выборы назначаются в 3-х случаях:

• когда компьютер не может найти мастер-браузера (если компьютер не получил ни одного ответа от мастер-браузера на 3 подряд запроса);
• когда в сети появляется предпочтительный браузер;
• когда запускается и появляется в сети основной контроллер домена, эмулятор PDC (только в условиях домена).

Первый претендент на роль главного обозревателя или предпочтительный обозреватель отправляет в сеть специальный широковещательный пакет, который извещает остальные компьютеры в сети о начале новых выборов, именуемый как ElectionDatagram, в котором указывает необходимые данные критериев выборов. Так же, при получении этого сообщения мастер-браузер сети (если он есть) обязан себя понизить до резервного браузера. На данный пакет реагируют только те компьютеры, на которых запущена служба Computer Browser и которые являются или могут исполнять роль мастер-браузера, т.е. обозреватели. Клиенты же на этот пакет никак не реагируют.

В качестве критериев определения лучшего используются следующие основные параметры:

1. версия ОС. Более поздняя редакция будет иметь преимущество на выборах, кроме случаев участия в выборах серверных ОС, которые имеют преимущество перед любыми настольными версиями ОС. Так, например, Windows XP будет иметь преимущество перед Windows 2000 Professional, но Windows 2000 Server будет иметь преимущество перед Windows XP;
2. версия протокола выборов. Чем выше версия, тем выше приоритет. Данный параметр не зависит от редакции ОС и является лишь версией протокола выбора браузера;
3. аптайм машины (время бесперебойной работы). Чем выше аптайм, тем выше приоритет при выборах;
4. Является ли данный компьютер держателем FSMO роли эмулятора PDC;
5. Сервер WINS;
6. Является ли этот компьютер предпочтительным обозревателем;
7. Является ли компьютер текущим мастер-браузером;
8. Является ли компьютер текущим бэкап-браузером.

Браузер, получивший данный пакет сравнивает все эти показатели со своими и выясняет, является ли он более лучшим, чем тот компьютер, который отправил этот пакет. Своё мнение компьютер выражает в ответном пакете отправителю.

Более подробно о критериях выборов можно прочитать здесь:

http://www.microsoft.com/technet/prodtechn...i_brs_ECEA.mspx

Если вдруг окажется, что в сети никого нету с запущенной службой Computer Browser и выборы не происходят, либо клиент не может найти ни одного мастер-браузера, то каждый компьютер у которого режим запуска службы Computer Browser стоит Manual форсирует запуск этой службы (что не является гарантированным событием при таких условиях) и объявляет новые выборы мастер-браузера. В таком случае процесс может очень сильно затянуться (вплоть до 72 минут). Но это не гарантирует успешного завершения выборов (при большом количестве кандидатов) и может оказаться, что сетевое окружение в сети не будет работать вообще.

Когда выборы окончены и выбран мастер-браузер (об этом все компьютеры извещаются ширковещательным сообщением с указанием имени победителя) и список компьютеров пуст, мастер-браузер посылает в сеть специальный сигнал, который форсирует клиентов для объявления самих себя мастер-браузеру. Такая же процедура происходит при перезапуске службы Computer Browser на главном обозревателе сети (при перезапуске службы список компьютеров очищается) или при появлении в сети предпочтительного браузера. Эффект появления в сети предпочтительного браузера был описан выше.

Периодически (в произвольный интервал времени от 1 до 12 минут) каждый компьютер объявляет (представляет) себя перед мастер-браузером. Мастер-браузер в свою очередь собирает эти данные в единый список. Проигравшие выборы браузеры автоматически становятся резеврными браузерами (backup browser) и они регулярно получают копию списка сетевого окружения от мастер-браузера. Они же и занимаются обслуживанием конечных клиентов. Например, один из клиентов хочет запросить список компьютеров в сети. Для этого он обращается к мастер-браузеру за списком резервных браузеров. Тот им отвечает списком имён резервных браузеров и клиент произвольно выбирает одного из 3-х (имена остальных двух он записывает в кэш) и уже с ним договаривается о списке компьютеров для публикации в сетевом окружении. Если же в сети нету резервных браузеров, то клиент будет напрямую взаимодействовать с мастер-браузером и уже с него получать списки компьютеров и расшаренных ресурсов.

А теперь рассмотрим более детально как всё будет происходить в реальной сети. В данном случае будет использоваться простая логическая сеть из 5 компьютеров, которые подключены в один свитч или хаб:



Здесь в виде больших компьютеров я показал те компьютеры, на которых была запущена служба Computer Browser, а в виде маленьких – где эта служба не запущена. При включении компьютеров в сеть, компьютер PC1 посылает в сеть сигнал о начале выборов (Election datagram) со своими показателями критериев выборов как это показано на следующем рисунке:


Компьютеры PC2 и PC5 срванивают показатели компьютера PC1 со своими и генерируют ответное сообщение с указанием своего статуса (хуже, или лучше). Если PC1 будет настроен как предпочтительный браузер, то он станет мастер-браузером в любом случае, т.к. этот статус имеет наивысокий приоритет. На картинке изображено, что PC1 выиграл выборы и стал мастер-браузером для сети Workgroup (сбоку пририсована папочка), т.к. он работает под управлением Windows 2000 Server, который имеет приоритет перед Windows XP. И PC1 отправляет в сеть широковещательный пакет с указанием своего имени и имени своей логической группы (логическую группу ещё называют LAN-группой), который называется Workgroup Announcement или Domain Announcement и которым мастер-браузер объявляет себя в сети. После выборов компьютер PC1 отправит в сеть другой запрос на объявления компьютеров специальным широковещательным пакетом RequestAnnouncement. Клиенты (и резервные браузеры) начинают объявлять себя мастер-браузеру (т.е. компьютеру PC1). После того как все компьютеры объявят себя мастер-браузер составит список для сетевого окружения именнуемого списком обозревателя (browse list) и отправит его копию каждому резервному браузеру, т.е. компьютерам PC2 и PC5 в нашем примере. На следующем рисунке эта процедура отмечена стрелочками с цифрой 1.



Теперь клиент захочет посмотреть список компьютеров в сети. Для этого он отправляет в сеть широковещательный запрос GetBackupList [цифра 2 на рисунке] на поиск мастер-браузера и получения списка резервных браузеров, на который мастер-браузер отвечает [3] списком, который будет состоять из PC2 и PC5. Клиент произвольно выбирает себе понравившегося бэкап-браузера и уже у него запрашивает список компьютеров в сети [4]. Резервный браузер отвечает списком [5] и клиент публикует его в окне My Network Places в котором будут отражены компьютеры PC1, PC2, PC3, PC4 и PC5. Если в этом окне зайти на любой компьютер, то клиент уже не будет обращаться к браузеру а будет контактировать напрямую со своим собеседником, которого он хочет посмотреть. Точно так же будет работать и доменная сеть, когда все компьютеры домена находятся в одном сегменте. Можно сразу сказать, что в качестве компьютера PC1 на рисунке будет выступать первый контроллер домена, или другой контроллер, который держит роль эмулятора PDC.

Работа нескольких обозревателей в одном сегменте

Бывают ситуации, когда мы хотим разделить один физический сегмент на несколько логических рабочих групп, например Workgroup и Workgroup1. Как уже сказано выше, при объявлении самого себя мастер-бразуер отправляет в сеть специальный пакет Workgroup Announcement или Domain Announcement (только если компьютер находится в домене), который слушают не только клиенты своей логической группы, но и мастер-браузеры других логических сетей. Когда мастер-браузер другой сети получает такой пакет, то он добавляет в список новую логическую группу и имя главного обозревателя той сети. И если клиент захочет обратиться к компьютеру из другой LAN группы, то он от своего мастер-браузера получает список доступных логических групп в данном сегменте и связанных с ними мастер-браузеров. И клиент просто отправляет в сеть широковещательный пакет GetBrowserList, но с указанием имени конкретной LAN-группы. Тогда мастер-браузер указанной в запросе LAN-группы возвращает клиенту список бэкап-браузеров и вся остальная работа сводится к работе, которая описана в предыдущей главе. Разница лишь в том, что для каждой логической группы избирается свой собственный мастер-браузер. И только мастер-браузер собирает названия других логических групп и имена связанных с ними мастер-браузерами (списки компьютеров других LAN-групп они не собирают, только для своих). Эта информация будет доступна и клиенту. Выглядеть это будет примерно следующим образом:

Здесь мы видим 4 LAN-группы в кружочках (NetworkA, NetworkB, NetworkC и Domain), которые находятся в одном сегменте. Так же я показал имена мастер-браузеров (MasterA, MasterB, MasterC и DC1) для каждой LAN-группы. Так же я показал широковещательные пакеты Workgroup/Domain Announcement, которые принимают и обрабатывают все мастер-браузеры в пределах слышимости широковещательных сообщений (т.е. одного физического сегмента).

В содержании Workgroup Announcement или Domain Announcement включается название LAN-группы, или домена, имя мастер-браузера данной группы и версия ОС, под которой управляется мастер-браузер конкретной группы. Стрелочкой от DC1 к PC2 я показал пересылку копии списка browse list, которую мастер-браузер DC1 отправляет резервному браузеру LAN-группы Domain. В этом списке будет отражено то, что приведено в жёлтом прямоугольнике, а именно – список доступных LAN-групп и имена их мастер-браузеров (эта информация не отображается в сетевом окружении). Этот список будет отражаться в сетевом окружении у пользователя. Когда пользователь зайдёт в одну из них, то сначала он свяжется с мастер-браузером пакетом GetBackupList, чтобы получить список резервных браузеров LAN-группы. А далее – по обычной схеме, выбирает произвольно одного из резервных-браузеров от которого он уже получит список всех компьютеров в логической группе и в той группе, в последующем будет работать с этим резервным браузером.

Предположим, у нас есть два физических сегмента сети, которые соединены между собой посредством маршрутизатора (роутера), как это показано на рисунке:



У нас есть две логические группы (LAN-группы) которые называются Workgroup и MyGroup. Каждая группа находится в своём физическом сегменте и эти сегменты соединены между собой маршрутизатором. Каждая LAN-группа сама по себе будет работать как описано в разделе "Работа обозревателя в одном физическом сегменте" данной статьи. Но как быть, если мы захотим просмотреть список компьютеров группы MyGroup из LAN-группы Workgroup? Как известно, каждый мастер-браузер объявляет себя другим мастер-браузерам в сегменте путём широковещательного сообщения Workgroup Announcement. Но маршрутизатор не пропустит через себя этот пакет в другую сеть (маршрутизаторы не перенаправляют широковещательные сообщения), а значит, мастер-браузер сети Workgroup не узнает, что в сети существует LAN-группа MyGroup и кто в ней является мастер-браузером. К сожалению (а может и к счастью) в условиях рабочей группы нету никакого механизма, чтобы реализовать просмотр списка компьютеров из другого физического сегмента сети.



Допустим, у нас есть два сегмента сети, которые соединены маршрутизатором, но все компьютеры в этих сегментах состоят в одной LAN-группе под названием Workgroup как это изображено на рисунке:

Так же, как и в предыдущем примере мы сталкиваемся с маршрутизатором, который не будет пропускать из одного сегмента сети в другую широковещательные пакеты объявления выборов, объявления мастер-браузеров и т.д. В данном случае схема вырождается в предыдущий пример, т.е. у нас в сети получаются две независмые LAN-группы, в каждой из них будут проходить свои выборы и в каждой сети будет свой мастер-браузер со своим набором резервных браузеров. На компьютерах PC3 и Comp4 будет видна LAN-группа Workgroup, но список будет составлять только компьютеры из своей сети. И левая LAN-группа Workgroup не сможет контактировать через сетевое окружение с правой LAN-группой Workgroup и наоборот. Хотя имена у них будут одинаковые, но никакой взаимосвязи на уровне сетевого окружения у них не будет, т.е. просто две изолированные группы с совпадающим названием как и в предыдущем примере.

Итак, мы узнали, что в среде рабочей группы с маршрутизатором LAN-группы не могут общаться между собой через сетевое окружение, находясь в разных сегментах сети. Если в сети реализован домен, то здесь у нас есть возможность воспользоваться особыми возможностями доменного мастер-браузера, которыми не обладают остальные мастер-браузеры. Но и в домене не всё так просто, как, наверное, хотелось бы. Рассмотрим следующую картинку:

Давайте ещё раз вспомним, как происходит публикация LAN-групп и их мастер-браузеров в сети и вспомним, какие же проблемы у нас возникали при использовании маршрутизатора. В каждом физическом сегменте (SubnetA, SubnetB, SubnetC, SubnetD) объявляются выборы мастер-браузера, которые вне зависимости от реализации имеют одну и ту же схему, поэтому я этот вопрос здесь уже не рассматриваю. После окончания выборов в каждой подсети назначается свой мастер-браузер (MasterA, MasterB, MasterC и DC1). DC1 являясь держателем роли эмулятора PDC становится доменным обозревателем – Domain Master Browse Server. После окончания выборов по закону каждый мастер-браузер должен объявить себя и свою LAN-группу остальным мастер-браузерам широковещательным пакетом Domain Announcement. Т.к. у нас домен, а не рабочая группа, то все компьютеры в домене входят в одну LAN-группу, которая совпадает с именем домена. В нашем примере, домен называется MyDomain. Если посмотреть на наш рисунок, то мы увидим, что этот пакет дойдёт только до маршрутизатора (Router) и его никто в соседних сетях не услышит и никто никогда так и не узнает о существовании, например MasterA в подсети SubnetA, кроме членов этой подсети. NetBIOS обычно разрешает имена тоже путём отправки в сеть широковещательного пакета. Поэтому нужен какой-то дополнительный механизм для объявления мастер-браузеров и разрешения имён (в частности разрешения имени доменного обозревателя). В качестве этого механизма будет выступать система WINS (Windows Internet Name Service).

На заметку: WINS выполняет практически те же функции, что и DNS (Domain Name Service) за той лишь разницей, что DNS разрешает доменные имена компьютеров в IP-адреса, а WINS разрешает NetBIOS-имена в IP-адреса. В начале статьи было сказано, что в качестве транспорта служба сетевого обозревателя (окружения) использует только NetBIOS транспорт. Т.к. DNS не занимается разрешением NetBIOS-имён, то этим будет заниматься именно WINS.

WINS работает по схожей схеме, как и DNS. Он имеет свою таблицу сопоставления NetBIOS-имён компьютеров их IP-адресам. Т.к. в доменных сетях разрешение имён путём широковещания зачастую будет осложнено маршрутизаторами, поэтому на каждом компьютере необходимо прописывать адрес WINS-сервера. Если в сети развёрнут протокол динамической настройки клиентов DHCP (Dynamic Host Configuration Protocol), то сервер DHCP будет сам выдавать клиентам вместе с их IP-адресом и адрес WINS-сервера. При наличии его адреса клиент получает возможность разрешить NetBIOS-имя любого компьютера в домене в его IP-адрес путём простого прямого (не широковещательного) запроса WINS-сервера. Итак, первую проблему – проблему разрешения имён мы решили при помощи внедрения в сеть WINS-сервера (Windows Internet Name Service).

Более подробно о функциях и настройки WINS можно прочитать тут:

http://technet.microsoft.com/en-us/library/bb727015.aspx

Примечание: о порядке и правилах разрешения NetBIOS-имён можно прочитать тут:

http://technet.microsoft.com/en-us/library/bb727005.aspx

Но осталось решить другую проблему – как узнать, кто в сети является доменным обозревателем? Ведь только доменный обозреватель может собирать списки компьютеров со всех подсетей домена в единый список домена, который будет включать все компьютеры домена. Для этой задачи будет также будет задействован сервер WINS. Я уже упоминал об одной особенной возможности доменного мастер-браузера и которой не обладает ни один другой мастер-браузер. Теперь пора раскрыть эту особенность – контроллер домена, держащий роль эмулятора PDC может себя регистрировать на WINS-сервере как доменный мастер-браузер. Остальные же компьютеры (вне зависимости от их роли браузера или клиента) себя регистрируют на WINS-сервере просто как компьютеры. И клиенты могут прямым запросом сервера WINS выяснить имя и IP-адрес доменного обозревателя и уже прямым сообщением (которое маршрутизатор пропустит в другую сеть) объявить себя и свою подсеть доменному мастер-браузеру.


А теперь, используя наши знания, давайте посмотрим, как же будет выглядеть процесс работы сетевого окружения. Предположим, что в WINS уже есть таблица сопоставления NetBIOS-имён всех компьютеров домена. Тогда доменный мастер-браузер регистрирует себя особым образом на WINS-сервере и объявляет себя для всего домена как доменный мастер-браузер. Например в подсети SubnetA закончились выборы и компьютер MasterA стал для этой сети мастер-браузером. Сперва он объявляет себя в своём сегменте и посылает в свою сеть широковещательный запрос RequestAnnouncement, сообщая остальным компьютерам его LAN-группы объявить себя мастер-браузеру. Т.е. по такой же схеме, как и в разделе "Работа обозревателя в одном физическом сегменте". Когда список browse list будет составлен и его копия будет выдана всем резервным обозревателям сегмента, мастер-браузер по закону должен себя объявить перед доменным мастер-браузером. Для этого он сперва пробует широковещательным запросом найти доменного обозревателя. Т.к. у нас стоит маршрутизатор, то этот запрос тихонечко умрёт без ответа. Если ответ не будет получен, то мастер-браузер обратится к серверу WINS с запросом – есть или нету в сети доменный мастер-браузер. Если он есть (контроллер домена включен), то WINS отвечает именем доменного обозревателя (т.е. DC1). Получив имя, мастер-браузер сети SubnetA попытается разрешить имя DC1 в IP-адрес при помощи того же сервера WINS. Получив IP-адрес, мастер-браузер MasterA отправляет прямой (не широковещательный) пакет MasterBrowserAnnouncement доменному обозревателю с указанием своего имени. После чего доменный мастер-браузер запросит копию списка всех компьютеров (browse list) в удалённом сегменте (SubnetA) и по получении этого списка доменный обозреватель его обрабатывает и включает все компьютеры из этой сети в общий доменный список. Доменный список будет содержать одноуровневый список всех компьютеров в домене без их деления по физическому расположению, т.к. все компьютеры являются членами одного домена. После этого, доменный мастер-браузер отправляет мастер-браузеру сети SubnetA свою копию browse list списка, который будет включать все компьютеры в сети, которые подключены к сети и успели себя объявить либо напрямую, либо через промежуточные мастер-браузеры. Такая же процедура будет происходить и в отношении остальных подсетей, которые находятся за маршрутизатором.

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

• отключение от сети обычного клиента (не браузера). Известно, что объявив себя однажды перед мастер-браузером, клиент в процессе обязан периодически (с интервалом от 1 до 12 минут) сообщать о себе (я жив!) мастер-браузеру. Если же клиент 3 раза подряд не объявил себя, то мастер-браузер вычёркивает (удаляет) этот компьютер из списка обозревателя. Ввиду того, что интервал объявления может достигать 12 минут, то существует реальная возможность, что этот компьютер будет фигугрировать еще целых 36 минут в списке обозревателя, хотя его в сети уже давно нету. Участники других сетей могут считать компьютер живым ещё вплоть до 72 минут после выведения компьютера из сети.
• выключение резервного обозревателя. Если резервный обозреватель выключается корректно от сети, то он об этом извещает мастер-браузера, который его сразу же вычёркивает из списка резервных браузеров. В остальном же время фигурирования выключенного резервного браузера от сети будет таким же как и для обычного клиента. Если же резервный браузер внезапно отключился от сети, то первыми его отстутсвие заметят клиенты, которых обслуживал этот браузер. Т.к. по правилам, если резервный браузер не ответил клиенту на 3 подряд запроса, то клиент вычёркивает его из списка и пытается связаться с другим резервным браузером. Временные задержки очистки списка окружения будут такие же, как и в случае клиента, т.е. в своей подсети – до 36 минут, для других подсетей – до 72 минут.
• выключение главного обозревателя. Когда мастер-браузер корректно завершает свою работу, то перед полным уходом в небытие он отправляет в сеть широковещательный пакет ForceElection, который извещает участников сети о внеочередных перевыборах. Если же мастер-браузер выключился внезапно, то первыми могут заметить его отстутвие резервные браузеры, которые получают от него копии списков обозревателя. Если мастер-браузер в течении 12 минут не отправил резервному браузеру копию списка обозревателя, то этот резервный браузер отправит в сеть сигнал о внеочередных перевыборах. Если же в сети не будет ни одного резервного обозревателя, то потенциальные обозреватели, или клиенты, которые способны запустить службу Computer Browser (служба должна быть в режиме запуска Manual). Если же и таких нету, то сетевое окружение станет недоступным.
• Выключение доменного обозревателя. Если выключается от сети (по любой причине) доменный мастер-браузер, то новые выборы не объявляются. Дело в том, что в доменной модели Active Directory может быть несколько или очень много равноправных контроллеров домена. Они равноправны практически во всём, кроме 5 ролей FSMO, одной из которых является роль эмулятора PDC. В любой момент времени во всём домене не может быть больше одного эмулятора PDC. И при отключении его другие контроллеры домена не могут повысить свою роль до эмулятора PDC сами по определённым причинам. Передать роль может только вручную системный администратор домена (и то, только при полной уверенности, что упавший контроллер больше не вернётся к жизни никогда). Если мастер-браузеры не смогут получить копии списка компьютеров всего домена, то мастер-браузеры в каждой подсети удаляют из своих списков компьютеры, которые находятся в других сетях и поддерживают только списки тех компьютеров, которые находятся в их сети. При этом сетевое окружение домена вырождается на несколько (в зависимости от количества подсетей) изолированных рабочих групп, которые друг с другом контактировать не смогут через сетевое окружение, а только напрямую, по известному имени удалённого компьютера.

Внимание!!! Системным администраторам не следует без особой необходимости передавать роль эмулятора PDC (равно как и остальные 4 роли: хозяин схемы, хозяин операций, RID-master и хозяин инфраструктуры) при временном выведении держателя любой из этих ролей. Дело в том, что при захвате этих ролей при помощи утилиты ntdsutil контроллер, который раньше держал любую из этих ролей больше в домен возвращать нельзя, пока с него не будет полностью удалена база Active Directory. Поэтому принудительный захват этих ролей следует проивзодить лишь при полной уверенности, что контроллер, несущий эти роли восстановить не удастся стандартными методами, а только, как минимум полным удалением базы Active Directory или полной переинсталляцией системы. Поэтому, если временно выведен из строя эмулятор PDC не передавайте эту роль другим контроллерам.