Главная Security, Windows, Без рубрики, Новое Group Policy, Security
  • Хранение учетных данных в скриптах и групповых политиках на примере задачи по смене пароля локального администратора

    Введение

    clip_image001С точки зрения безопасности пароль локального администратора должен соответствовать следующим требованиям:

    · быть известным только ограниченному кругу лиц;

    · обладать достаточной сложностью;

    · регулярно изменяться.

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

    1) при помощи стартап-скриптов;

    2) используя предпочтения групповых политик;

    3) запуском скрипта на выделенном компьютере.

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

    Стартап-скрипты

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

    Для решения применим скрипт, позаимствованный с блога «Hey, Scripting Guy!», и немного отредактируем его. В итоге получится что-то вроде:

    strComputer = “.”

    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator,user”)

    objUser.SetPassword “12345-as” ‘

    objUser.SetInfo

    Сам скрипт не идеален. Например, в него можно добавить:

    1) привязку к SID встроенного администратора (это необходимо если учётная запись была переименована);

    2) логирование в журнале событий системы;

    3) отправку оповещений об ошибках выполнения по электронной почте.

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

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

    1) создать групповую политику;

    2) добавить туда наш скрипт в качестве стартап-скрипта (более подробно об этом написано в KB198642);

    3) прикрепить групповую политику к контейнеру с компьютерами, на которых должен изменяться пароль.

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

    Кодирование

    Для решения данной проблемы мы можем воспользоваться утилитой Script Encoder от компании Microsoft. Эта утилита позволяет преобразовать vbs-скрипт в формат vbe. В результате, тело скрипта хранится в закодированном виде и это никак не сказывается на возможности его исполнения. Рассмотрим это более подробно на нашем примере:

    1) Скачиваем установочный файл с сайта Microsoft.

    2) Распаковываем его.

    3) В результате получаем несколько файлов. Один из них – нужная нам утилита screnc.exe. Синтаксис использования следующий:

    SRCENC [switches] inputfile outputfile.

    Здесь inputfile – исходный vbs-скрипт, outputfile – его зашифрованный аналог, [switches] – необязательные параметры, которые нам не понадобятся.

    4) В итоге тело скрипта будет иметь вид:

    «#@~^mQAAAA==dDD/K:aEYD,xPrRE@#@&?nO,W4Ni/DP{~!+Dr(LnmOcrrxgP)JzE~LP/O.;Whw!OD~LPrzb9:bUkkY.lDW.S!/+ME#@#@&W(%i/Dc?nYKCk/AWM[PrF+fW*OCdrPv@#@&G(Lik+MR?Y&U0K@#@&Ly4AAA==^#~@»

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

    Декодирование

    Казалось бы теперь учетные данные защищены и системный администратора может спать спокойно. Однако существуют vbs-скрипты, с помощью которых можно легко раскодировать зашифрованный вариант. Пример такого скрипта можно получить по следующему адресу: http://www.interclasse.com/scripts/decovbe.php.

    Для его использования, скопируем код в файл decode.vbs и запустим его из командной строки. В качестве аргумента будет путь и имя закодированного vbe-файла:

    decode.vbs output.vbe

    В результате выполнения должно появиться окно, содержащее текст исходного vbs-скрипта. Как следствие учетные данные администратора опять могут стать известны потенциальному злоумышленнику.

    Альтернативные варианты

    Рассмотрим альтернативные способы решения задачи передачи учетных данных на рабочие станции. К таковым можно отнести:

    1) Group Policy Preferences;

    2) централизованное изменение пароля со стороны сервера;

    3) усложнение структуры скрипта и ограничение доступа к нему.

    Group Policy Preferences (GPP)

    Предпочтения групповых политик это своего рода замена скриптам в групповых политиках. Данная технология активно рекламируется Microsoft и действительно значительно упрощает работу системного администратора. Изменение пароля локального администратора при помощи GPP довольно подробно описано в статье: «Change local administrator passwords with Group Policy Preferences». Ключевая мысль этой статьи: «Не рекомендуется изменять пароли локального администратора и сервисных учетных записей при помощи GPP». Связано это с тем, что ни смотря на то, что пароль администратора хранится в зашифрованном виде, для его получения достаточно 256bit AES ключа находящегося на рабочей станции. Таким образом, этот способ также не является безопасным.

    Централизованное изменение пароля

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

    «How Can I Change a User’s Password?». Предложенный там скрипт:

    Set objOU = GetObject(“LDAP://OU=Finance, DC=fabrikam, DC=com”)

    objOU.Filter = Array(“Computer”)

    For Each objItem in objOU

    strComputer = objItem.CN

    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)

    objUser.SetPassword(“i5A2sj*!”)

    Next

    берет информацию о компьютерах из контейнера Active Directory и поочередно подключаясь к каждому из них меняет пароль администратора. Из минусов такого варианта можно отметить:

    · необходимость удаленного подключения к компьютерам (а они не всегда могут быть доступны);

    · организацию автоматического запуска скрипта по расписанию.

    Усложнение структуры скрипта

    Достаточно много вариантов с применением скриптов изложено в обсуждение «Смена пароля локального администратора» на форумах Microsoft Technet. Особенно интересен вариант с веб-сервером. При его использовании компьютер во время загрузке обращается к серверу, на котором выполняется скрипт по изменению пароля локального администратора. Таким образом этот способ удачно сочетает в себе двух других вариантов, основанных на использовании startup-скриптов и централизованной смены пароля.

    Заключение

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

    Ссылки:

    · Script Encoder;

    · Passwords in Group Policy Preferences;

    · Change local administrator passwords with Group Policy Preferences;

    · How Can I Change a User’s Password? ;

    · Форумы Technet: Смена пароля локального администратора.

  • Главная Windows, Без рубрики, Новое Active Directory, Group Policy
    • Group Policy: Основы. Часть 1

      logo_thumb

      В процессе заслуженного отдыха я успел набросать слайды  нового доклада  для проекта Techdays. Буквально пару слов о Techdays, это платформа на основе которой люди бесплатно делятся знаниями в самой удобной из доступных  дистанционных форм – в форме вебкаста. Мой Доклад посвящен основам групповых политик. В нем раскрываются базовые теоретические понятия, необходимые для управления компьютерами в домене Active Directory и основные практические приемы. Ориентирован на людей не работавших до этого с групповыми политиками, либо имеющих пробелы в знаниях по данному вопросу.

    • Главная System Center, Без рубрики, Новое Group Policy, SCMDM 2008
      • Создание шаблона ADM для работы с Windows Mobile

        gpoiconMicrosoft System Center Mobile Device Manager предлагает достаточно много разных и интересных «фич», к которым относятся распространение ПО при помощи механизма WSUS, использование VPN–соединения на базе IPSec, управление устройствами при помощи групповых политик. Однако набор политик, входящий в состав SCMDM, не всегда покрывает все потребности администраторов и тогда перед ними возникает задача по созданию собственного шаблона (либо нескольких шаблонов). И именно об этом творческом процессе я хочу рассказать в этой статье. При этом статья будет поделена на две части – немного общей теории групповых политик и групповые политики применительно к Windows Mobile.

      • Главная Windows, Без рубрики, Новое Active Directory, Group Policy, Windows 2008 R2, Windows Server 2008
        • Репликация Active Directory: Разговор на «Ты»

          logoОдна из главных рекомендаций Microsoft касательно Active Directory Domain Services (ADDS) говорит о необходимости развертывания в производственной среде минимум двух контроллеров домена. Реальная же жизнь показывает, что в средних и крупных компаниях количество контроллеров может достигать нескольких десятков и даже сотен. Когда системный администратор начинает работать в крупной сети на базе ADDS одной из самых важных забот становится репликация Active Directory.

           

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

          Впервые появившись в Windows Server 2000 технология Active Directory (это прежде всего транзакционная база данных содержащая информацию об объектах вашей сети и глубоко интегрированная с системой безопасности Windows) более чем за 9 лет претерпела некоторые изменения, но даже в Windows Server 2008 R2 работает на хорошо зарекомендовавшем себя движке Extensible Storage Engine ( ESE ). Если верить расчетам масштабируемости, данного решения должно хватить даже сетям с несколькими миллионами объектов, а вырасти база, может до 16 террабайт. Сердцем Active Directory является файл NTDS.DIT в котором, собственно говоря, вся информация и хранится. При добавлении второго и последующих контроллеров домена происходит создание копии данного файла, и размещение ее на введенном в строй новом контроллере. Т.е можно сделать четкий вывод: каждый контроллер домена хранит свою версию файла NTDS.DIT.

          Важно понимать, что при открытии оснастки для работы с Active Directory, а это может быть Active Directory Пользователи и Компьютеры или как вариант Active Directory Сайты и Сервисы, вы всегда подключаетесь к конкретному контроллеру домена и при желании можете выбрать с каким контроллером работать – это означает, что выработаете с конкретной версией базы данных, которая в данный момент может отличаться от других копий. Естественно создавая учетную запись либо меняя конфигурацию, изменения вносятся только в один файл NTDS.DIT, который находится на контроллере, куда подключена оснастка (или любой другой инструмент управления). После внесения изменений критически важно оповестить другие контроллеры об изменениях и новых данных и как можно скорее произвести синхронизацию. В Active Directory этот процесс синхронизации называется репликацией и в дальнейшем я буду использовать именно этот термин. Особенно важно помнить эти факты, когда вы занимаетесь решением проблем с репликацией Active Directory и вносите изменения в контекст конфигурации AD. Это происходит тоже на конкретном контроллере и с конкретным файлом NTDS.DIT.

          Физически NTDS.DIT это просто один файл, но логически он состоит из нескольких разделов (иногда их называют контекстами именования или контекстами репликации), каждый из которых содержит определенную информацию и реплицируется по-своему.

          Раздел «Schema» – хранит в себе схему ActiveDirectory, которая описывает, какие объекты могут быть созданы, и что они из себя будут представлять. Меняется реже всего, как правило, при переходе контроллеров на новую операционную систему либо при установке в организации почтовой системы Exchange. Процесс изменения базы данных в контексте схемы чаще всего называют расширением схемы и это не случайно, т.к. отменить эти изменения (например, удалить созданные в этом контексте объекты) невозможно. Репликация раздела осуществляется на все контроллеры домена в лесу Active Directory. Единственный раздел, чья репликация не является мультимастерной. Репликация раздела «Schema» всегда односторонняя и выполняется от контроллера домена, владеющего ролью FSMO Хозяин Схемы, на все оставшиеся контроллеры домена. (Впоследствии оставшиеся контроллеры домена реплицируют информацию своим репликационным партнерам, но источником обновления в  этой цепочке репликации всегда будет Хозяин схемы)

          image

          Рис. 1 Разделы базы Active Directory

          Раздел «Configuration» – содержит информацию о конфигурации Active Directory, в частности описывает, какие и сколько доменов создано, как они между собой связанны, сколько существует сайтов, какие сервисы доступны в организации и просто системные настройки службы каталогов такие как квоты, политики LDAP-запросов, правила неточного поиска, разрешения имен объектов и т.п.. Раздел реплицируется между всеми контроллерами доменов в лесу и может быть изменен на любом контроллере домена. Изменения данного раздела связаны с конфигурированием и настройкой самой Active Directory.

          Раздел «Domain» – или доменный. Все учетные записи пользователей, группы безопасности, организационные подразделения, объекты компьютеров и принтеров создаются и хранятся в данном разделе. Реплицируется раздел только между контролерами домена в том домене к которому принадлежит контроллер. Получается, что в организациях, имеющих несколько доменов, в каждом домене будет свой раздел «Domain».

          Разделы «Application» – опциональные разделы. Зона репликации зависит от настройки. Как правило, создается два Application раздела, это ForestDNSZones и DomainDNSZones.

          · ForestDNSZones – хранит SRV и CNAME записи для Леса AD и реплицируется на все контроллеры домена в лесу, являющиеся DNS серверами.

          · DomainDNSZones – содержит DNS записи для зоны домена. Реплицируется на все контроллеры домена с установленным на них DNS сервером.

          Посмотреть на каждый раздел каталога и данные в нем хранящиеся можно через утилиты ADSI Edit AdExplorer и LDP.exe. Утилиту (AdExplorer) можно скачать с сайта Microsoft, она входит в комплект утилит Sysinternals. А LDP.exe становится доступна после установки на контроллер домена Windows Support Tools. Следует отметить, что данный комплект не потерял своей актуальности и после выхода Windows Server 2008.

          image

          Рис. 2 Выбор раздела для подключения в утилите LDP.exe

          Теперь важно уяснить следующее, когда клиент аутентифицируется на контроллере домена, и применяются групповые политики, образуется трафик (85 Кб на вход станции в домен (с Default Domain Policy) и 75Кб на вход пользователя (тоже с Default Domain Policy)). Более того репликация изменений между контроллерами доменов порождает свой репликационный трафик. Этим трафиком нужно управлять, представьте себе, что организация и естественно ваш домен Active Directory располагается в двух городах связанных WAN каналом и однажды все пользователи филиала в Ростове-на-Дону начнут обращаться к контроллеру, расположенному в центральном Московском офисе. А контроллеры домена начнут реплицировать информацию в любое время и по первому желанию. Минимум с чем Вам придется столкнуться это высокая утилизация WAN канала и медленный вход пользователей в домен.

          Поэтому в Active Directory введено понятие Сайтов. Сайт это логическое объединение контроллеров домена и клиентов для управления служебным трафиком службы каталогов. Если ваш Лес Active Directory не распространяется за пределы одного сегмента локальной сети, следовательно, вы работаете с односайтовой структурой. Именно она является дефолтной и именно с неё мы начнем разговор.

          При создании Active Directory и поднятии (имеется ввиду процедура dcpromo) первого контроллера домена формируется сайт по-умолчанию с именем «Default-First-Site-Namе». Если не создавать дополнительных сайтов и придерживаться односайтовой структуры, все новые контроллеры будут попадать в данных сайт. После появления второго и последующих контроллеров должны образоваться Репликационные связи (connection objects), указывающие на то какой контроллер и откуда должен реплицировать изменения. Посмотреть эти связи можно через оснастку «Active Directory Сайты и Службы».

          На Рис.3 открыта оснастка «ActiveDirectoryСайты и Службы» и по имеющейся информации можно сказать, что в данном примере имеется единственный сайт по-умолчанию, в котором находится два контроллера домена Server1 и Server2. А так же, что Server1 имеет партнера по репликации Server2 и реплицирует с него изменения. Без наличия данных связей репликации между контроллерами работать не будет.

          Нередки случаи когда системные администраторы, установив новый контроллер домена, не находят у него данных связей и начинают создавать их руками. Это распространенная ошибка. За создание связей, базируясь на определенной логике, отвечает служба KCC (Knowledge Consistency Checker). Созданию связей самостоятельно чревато возникновением ошибок и дальнейшей путаницей. Для тех же, кто не хочет ждать, пока KCC справится с задачей, существует способ ее поторопить.

          image

          Рис. 3 Свойства Репликационной связи.

          Для этого необходимо использовать утилиту Repadmin с ключом kcc. Синтаксис будет выглядеть следующим образом:

          repadmin /kcc server1.itband.ru (Вместо server1.itband.ru вы укажете FQDN вашего сервера)

          Если нужно запустить генерацию связей на всех контроллерах домена в сайте, то команда Repadmin принимает вид:

          repadmin /kccsite: «Default-First-Site-Name» (Если имя сайта было изменено «Default-First-Site-Name» заменяется реальны именем)

          Можно так же запустить процесс генерации топологии на всех контроллерах леса командой repadmin /kcc *. Большинство опций команды repadmin поддерживают ключ /async, который дает задание контроллеру домена и при этом не ожидает его завершения.

          Без административного вмешательства служба KCC стартует на каждом контроллере домена раз в 15 минут и в случае необходимости добавляет или удаляет лишние репликационные связи (учтите, что связи, созданные вручную, не управляются KCC). Логика создания связей в рамках одного сайта кажется довольно простой, каждый контроллер не реплицируется с каждым, служба KCC всегда пытается создать кольцо репликации, причем по мере добавления новых контроллеров кольцо будет расширяться. Расширение не бесконечно, при создании связей существует «правило трех прыжков». Это значит, что между двумя контроллерами домена при репликации не может быть больше трех посредников.

          image

          Рис. 4 Принцип создание связей репликации службой KCC

          Как только число контроллеров достигнет 8 штук, правило «трех прыжков» приведет к тому, что служба KCC выполнит «ход конем» и добавит дополнительные прямые связи, тем самым сокращая расстояние между двумя любыми контроллерами до допустимого значения «максимум в три прыжка». Данная ситуация хорошо проиллюстрирована на рисунке 4. Создание связей между контроллерами расположенными в разных сайтах выполняется с учетом топологии сайтов, сайт-линков и мостов между сайт-линками. Подробнее о построении межсайтовой репликации читайте в разделе «межсайтовая репликация». Следует отметить, что кольцо при построении топологии репликации строиться независимо для каждого контекста репликации (раздела Active Directory) далее эти кольца накладываются друг на друга и выясняется, где можно вместо нескольких репликационных связей – обойтись одной.

          Внутрисайтовая репликация начинается, когда в Active Directory происходит изменение, это может быть изменение атрибута или создание учетной записи. Контроллер домена, в базе которого произошли изменения, ожидает 15 секунд, а затем отправляет ближайшему партнеру репликации уведомление о том, что на нем произошло какое-то обновление. При наличии двух и более партнеров по репликации, последующие уведомления отправляются каждому партнеру с 3-секундной задержкой (Верно для уровня леса Windows 2003 и выше, для Windows 2000 первичная задержка составляет 300 секунд, а последующие 45 секунд). После получения уведомления об изменении партнер репликации проверяет возможность репликации и список обновлений и выполняет процесс репликации с тем контроллером, который прислал уведомление. Трех секундная задержка предотвращает чрезмерную загрузку из-за одновременных запросов обновлений от множества партнеров по репликации. Периоды нотификаций можно настроить командой repadmin /notifyopt.

          Следует обратить особое внимание читателей, что процесс репликации ВСЕГДА происходит в режиме pull, т.е. «стягивания» изменений и новых объектов, но не в режиме push. Это связано с тем, что только контроллер хозяин файла NTDS.DIT имеет право в нем что-то изменять и отвечает за целостность своей БД. Из этого так же следует, что ВСЕ линки репликации которые, создаются в ручную или службой KCC имеют однонаправленную природу, т.е. логически обозначают входящий поток репликационной информации.

          Некоторые изменения реплицируются без 15-секундной задержки. Такая репликация, называемая срочной (urgent replication). В события ее вызывающие входят блокировки учетных записей, изменение пароля учетной записи. В официальных документах присутствует путаница. По сути это не репликация вовсе и механизм передачи этих изменений в коре отличается от процесса репликации. Хотя в качестве транспорта используется тоже протокол RPC. Такая репликация выполняется не обычным механизмом репликации, а специальными вызовами RPC. По сути это запросы аналогичные изменению объектов через ADSI. В зависимости от режима работы леса список событий может меняться.

          Если внимательно присмотреться к свойствам репликационной связи, то можно найти расписание репликации, по умолчанию оно установлено на ежечасный запуск. Возникает вопрос: Зачем еще одно расписание если есть система уведомлений?

          image

          Рис. 5 Расписание репликации

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

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

          repadmin /replicate server2.itband.ru server1. itband.ru dc=itband,dc=ru

          С ключем /replicate необходимо задать куда (server2.itband.ru ) и с какого контроллера (server1.itband.ru ) должны реплицироваться данные, а также какой раздел каталога нужно реплицировать (dc=itband,dc=ru).

          Запустить репликацию всех разделов Active Directory в рамках всего леса (в рамках существующей топологии) довольно легко, для это следует выполнить: Repadmin /syncall /AeS. Учтите, что в крупных сетях такой запуск репликации может вызвать серьезный поток трафика, который пойдет не только по скоростным каналам.

          Алгоритм распространения изменений

          Теперь необходимо разобраться, как после получения репликационного уведомления от партнера контроллер домена решит: Есть или нет изменения необходимые для репликации ? Если есть то, какие объекты или их отдельные атрибуты должны быть прореплицированы. Алгоритм выглядит следующим образом.

          Любой контроллер домена ведет некий счетчик называемый «highestCommittedUSN», который увеличивается на единицу при любом атомарном изменении базы Active Directory. При этом у каждого контроллера домена этот счетчик свой и между контроллерами его значения не совпадают. Например, в 9 утра значение «highestCommittedUSN» у контроллера DC1 было равно 14879, а в 6 вечера 14896. Это значит, что за прошедшее время в базе этого контроллера произошло 17 изменений. Посмотреть значение «highestCommittedUSN» можно с помощью утилиты ldp просто подключившись к нужному контроллеру домена. При подключении выводиться состояние динамического системного объекта RootDSE, среди атрибутов которого как раз и присутствует «highestCommittedUSN».

          image

          Рис. 6 Просмотр значения «highestCommittedUSN» на контроллере домена.

          После проведенной репликации каждый контроллер домена кэширует значения «highestCommittedUSN» своих репликационных партнеров. И когда в последствии контроллер домена DC1 получит уведомление от контроллера DC2 в нем будет информация о текущем «highestCommittedUSN» DC2. Контроллеру DC1 останется только сравнить текущий «highestCommittedUSN» с тем, который он закэшировал во время прошлой репликации. Если он вырос : значит в базе DC2 произошли изменения и необходимо произвести репликацию. Если остался прежним, то в ней нет необходимости.

          Таблица, в которой хранится информация о «highestCommittedUSN» репликационных партнеров называется вектором обновления или «up-to-date vector». Посмотреть ее можно с помощью утилиты repadmin.

          repadmin /showutdvec dc1 dc=lab,dc=itband,dc=ru

          Default-First-Site-Name\DC2 @ USN 16667 @ Time 2009-09-21 01:24:15

          Default-First-Site-Name\DC1 @ USN 20704 @ Time 2009-09-21 01:31:25

          В данном примере результатом будет вывод значений «highestCommittedUSN» репликационных партнеров DC1 (а также актуальный USN его самого), при этом это будут значения, о которых DC1 знает, в действительности уже они могли вырасти по причине внесения изменения в базу на тех контроллерах. Следует помнить, что «highestCommittedUSN» увеличивается как после изменений внесенных в базу непосредственно на контроллере, так и после изменений прореплицированных с других контроллеров.

          image

          Рис. 7 Просмотр вектора обновлений на контроллере DC1.

          Есть одно но, сам по себе «up-to-date vector» отвечает на вопрос «Были ли изменения?». Этого недостаточно, необходимо вычислить что изменилось. Давайте рассмотрим данный механизм на примере.

          В нашей сети находится два синхронизированных контроллера домена (DC1и DC2 ). До изменений «highestCommittedUSN» у DC1 равен 20902, а у DC2 16940. На контроллере DC1 создается учетная запись пользователя Федя Рашпин. После создания учетной записи «highestCommittedUSN» на DC1 стал показывать 20909. Это говорит о том, что было произведено 7 изменений. Напоминаю, что считаются атомарные изменения, т.е создание учетной записи можно разложить на само создание плюс изменение ряда атрибутов, которые выполняет оснастка Active Directory Users and Computers.

          Если подключиться через LDP.exe к нашему объекту пользователь, то можно увидеть два атрибута uSNCreated и uSNChanged.

           

          image

          Рис. 8 Просмотр атрибутов uSNCreated и uSNChanged для учетной записи.

          uSNCreated будет говорить, какой «highestCommittedUSN» был в момент создания объекта на данном контроллере, а uSNChanged в момент последнего изменения. Получается, что первый показатель (uSNCreated) будет оставаться неизменным, а второй в свою очередь (uSNChanged) по мере обновлений объекта будет расти. Важно понимать, что uSNCreated и uSNChanged на каждом контроллере домена у объекта будут свои.

          Посмотрим на пользователя Федя через утилиту repadmin. Для получения служебной информации, используемой при репликации задействуем ключ /showmeta.

          repadmin /showmeta “CN=Федя Рашпин,OU=testou,DC=lab,DC=itband,DC=ru”

          При этом нас интересует информация с каждого контроллера. Но начнем с DC1.

          image

          Рис. 9 Вывод метаданных о созданном пользователе на DC1.

          Какую же информацию нам дает repadmin (Рис. 9). Данный список не что иное, как объект пользователя, разложенный по атрибутам.

          По каждому атрибуту можно увидеть:

          · Loc.USN это «highestCommittedUSN» контроллера DC1 в момент внесения последних изменений.

          · Originating DC говорит о том, на каком контроллере были произведены последние действия с этим атрибутом, т.е откуда пошло распространение.

          · Org.Usn это «highestCommittedUSN» контроллера автора изменений в момент внесения последних.

          · Ver – версия атрибута, растет на единицу при каждом его изменении (локально или в результате репликации).

          · Attribute – непосредственно название самого атрибута.

          Взглянув на эту таблицу можно сделать вывод, что пользователь «Федя Рашпин» был создан (или изменен) на контроллере домена DC1, при этом увидеть, что «highestCommittedUSN» DC1 в процессе создания учетной записи рос от 20904 до 20909. (Org.USN)

          Совпадение колонок Loc.USN и Org.USN говорит о том, что запуск repadmin /showmeta произведен на контроллере домена, который был автором изменений. Если выполнить тоже самое на втором контроллере, результат будет несколько другой.

          image

          Рис. 10 Вывод метаданных о созданном пользователе на DC2.

          На DC2 четко просматривается, что автором всех изменений (кроме одного) был DC1 и его «highestCommittedUSN» (Org.Usn) в момент изменения каждого атрибута. А также «highestCommittedUSN» в момент внесения обновлений в базу контроллера DC2. (Loc.USN)

          А вот теперь пора сделать небольшой вывод:

          Когда контроллер домена рассылает репликационным партнерам уведомления об обновлении базы, он сообщает свой текущий «highestCommittedUSN». Партнер, получивший это уведомление, сравнивает этот «highestCommittedUSN» с тем, что он запомнил с прошлой процедуры репликации. Если он вырос, значит необходимо запускать репликацию. Например: DC2 получил от DC1 уведомление и текущий «highestCommittedUSN» равный 20912, он сравнивает с известным ему значением 20850. Делает вывод о необходимости репликации и запрашивает изменения, произошедшие в период роста «highestCommittedUSN» с 20850 до 20912.

          DC1 осуществляет выборку из своей базы. Для этого просматривается Loc.USN и те атрибуты, которые менялись в заданном диапазоне «highestCommittedUSN» реплицируются на DC2.

          Решение конфликтов

          Не исключена ситуация когда один и тот же атрибут будет меняться одновременно на двух и более контроллерах домена. Как быть в такой ситуации. Существует строгий механизм разрешения конфликтов.

          Правило первое: Можно было заметить в метаданных репликации параметр Ver. Как уже было сказано, он увеличивается на единицу каждый раз при изменении атрибута. Если сразу на двух контроллерах происходит изменение атрибута, в первую очередь будет произведено сравнение номера версии. Атрибут, имеющий более высокий номер версии, является приоритетным. И именно его значение будет использоваться.

          Правило второе: Если номер версии совпадает, учитывается время изменения атрибута. Значение, установленное по времени последним выигрывает. В гипотетической ситуации, когда изменения атрибута на разных контролерах имеют один номер версии, да и сделаны в одно время победит тот контроллер, который имеет больший номер GUID. Возможно несколько любопытных ситуаций. Один администратор решает удалить пустое организационное подразделение, другой же на соседнем контроллере в это время создает учетную запись. Получается явный конфликт интересов.

          В такой ситуации будет задействован скрытый контейнер LostAndFound, получить доступ, к которому можно только переключив оснастку «Active Directory – пользователи и компьютеры» в расширенный режим.

          image

          Рис. 11 Контейнер LostAndFound.

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

          Другой вид разногласий может возникнуть в случае одновременного создания объектов с одинаковыми именами, это может быть организационное подразделение или учетная запись пользователя. В такой ситуации принцип довольно простой, объект, созданный первым, переименовывается, точнее к его имени добавляется objectGUID. Если необходимость в этом объекте впоследствии сохранится, ничто не мешает администратору дать ему новое имя.

          image

          Рис. 12 Автоматическое разрешение конфликта

          Большим преимуществом с точки зрения репликации является переход на режим работы домена Windows Server 2003 и более поздние. В них изменилась процедура репликации атрибутов типа «linked-valued» (пример «Членство в группах»). При добавлении разных пользователей на разных контроллерах в одну и туже группу результатом будет членство всхе добавленных пользователей в составе этой группы. В случае с Windows 2000 состав группы при таком конфликте определялся бы по ее членству на том контроллере, на котором изменения в группе были бы сделаны позже по времени.

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

           

          Илья Рудь

          Константин Леонтьев

          http://kleontiv.spaces.live.com/

          Статья опубликована в журнале “Системный администратор” от 01.2010

        • Главная Windows, Новое Active Directory, Group Policy
          • Использование в работе «GP Preferences»

            • Рубрика: Windows,Новое
            • Автор: Илья Рудь
            • Дата: Wednesday 01 Apr 2009

            sec21 На современном этапе у компании Microsoft есть продукты и технологии, которые становятся козырной картой в игре за внимание пользователей и администраторов. Одним из «джокеров» является технология групповых политик, позволяющая достаточно просто и эффективно управлять тысячами windows-компьютеров. Корпорация Microsoft это прекрасно понимает и с каждой версией новой операционной системы увеличивает количество параметров доступных для конфигурирования через GP. (Давайте сразу договоримся, групповые политики или Group Policy здесь и дальше по тексту просто GP).

            Если в Windows 2003 SP1 мы могли настроить через GP порядка 1800 параметров, то в Windows Vista и Windows Server 2008 это количество выросло до 2500. С использованием групповых политик в среде, построенной на Windows 2003 и Windows XP, можно было сделать много, но не все. Часть задач перекладывалась на скрипты, которые можно было создавать самому и применять вместе с GP.

            Скрипты это конечно здорово, но есть одна проблема, далеко не все умеют их писать. А поскольку «свято место пусто не бывает» на рынке появились компании, которые предлагали свои разработки позволяющие расширить стандартные групповые политики. Одной из таких компаний была «Desktop Standard». Видимо их разработка показалась софтверному гиганту достаточно интересной, поскольку в 2006-м году по старой корпоративной традиции компания была куплена Microsoft . С точки зрения ИТ-администраторов данное поглощение однозначно прошло со знаком «+». То, что стоило отдельных денег, теперь является частью доменной сети под управлением Windows Server 2008 и не требует дополнительного лицензирования.

            В данной статье я буду рассказывать об изменениях в групповых политиках, которые произошли после выхода Windows Server 2008 с акцентом на «GP Preferences». Ну а теперь обо всем по порядку.

            Как было в Windows Server 2003.

            Для начала я предлагаю освежить в памяти групповые политики в классическом виде, т.е так как они выглядят в Windows Server 2003. При создании объекта групповой политики мы могли воздействовать на компьютеры или пользователей несколькими способами:

            1. Сценарии – синий блок на рисунке 1. Сценарии давали возможность выполнить скрипты, написанные на Visual Basic Scripting Edition (VBS-файлы) и JScript (JS-файлы). При этом данные скрипты могли применяться в четырех случаях: при загрузке, при входе пользователя в систему, при выходе пользователя из системы, при выключении компьютера.

            2. Установка программ – красный блок на рисунке 1. Компонент «Установка программ» позволял развертывать программное обеспечение из msi-файлов и в ряде ситуации отойти от ручной установки программ.

            3. Параметры безопасности – оранжевый блок на рисунке 1. Параметры безопасности содержали целый ряд настроек безопасности компьютера. Список достаточно большой, могу привести примеры того что мы могли сделать: настроить NTFS права на файлы и папки, разрешить или запретить выключение питания компьютера, регулировать запуск служб, контролировать принадлежность пользователяк группам безопасности и многое другое.

            4. Административные шаблоны – черный блок на рисунке 1. Непосредственная настройка самой операционной системы и ее компонентов ложилась на административные шаблоны. Фактически они являлись текстовыми файлами, в которых было прописано, какие параметры реестра должны быть применены на клиенте. Сразу после установки мы уже имели пять различных шаблонов, каждый из которых отвечал за свои параметры. Например, шаблон «Inetres.adm» позволял конфигурировать параметры обозревателя Internet Explorer.

            image

            Рис. 1 Объект групповой политики Windows Server 2003

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

            Как стало в Windows 2008.

            В принципе данная логика остается и в Windows Server 2008, за одним исключением, при создании объекта групповой политики в Windows Server 2008 у вас появляется новый блок, в русских версиях ОС он звучит как «Настройка». (Рис.2).

            Собственно говоря, это и есть решение бывшей «Desktop Standard» интегрированное в новой серверной операционной системе. Данный блок «Настройка» предназначен для расширенного администрирования компьютеров без использования скриптов.

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

            image

            Рис.2 Новый блок при создании GP (англ. – GP Preferences)

            Для начала давайте ответим на вопрос: В какие моменты происходит применение групповых политик?

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

            Примечание: 90 минут является значением по-умолчанию для параметра фонового применения GP, значение этого параметр можно менять.

            Применение нового блока (давайте называть его GP Preferences) осуществляется точно также.

            Разница заключается в следующем. Если GP применяется каждый раз в вышеописанных ситуациях и при изменении параметров на клиентском компьютере приводит все в соответствии с политикой, то параметры «GP Preferences» можно настроить на выполнение как постоянно, так и только один раз.

            Простой пример: вы меняете параметр через GP, пока политика применена этот параметр проверяется каждый раз при загрузке и входе. Если вдруг пользователь поменял этот параметр после входа на компьютер, то через 90 минут действия пользователя будут затерты, и параметр будет иметь значение в соответствии с политикой. Если вдруг вы отключите политику, параметр вернется на то значение, которое он имел По-умолчанию.

            А вот при передаче параметра через «GP Preferences» у вас есть выбор либо применять этот параметр каждый раз, т.е будет действовать классическая схема «принуждения» описанная выше, либо применить его один раз. Соответственно при однократном применении пользователь получит результат, но сможет его поменять и измененное значение останется,

            т.к повторного применения не будет. Плюс к этому отключение политики, где настроены «GP Preferences» не приведет к возвращению на параметры По-умолчанию.

            Не стоит забывать, что «GP Preferences» делятся на часть, которая применяется к пользователям и часть, которая применяется к компьютерам. Т.е здесь все, как и у классических политик. Рис.3

            image

            image

            Рис.3 Часть «GP Preferences» применяемая для объектов компьютер (слева) и часть, применяемая для объектов пользователь. (справа)

            Следующей особенностью является ориентация нового блока «GP Preferences» на выполнения действия, то, что изначально делалось только скриптами: создать папку, создать ярлык, открыть общий доступ к папке, создать локального пользователя и тому подобное.

            Попробуем в «GP Preferences» в деле.

            Я предлагаю для лучшего понимания данной темы, решить практическую задачу с использованием «GP Preferences».

            Вводная информация для задачи такая:

            На сервере «Win2008-DC», который является контроллером домена, есть папка с общим доступом «Intro Docs», в этой папки находятся документы, которые должны прочитать сотрудники в первый рабочий день. Нужно, чтобы при первом входе на компьютер, у нового сотрудника на диск «C:» была скопирована данная папка, на рабочий стол пользователя добавлен к ней ярлык. После ознакомления сотрудник должен иметь возможность удалить и папку и ярлык. Вот и все. Может быть данная ситуация не совсем логична с жизненной точки зрения, но для проверки работы «GP Preferences» этого будет достаточно.

            Прежде чем приступить к выполнению задачи, давайте уясним одну вещь. С помощью «GP Preferences» можно управлять следующими операционными системами:

            · Windows XP with SP2

            · Windows Vista

            · Windows Server 2003 with SP1

            · Windows Server 2008

            И на каждой из управляемых систем (кроме Windows Server 2008) нужно установить клиентскую часть «Group Policy preferences clientside extension» или сокращенно CSE. Для всех из данного списка операционных систем доступна своя версия CSE. Скачать CSE можно с сайта Microsoft

            Важно: Пока CSE не установлены на управляемом компьютере параметры «GP Preferences» применяться не будут.

            Итак, переходим к выполнению задачи:

            1. В первую очередь я скачал CSE для Windows Vista и установил на все компьютеры.

            2. После этого на сервере «Win2008-DC» создал папку «Intro Docs» , открыл к ней общий доступ и наполнил документами.

            3. Поскольку «GP Preferences» являются частью объекта групповой политики, нам будет необходимо создать и применить такой объект. В моем тестовом домене создано организационное подразделение «Moscow», в которое вложены два других организационных подразделения. «Computer» – где хранятся объекты компьютеров и «User» с объектами пользователей. (Рис.4)

            image

            Рис.4 Структура организационных подразделений.

            4. Используя оснастку «Управление групповой политикой» я создаю объект групповой политики и связываю его с организационным подразделением Moscow.

            Назову его «TEST GP Pref». Политика создана, остается ее настроить. (Рис.5)

            image

            Рис.5 Создание GPO

            5. Открываем «TEST GP Pref» для редактирования и перед нами встает вопрос: «Какую часть GP Preferences редактировать? Для пользователя или для компьютера». Я считаю, что в нашей ситуации будет правильно редактировать «Конфигурацию пользователя». В зависимости от того что мы выберем наша политика будет действовать по-разному. Если применим настройки в «Конфигурации пользователя», то на первый же компьютер, на который зайдет пользователь, будет скопирована папка «Intro Docs» и создан ярлык. В последующие заходы данного пользователя на этот или другие компьютеры ничего создаваться не будет. Если применим настройки в «Конфигурации компьютера» то при первой загрузке будет создана папка «Intro Docs» и ярлык и абсолютно не важно, будет ли кто на него входить или нет. Я надеюсь, разницу вы поняли.

            image

            Рис.6 Редактирование GPO

            6. Разворачиваем «Конфигурацию пользователя – Настройка – Конфигурация Windows –Файлы». Щелкаем правой кнопкой мыши на пустом месте и выбираем «Создать» – «Файл». Сейчас перед нами стоит задача настроить копирование папки «Intro Docs» на клиента при первом его входе. Для этого в появившемся окне выбираем действие «Создать» (Рис.7) , в поле «Исходные файлы» вводим путь к папке на сервере, по окончанию пути ставим звездочку, это говорит о том, что из папки нужно копировать все файлы. В поле пути конечной папки указываем, в какой папке на клиенте должны появиться эти файлы. Если папка в момент применения политики не существует – она будет создана! Обратите внимание, что я при указании конечной папки использовал переменную %SystemDrive% которая означает что папка должна находиться в корне на системном диске, т.е на диске где стоит Windows. Если вы не помните, какие переменные используются в Windows, достаточно поставить курсор в поле ввода и нажать клавишу «F3» , перед вами появится окно с переменными, где можно будет выбрать нужную. (Рис.8) Указывая переменные вместо жесткого указания пути, (т.е C:\Intro Docs) вы страхуете себя от нештатных ситуаций. (Например, отсутствие раздела с буквой C:)

            image

            Рис.7 Создание действия в «GP Preferences»

            Но это еще не все, нам необходимо убедиться, что данное действие будет осуществлено только единожды для каждого пользователя. Поэтому переходим на закладку «Общие параметры» (Рис.9) и ставим галочку напротив настройки «Применить один раз и не применять повторно» и нажимаем «Ок»

            Что произойдет в результате применения данной настройки?

            При первом входе пользователя на компьютер будет проверено, существует ли на системном диске папка «Intro Docs», если ее нет, она будет создана и после чего в нее будут скопированы файлы с общей папки по адресу «\\Win2008-DC\Intro Docs\». После применения политики и создания файлов и папки, пользователь сможет сделать с ней все что угодно в рамках данных ему прав, повторно папка создаваться не будет.

            image

            Рис.8 Меню с переменными.

            image

            Рис.9 Настройка закладки общие параметры.

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

            image

            Рис. 10 Создание ярлыка.

            В поле «Имя» вводим имя нашего ярлыка, в типе объекта оставляем «Объект файловой системы», в «Размещении» – указываем «Рабочий стол». Но если хотите, чтобы ярлык появился в каком-то другом месте, можете поэкспериментировать.

            «Конечный путь» – путь, к которому будет вести наш ярлык. Прописываем здесь %SystemDrive%\Intro Docs, т.е ярлык будет указывать на папку «Intro Docs» на системном диске клиента.

            В поле «Путь к значку файла» можете нажать на троеточие «» и выбрать иконку для вашего ярлыка. После чего нажимаем «Ок»

            Задача выполнена. Остается обновить политику на клиенте и проверить появление ярлыка на рабочем столе и папки Intro Docs на системном диске клиента.

            На что еще следует обратить внимание при создании действия.

            Когда вы создавали файлы, то при выборе действия у вас было 4 варианта.

            «Создать» – «Заменить» – «Обновить» – «Удалить»

            Если по первому и последнему все я думаю понятно. На нашем примере «Создать» создает файлы путем копирования с сервера, а «Удаление» позволило бы очистить папку Intro Docs.

            То действия «Заменить» – «Обновить» не столь очевидны.

            Особый интерес представляет фильтрация применения «GP Preferences».

            Если вы помните, в Windows Server 2003 мы могли фильтровать применение групповой политики несколькими способами, самой распространенной была и остается фильтрация путем применения GP к разным организационным подразделениям. Если же мы хотели фильтровать применение GP в рамках одного организационного подразделения, то могли использовать WMI-фильтры или запрещать применение политики путем фильтров безопасности. Осуществлять фильтрацию, по каким-то признакам клиента можно было только с помощью WMI-фильтров и было это достаточно сложно.

            В Windows 2008 фильтрация «GP Preferences» выглядит поистине сказочно. Кто не верит на слово, предлагаю взглянуть на Рис.11

            image

            В «Нацеливании» (а именно так называется фильтрация «GP Preferences») есть если не все, то очень многое. Добавьте к этому «Нацеливание» по каждому элементу, а на всей политики разом и вы получите «Мечту системного администратора». Подробнее в видео-приложении.

            Вывод.

            Инструмент для работы получился отменный. Когда смотришь на подобные решения, действительно веришь в снижении стоимости обслуживания новых версии операционных систем от Microsoft. Следует заметить что «GP Preferences» можно установить и на контроллер домена под управлением Windows Server 2003, после чего задействовать данную возможность для управления сетью. Позвольте ответить на вопрос: Почему ты до этого об этом молчал?

            На последней встрече с архитекторами Microsoft зашел разговор о «GP Preferences» и я поинтересовался, почему они умалчивают возможность использования «GP Preferences» без покупки Windows Server 2008, на что я получил конкретный ответ: «Да, установить данную вещь на Windows Server 2003 можно и это будет работать. Но, работа «GP Preferences»на Windows Server 2003 компанией Microsoft не поддерживается, мы это выпустили, а вы хотите, используйте, хотите, нет». Вот собственно и причина моего молчания.

            Некоторые моменты в статье я осознанно опустил. Данная статья является экспериментальной. Она состоит из данного документа и видео-приложения.

            Скачать видео-демонстрацию.

            Рудь Илья

            MCSE/MCT

            me@rudilya.ru