Если вы думаете, что вы специалисты по информационным технологиям ведете очень занятую жизнь, то вы ни за что не захотите быть одновременно специалистом по информационным технологиям и автором книг! Сразу же после почти года работы в качестве ведущего автора по Windows Vista Resource Kit, издательство Microsoft Press пригласило меня на работу в качестве автора первой книги об операционной системе Windows Server 2008 (бывшее кодовое название Windows Server «Longhorn»). По прошествии шести безумных недель написания и свыше 2000 писем с обсуждениями с командой разработчиков операционной системы Windows Server, моя книга под названием «Introducing Windows Server 2008» (знакомство с операционной системой Windows Server 2008) наконец закончена и может быть предварительно заказана на Amazon.com. В основном эта книга основывалась на версии -Beta 3 операционной системы Windows Server 2008, но чтобы гарантировать техническую точность RTM, мне помогали почти сто сотрудников из команды разработчиков Windows Server компании Microsoft, которые работали в качестве консультантов и цензоров содержимого книги. Эти эксперты (а именно те, которые занимались непосредственно разработкой операционной системы Windows Server 2008, знают об этом продукте гораздо больше, чем кто либо другой) также добавили тонну полезной информации в виде сносок с пометкой «From The Experts» (от экспертов), в которых приводится подробное техническое описание, как работает операционная система Windows Server 2008, как устанавливать, настраивать, поддерживать и отлаживать различные инструменты и роли.
Ниже приводится содержание различных глав, чтобы вы могли понять, о каких темах будет идти речь в книге:
Ниже приводятся две кратких выдержки из Главы 7, в которой рассказывается о новых возможностях Active Directory в операционной системе Windows Server 2008. В первой выдержке речь пойдет об улучшения в аудите для Active Directory:
Первое улучшение, которое мы рассмотрим, это аудит AD DS auditing. На текущей платформе, Windows Server 2003 R2 (а также в операционной системе Windows Server 2008), вы можете включить глобальную политику аудита (global audit policy) под названием Audit Directory Service Access (аудит доступа к службы директорий) для журнализации событий в журнале Security event log, при выполнении определенных операций над объектами, хранящимися в Active Directory. Подключение журнализации объектов в Active Directory – это процесс, состоящий из двух этапов. Во-первых, вы должны открыть политику по умолчанию для контроллера домена Default Domain Controller Policy в редакторе объектов политик групп Group Policy Object Editor и включить глобальную политику аудита под названием Audit Directory Service Access, которая располагается в Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.
Рисунок 1: Подключение успешного аудита на доступ к службе директорий
Затем, вы должны настроить системный список управления доступом (system access control list или SACL) для объекта или объектов, для которых вам необходим аудит. Например, для того чтобы включить аудит на успешный доступ для аутентифицированных пользователей (Authenticated Users) к объектам пользователей, хранящихся внутри организационной единицы (organizational unit или OU), вы должны сделать следующее:
Рисунок 2: Настройка аудита (продолжение)
Рисунок 3: Настройка аудита (завершение)
Теперь, если вы измените свойство одной из учетных записей пользователя (user account) в вашей организационной единице OU, например, отключите учетную запись, то это событие должно попасть в журнал безопасности Security log с ID события 4662 и пометкой Directory Service Access (доступ к службе директорий), для того чтобы указать, что производился доступ к объекту.
Рисунок 4: Событие в журнале безопасности Security log
Но все это делается в операционной системе Windows Server 2008 аналогично предыдущей версии Windows Server. Новое в операционной системе Windows Server 2008 заключается в том, что в то время, как в на предыдущей платформе Windows Server существовала лишь одна политика аудита (Audit Directory Service Access или аудит доступа к службе директорий), которая контролировала, был ли подключен или отключен аудит службы директорий (directory service), то в операционной системе Windows Server 2008 эта политика разделилась на четыре различных подкатегории:
Одна из этих подкатегорий—Directory Service Changes (изменения в службе директорий)—была улучшена для предоставления возможности аудита следующих изменений в объектах AD DS, SACL которых были настроены для включения объектов для аудита:
Польза от таких изменений должна быть очевидна для администраторов, которые занимаются поддержкой аудита изменений, которые производились для Active Directory, и другими действиями по аудиту, т.к. это очень важная часть общей стратегии подлинности доступа (Identity and Access IDA strategy) для организации. Например, с помощью журнала безопасности (Security log) и фильтра для определенного объекта пользователя, вы теперь можете подробно отследить все изменения в атрибутах этого объекта в течение всего периода жизни объекта. Если вы подключаете аудит для глобальной политики аудита Audit Directory Service Access (а для этой политики подключен аудит внутри политики по умолчанию для контроллеров доменов Default Domain Controllers Policy), то эффектом этого будет также подключение аудита для первой из этих подкатегорий (Directory Service Access или доступ к службе директорий), которая описывалась ранее, которая позволяет фиксировать попытки доступа к объектам. Если вам нужно, то вы можете выборочно включить или отключить аудит отдельно для каждой из этих подкатегорий с помощью Auditpol.exe – инструмента, который работает из командной строки, который входит в состав операционной системы Windows Server 2008. Например, если вы хотите подключить аудит для второй подкатегории (Directory Service Changes изменения в службе директорий), чтобы вы могли увидеть старое и новое значение атрибута объекта, после успешного изменения этого атрибута, то вы должны набрать такую команду auditpol /set /subcategory:“directory service changes” /success:enable в командной строке на вашем контроллере домена (domain controller). Если мы сделаем это в предыдущем сценарии, а затем включим учетную запись пользователя, которую мы перед этим отключили, то в журнале безопасности (Security log) появятся три новых события, касающихся аудита службы директорий.
Рисунок 5: Подробное описание события аудита
Первое (самое раннее) из этих событий имеет ID 4662, и позволяет узнать, что осуществлялся доступ к объекту типа User, в то время, как второе событие (ID 5136) представляет собой старое значения для модифицированного атрибута, а третье событие (также с ID 5136) – это новое значение атрибута. В таблице 7-1 показан список возможный ID событий для событий по аудиту, описывающих изменение службы директорий Directory Service Changes.
| ID события | Значение |
|---|---|
| 5136 | Был изменен атрибут объекта. |
| 5137 | Был создан новый объект. |
| 5138 | Было отменено удаление объекта. |
| 5139 | Объект был перемещен внутри домена. |
Дополнительно, кроме того, что вы можете таким образом отслеживать историю объектов, операционная система Windows Server 2008 также предоставляет вам возможность установки флагов в схеме Active Directory, для указания атрибутов объектов, изменения которых вы хотите отслеживать, а также атрибутов, для которых вы не хотите отслеживать изменения атрибутов. Это может быть очень полезно, т.к. отслеживание всех изменений в объектах, может приводить к слишком быстрому разрастанию и переполнению журнала безопасности (Security log).
—
Вторая краткая выдержка из моей книги – это сноска «From The Experts», в которой обсуждаются некоторые дополнительные проблемы, связанные с использованием серверов DNS с Read-Only Domain Controllers (RODC или контроллеры домена только для чтения) (RODC – это еще одно новая возможность Active Directory, которая появилась в операционной системе Windows Server 2008). С помощью этой сноски вы можете почувствовать технический уровень:
При установке контроллеров домена только для чтения Read Only Domain Controller (RODC) для сайтов дочерних офисов в операционной системе Windows Server 2008 с помощью мастера по установке Active Directory Installation Wizard или инструмента, работающего из командной строки, под названием DCPromo, вы должны указать домен DNS domain для домена Active Directory, к которому вы подключаете RODC в процессе установки. Во время этого процесса, вы должны указать параметры установки сервера DNS Server. Сервер DNS Server необходим для обнаружения контроллеров домена (domain controller) и других компьютеров, которые являются членами домена Active Directory, как на стороне хаба, так и на стороне дочернего офиса. По умолчанию, сервер DNS Server устанавливается локально на RODC, который копирует существующую зону AD для указанного домена, и добавляет локальный IP адрес в список DNS Server контроллеров домена локального клиента DNS.
В качестве лучшей рекомендации, компания Microsoft советует, чтобы на клиентских компьютерах по умолчанию было включено динамическое обновление Dynamic DNS update, и чтобы сервера DHCP Servers использовались для настройки списка сервера DNS Server. Аналогично, на стороне дочернего офиса, клиенты должны быть настроены на использование динамических обновлений Dynamic DNS update, и вы должны задать основной сервер Primary DNS Server или использовать DHCP для задания списка сервера DNS Server для направления клиентов на DNS Server, запущенный на RODC.
Если в дочернем офисе работает лишь один сервер DNS Server и RODC, то компания, Microsoft рекомендует, чтобы компьютеры клиентов также указывали на сервер DNS Server, работающие на контроллере домена на стороне хаба. Это можно сделать либо с помощью настройки клиентов на альтернативный Alternate DNS Server для сервера DNS на стороне хаба, либо настроить сервера DHCP Servers на задание списка сервера DNS Server на первом локальном сервере DNS Server, а затем на удаленном сервере DNS Server на стороне хаба. Сервер DNS Server на RODC должен быть первым сервером DNS Server в списке, чтобы достичь максимальной производительности для клиентов дочернего офиса.
В сценариях с крупными дочерними офисами, если настраивать два или более RODC, вы можете воспользоваться настройкой по умолчанию и установить сервер DNS Server локально на всех RODC. С той же самой стороны, RODC не будут дублироваться друг с другом. RODC в основном полагаются на репликацию с контроллерами доменов на стороне хаба в время запланированных интервалов для обновления локальных данных в директории. Поэтому, DNS Server в дочернем офисе на RODC передает обновленные данные DNS zone data в процессе обычного цикла репликации с контроллера домена на стороне хаба, подключенного к локальному RODC.
Дополнительно, к репликации со стороны хаба, сервера DNS Server на RODC также пытаются копировать локальные данные после получения запроса клиента на обновление (client update request). Сервер DNS Server дочернего офиса, направляет клиента на сервер DNS Server на стороне хаба на контроллер домена (domain controller), который открыт для записи, и который может произвести обновление. Сразу после этого, он пытается связаться с контроллером домена на стороне хаба для обновления его локальной копии данных в соответствии с измененной записью. Все другие сервера DNS дочернего офиса на RODC не пытаются получить локальную копию одной изменой записи, т.к. они не получали оригинальный запрос клиента на обновление (client update request). Этот механизм имеет преимущество, согласно которому обновленная клиентская запись может быть быстро обнаружена в дочернем офисе, без необходимости отправки частых и больших запросов на репликацию за всеми данными в домене со стороны хаба. Если потеряно соединение с сетью, или контроллером домена на стороне хаба, то можно доставить обновленную запись на сервер DNS Server в дочернем офисе, эта запись будет доступна локально лишь после следующей запланированной репликации со стороны контроллеров домена на стороне хаба, и она будет доступна для всех RODC в дочернем офисе.
Из последовательности попыток сервера DNS Server скопировать отдельные записи между циклами репликаций, если данные DNS zone data хранятся на нескольких RODC, локальные записи дочерних офисов могут накапливать некоторые несоответствия. Чтобы гарантировать высокий уровень устойчивости для данных DNS, рекомендуется настроить все клиентские компьютеры в дочернем офисе для работы с одним списком серверов DNS Server—например, с помощью DHCP.
Если в более редких случаях, когда своевременное обнаружение локальный клиентских записей в дочерних офисах абсолютно критично, чтобы избежать любых несостыковок, вы можете установить сервера DNS на всех RODC, но указать для всех клиентов единственный сервер DNS Server.
www.windowsnetworking.com
Tags: dns, domain, nat, replication, Windows Vista