Владислав Спектор, v 2.0
(Частично использованы материалы Википедии и других источников.)
Оглавление
1… Настоящее Оглавление
2… Краткая история AD
2… Ключевые моменты
2… Функции AD
3… Логическая структура AD: Objects, OU, Domains, Деревья Доменов (Domain Trees), Леса (Forests)
4… Физическая структура AD:
4… Физическая структура и репликация;
5… Функции физической структуры;
5… Домен Контроллер (DC);
5… Сайт (Site) - Site Link properties, Site-Link Bridge
5… Разделы AD (Partitions): Раздел Схемы (Schema partition), Домена (Domain partition), Раздел Конфигурации (Configuration partition), Разделы Приложений (Application partition)
6… Глобальный Каталог (Global Catalog , GC)
6… Хозяева Операций (Operations Masters) или FSMO (Flexible single-master operations): Назначение ролей
6… Роли хозяев уровня Леса (Forest-wide roles): Хозяин Схемы (Schema master), Хозяин именования Доменов (Domain naming master)
7… Роли хозяев уровня Домена (Domain-wide roles): Имитатор PDC (PDC emulator), Хозяин относительных идентификаторов (RID master), Хозяин инфраструктуры (Infrastructure master)
7… Передача ролей Хозяина Операций (Transfer FSMO roles), Захват ролей FSMO (Seize FSMO)
8… Таблица Active Directory
10… Для чего нужны OU и Группы и чем они отличаются
14… Group Policy
16… Сайты
20… Active Directory troubleshooting (занятия 7 и 8):
· утилиты AD
· GPO, Конфликты GPO
· Loopback Processing
· Мониторинг репликации
· Перенос (трансфер) и захват ролей при помощи NTDSutil
· Имитация проблем при расширении схемы
· NTDSutil
· Обобщение использования NTDSutil
· Хранение данных AD
· AD Backup
22… Сказочка про Кащея-Бессмертного
Краткая история AD
Во времена DOS и OS/2 существовал LAN Manager.
Во времена NT появились NT LAN Manager и NT Domain.
Затем появилась предтеча AD - Exchange Directory (Exchange 4.0-5.5).
Представление Active Directory состоялось в 1996 году, продукт был впервые выпущен с Windows 2000 Server, а затем был модифицирован и улучшен при выпуске сначала Windows Server 2003, затем Windows Server 2003 R2.
Ключевые моменты
Active Directory – это технология, являющаяся неотъемлемой частью серверных версий Windows 2000/2003. Active Directory предоставляет гораздо большие возможности, чем доменная система Windows NT и позволяет эффективно создавать открытые сетевые ресурсы, управлять ими и оперировать связанной информацией. Active Directory выступает также в качестве центрального узла аутентификации, то есть контролирует процесс входа пользователей в сеть и выдает им соответствующие привилегии в соответствии с настройками.
Active Directory совместима с LDAP. AD позволяет администраторам использовать групповые политики (GPO) для обеспечения единообразия настройки пользовательской рабочей среды, развёртывать ПО на множестве компьютеров (через групповые политики или посредством Microsoft Systems Management Server 2003 или System Center Configuration Manager), устанавливать обновления ОС, прикладного и серверного ПО на всех компьютерах в сети (с использованием сервера WSUS). Active Directory хранит данные и настройки среды в централизованной базе данных. Сети Active Directory могут быть различного размера: от нескольких сотен до нескольких миллионов объектов.
В отличие от версий Windows до Windows 2000, которые использовали в основном протокол NetBIOS для сетевого взаимодействия, служба Active Directory интегрирована с DNS и TCP/IP. DNS-сервер, обслуживающий Active Directory, должен быть совместим c BIND версии 8.1.2 или более поздней, сервер должен поддерживать записи типа SRV (RFC 2052) и протокол динамических обновлений (RFC 2136).
AD - служба каталога, определяющая каждого участника безопасности, а также их организацию. AD обеспечивает информацию об объектах в иерархической логической структуре. AD объекты представляют пользователей и ресурсы: users, computers, printers. Некоторые объекты являются контейнерами для других объектов
AD DataBase и ее разделы можно просмотреть при помощи Ldp.exe или ADSIedit
База данных AD (хранилище каталогов) в Windows 2000+ использует расширяемую подсистему хранения Microsoft Jet Blue, которая позволяет для каждого контроллера домена иметь базу размером до 16 терабайт и 1 миллиард объектов (теоретическое ограничение, практические тесты выполнялись только с приблизительно 100 миллионами объектов). Рекомендуется иметь до 1 миллиона объектов. Файл базы данных называется NTDS.DIT и имеет две основные таблицы — таблицу данных и таблицу связей. В Windows Server 2003 добавлена ещё одна таблица для обеспечения уникальности экземпляров дескрипторов безопасности.
Функции AD
AD призвана облегчать работу системных администраторов: она помогает администраторам управлять ресурсами в сети и решать проблемы доступа к ним. Обеспечивает централизованный контроль сетевых ресурсов, централизованное и децентрализованное управление ресурсами, безопасно хранит объекты в логической структуре, оптимизирует сетевой трафик.
Логическая структура AD
Objects
Active Directory (AD) имеет иерархическую структуру, состоящую из объектов. Объекты разделяются на три основные категории: ресурсы (например принтеры), службы (например, электронная почта) и люди (учётные записи пользователей и групп пользователей). Active Directory предоставляет информацию об объектах, позволяет организовывать объекты, управлять доступом к ним, а также устанавливает правила безопасности.
Каждый объект представляет отдельную сущность — пользователя, компьютер, принтер, приложение или общую сетевую папку — и его атрибуты. Объекты могут также быть контейнерами для других объектов. Объект уникально идентифицируется своим именем и имеет набор атрибутов (свойств) — характеристик и данных, которые объект может содержать; последние, в свою очередь, зависят от типа объекта. Можно представить себе тип объекта – бронтозавр. Он может иметь атрибут – толщина панциря. В тоже время тип объекта – компьютер – вряд ли будет иметь атрибут - толщина панциря, но зато он может иметь атрибут – скорость CPU.
Атрибуты являются составляющей базовой структуры объекта и определяются в схеме. Схема определяет, какие типы объектов могут существовать в AD.
Сама схема состоит из двух типов объектов: объекты классов схемы и объекты атрибутов схемы. Один объект класса схемы определяет один тип объекта Active Directory (например, объект «Пользователь»), а один объект атрибута схемы определяет некий атрибут, который объект класса может иметь (например, объект класса «Пользователь» может иметь атрибут «Цвет глаз»). Оба типа объектов представляют собой, по сути, шаблоны, на основе которых строятся реальные объекты, например пользователи или компьютеры (или бронтозавры).
Каждый объект атрибута может быть использован в нескольких разных объектах классов схемы. Например, объект атрибута «Цвет глаз» может быть применен как к объекту класса «Пользователь», так и к объекту класса «Бронтозавр».
Объекты атрибутов называются объектами схемы (или метаданными) и позволяют изменять и дополнять схему, когда это необходимо. Однако, каждый объект схемы является частью определений объектов Active Directory, поэтому деактивация или изменение этих объектов могут иметь серьёзные последствия, так как в результате этих действий будет изменена структура AD. Изменение объекта схемы автоматически распространяется в Active Directory. Будучи однажды созданным, объект схемы не может быть удалён, он может быть только деактивирован. Обычно все изменения схемы тщательно планируются.
Контейнер аналогичен объекту в том смысле, что он также имеет атрибуты и принадлежит пространству имён, но, в отличие от объекта, контейнер не обозначает ничего конкретного: он может содержать группу объектов или другие контейнеры.
OU
Применяются для иерархической организации, упорядочивания и разделения объектов, т.е. для группировки.
Группировка дает возможность управлять большим к-вом объектов,
Можно отделить компьютеры от пользователей, принтеров и групп
Можно применять GPO (Group Policy Objects)
Можно делегировать права контроля над OU (for Delegate Control)
Но для предоставления доступа к ресурсам используются группы, а не OU
Domains
Логическая группа компьютеров и объектов, использующих одну общую базу данных (находящуюся в файле NTDS.DIT) и разделяющих:
- имена пользовательских аккаунтов и паролей
- компьютерные аккаунты
- Группы
- OU
- DNS name
- политику пользовательских аккаунтов и паролей
Домен определяет границы безопасности в AD (хотя четкая граница пролегает между Лесами).
Логически существует одна база данных на Домен,
Физически – количество баз данных соответствует количеству DC (каждый имеет файл NTDS.dit).
Деревья Доменов (Domain Trees)
Имеют общее пространство имен (Contiguous Name Space)
Общие для Дерева параметры:
- DNS-name (Contiguous Name Space)
- Trusts (Parent-Child) - 2-way implicit transitive trusts
Леса (Forests)
Общие для Леса параметры:
- Schema
- Configuration
- Global catalog
- UPN (Unic Principal Name)
- Trusts - Top-Level 2-way implicit transitive trust
Физическая структура AD
Физическая структура и репликация
Физически информация AD хранится на одном или нескольких равнозначных контроллерах доменов, заменивших использовавшиеся в Windows NT основной и резервные контроллеры домена (хотя для выполнения некоторых операций сохраняется и так называемый сервер «операций с одним главным сервером», который может эмулировать главный контроллер домена). Каждый контроллер домена хранит копию данных AD, предназначенную для чтения и записи. Изменения, сделанные на одном контроллере, синхронизируются на все контроллеры домена при репликации. Серверы, на которых сама служба Active Directory не установлена, но которые при этом входят в домен AD, называются рядовыми серверами.
Репликация AD выполняется по запросу. Служба KCC создаёт топологию репликации, которая использует сайты, определённые в системе, для управления трафиком. Внутрисайтовая репликация выполняется часто и автоматически с помощью средства проверки согласованности (уведомлением партнёров по репликации об изменениях). Репликация между сайтами может быть настроена для каждого канала сайта (в зависимости от качества канала) — различная «оценка» (или «стоимость») может быть назначена каждому каналу (например DS3, T1, ISDN и т. д.), и трафик репликации будет ограничен, передаваться по расписанию и маршрутизироваться в соответствии с назначенной оценкой канала. Данные репликации могут транзитивно передаваться через несколько сайтов через мосты связи сайтов, если «оценка» низка, хотя AD автоматически назначает более низкую оценку для связей «сайт-сайт», чем для транзитивных соединений. Репликация сайт-сайт выполняется серверами-плацдармами в каждом сайте, которые затем реплицируют изменения на каждый контроллер домена своего сайта. Внутридоменная репликация проходит по протоколу RPC по IP, междоменная — может использовать также протокол SMTP.
Если структура Active Directory содержит несколько доменов, для решения задачи поиска объектов используется глобальный каталог: контроллер домена, содержащий все объекты леса, но с ограниченным набором атрибутов (неполная реплика). Каталог хранится на указанных серверах глобального каталога и обслуживает междоменные запросы.
Возможность операций с одним главным компьютером позволяет обрабатывать запросы, когда репликация с несколькими главными компьютерами недопустима. Есть пять типов таких операций: эмуляция главного контроллера домена (PDC-эмулятор), главный компьютер относительного идентификатора (мастер относительных идентификаторов или RID-мастер), главный компьютер инфраструктуры (мастер инфраструктуры), главный компьютер схемы (мастер схемы) и главный компьютер именования домена (мастер именования доменов). Первые три роли уникальны в рамках домена, последние две — уникальны в рамках всего леса.
Базу AD можно разделить на три логические хранилища или «раздела». «Схема» является шаблоном для AD и определяет все типы объектов, их классы и атрибуты, синтаксис атрибутов (все деревья находятся в одном лесу, потому что у них одна схема). «Конфигурация» является структурой леса и деревьев AD. «Домен» хранит всю информацию об объектах, созданных в этом домене. Первые два хранилища реплицируются на все контроллеры доменов в лесу, третий раздел полностью реплицируется между репликами контроллеров в рамках каждого домена и частично — на сервера глобального каталога.
База данных AD (хранилище каталогов) в Windows 2000 использует расширяемую подсистему хранения Microsoft Jet Blue, которая позволяет для каждого контроллера домена иметь базу размером до 16 терабайт и 1 миллиард объектов (теоретическое ограничение, практические тесты выполнялись только с приблизительно 100 миллионами объектов). Файл базы называется NTDS.DIT и имеет две основные таблицы — таблицу данных и таблицу связей. В Windows Server 2003 добавлена ещё одна таблица для обеспечения уникальности экземпляров дескрипторов безопасности.
Функции физической структуры
Оптимизирует сетевой трафик путем определения, когда и где осуществляется репликация и где происходит logon-трафик.
DCs - физически разделенные объекты и не идентичны Доменам.
Сайты – физически или географически разделенные объекты.
Домен Контроллер (DC)
Центральный (главный) сервер локальной сети, на котором работают службы каталогов и располагается хранилище данных каталогов.
Контроллер домена хранит параметры учётных записей пользователей, параметры безопасности (применимо к томам с файловой системой NTFS), параметры групповой и локальной политик.
При создании первого контроллера домена в организации (First Domain Controller), создаются также первый домен, первый лес, первый сайт и устанавливается Active Directory.
Контроллеры домена, работающие под управлением Windows Server 2003, хранят данные каталога и управляют взаимодействиями пользователя и домена, включая процессы входа пользователя в систему, проверку подлинности и поиски в каталоге.
Контроллеры домена создаются при использовании мастера установки Active Directory – ‘dcpromo’.
Сайт (Site)
сайты используются для настройки доступа к каталогам и репликации.
сеть делится на части (subnets) для быстрого log-on, а сайты - это собрание подсетей (subnets), связанных быстрым соединением (512 кб).
во время первого log-on клиент получает DC, который сообщает информацию о сайтах.
Site Link properties
intersite replication interval (180 min default)
schedule (morning, evening)
cost (priority) - путь наименьшей стоимости, если costs равны, используется site-link с наименьшим числом скачков (hops)
replication interval:
intrasite - 15 min (default)
intersite - 180 min (default)
Site-Link Bridge:
соединяет два Site-Links
используется, если нет полной связи между сайтами
IP (RPC) Site-Link - надежное соединение
SMTP Site-Link - для ненадежного соединения
KCC (Knowledge Consistency Checker) – инструмент для проверки и контроля репликации AD между DCs в пределах сайта, KCC проверяет и изменяет топологию репликации.
Разделы AD (Partitions)
Раздел Схемы (Schema partition):
схема это набор правил (конституция) Леса или набор шаблонов объектов
схема реплицируется в пределaх всего Леса
схема может изменяеться только с Хозяина схемы (об этом позже)
Схема это набор классов и атрибутов, хранящихся в каталоге.
Классы - это шаблоны, на основе которых создаются объекты:
класс пользователей, класс компьютеров, класс принтеров
возможно создавать свои классы, например: класс бронтозавров
У всех объектов есть атрибуты или свойства, например: имя входа (logon name)
возможно создавать свои атрибуты, например: цвет глаз, толщина панциря
Раздел Домена (Domain partition)
хранит информацию об объектах, созданных в Домене
полностью реплицируется в пределaх домена и частично - в пределах Леса на GC
Раздел Конфигурации (Configuration partition) :
определяет структуру Леса и Деревьев
реплицируется в пределaх Леса, изменяется с любого DC
implicit two-way transitive trustees
Разделы Приложений (Application partition):
репликация управляема
может осуществляться в пределах Леса в любой Домен или Сайт
по умолчанию существует раздел DNS
создается обычно в процессе инсталляции приложения
раздел можно создать при помощи NTDSutil
Глобальный Каталог (Global Catalog , GC)
Глобальный Каталог нужен в случае наличия нескольких доменов в Лесу.
Хранит реплики всех объектов Доменов AD Леса, но с сокращенным набором атрибутов, т.е. является частичной копией AD всех доменов в Лесу.
Глобальный Каталог реплицируется на все GC в Лесу.
Глобальный Каталог не изменяется, т.к. является Read-only.
Функция GC добавляется или удаляется при помощи ADSS (AD Sites and Services).
Возможно добавление атрибутов, хранимых GC, при помощи Active Directory Schema.
Хозяева Операций (Operations Masters) или FSMO (Flexible single-master operations)
FSMO— типы выполняемых контроллерами домена Active Directory операций, требующие обязательной уникальности сервера, выполняющего данные операции. В зависимости от типа операции уникальность FSMO подразумевается в пределах или леса доменов или домена.
Во времена Windows NT изменения в Домене осуществлялись при помощи так называемых Single-master operations. Только один главный DC был ответственен за изменения в Домене. Теперь, начиная с Windows 2000, Домены Active Directory работают по принципу Multi-master operations, когда все DC равны и все могут вносить изменения. Однако среди равных всегда есть самые равные. Только DCs, являющиеся Хозяевами Операций, могут делать особо важные изменения в Директории. Кроме важных изменений Single-master operations хороши также тем, чтопомогают избегать конфликтов репликации. В режиме Single-master operations выполняются следующие изменения:
- Изменения схемы на уровне Леса (Forest)
- Добавление нового домена
- Изменения паролей
Назначение ролей
По-умолчанию, при создании домена все роли назначаются первому созданному контроллеру домена, в случае создания леса доменов, все роли (уровня леса) исполняет начальный (корневой) домен.
Роли хозяев уровня Леса (Forest-wide roles)
Хозяин Схемы (Schema master)
Переносится в норме на другой DC при помощи AD Schema snap-in или NTDSutil. Единственный DC, имеющий разрешения делать записи в схему каталога. Изменения в схеме копируются на все остальные DC в Лесу (например, если вы инсталлируете Exchange Server в одном маленьком домене, вы влияете на весь Лес) !
Хозяин именования Доменов (Domain naming master)
Длужит для добавления или удаления Доменов в Лесу. При создании нового домена команда 'dcpromo.exe' подключается к Хозяину именования Доменов при помощи RPC. Переносится в норме на другой DC при помощи ADDT (AD Domains and Trusts).
Роли хозяев уровня Домена (Domain-wide roles)
Имитатор PDC (PDC emulator) – самая важная и срочная роль
нужен как единый центр изменения паролей (главная роль, важная даже в Домене, где все DCs являются серверами 2003)
нужен для сосуществования с NT DCs
нужен для реплицирования изменений на BDC в MIX Mode
нужен для обновления Password для пре-2000 клиентов
нужен для работы Domain Master Browser service
переносится в норме на другой DC при помощи ADUC
изменения пароля, сделанные на любом DC, всегда посылаются эмулятору PDC; в
случае конфликтных ситуаций он служит верховным арбитром; если пользователь не может идентифицироваться на каком-либо DC, то идентификация перенаправляется на PDC emulator.
Хозяин относительных идентификаторов (RID master)
дает область ID для DCs
каждый DC производит блок RID (RID-пул), который используется для раздачи SID: пользователям, группам, компьютерам.
перед тем, как блок RID истощается, делается запрос на другой блок у Хозяина
наличие единого Хозяина гарантирует уникальность каждой учетной записи в Домене
переносится в норме на другой DC при помощи ADUC
Хозяин инфраструктуры (Infrastructure master)
ответственен за обновление справочника групповой принадлежности пользователей
инфо о названиях аккаунтов и членстве в группах реплицируется на все DC в Домене
переносится в норме на другой DC при помощи ADUC
Передача ролей Хозяина Операций (Transfer FSMO roles)
осуществляется с согласия текущих владельцев ролей при помощи грапхических инструментов или утилиты NTDSutil.
Захват ролей FSMO (Seize FSMO)
Осуществляется в критических обстоятельствах при помощи NTDSutil.
Все роли могут быть переданы от одного контроллера домена другому при условии работоспособности обоих серверов. В случае, когда один из серверов не может продолжать работу, используется процедура захвата (англ. seize) роли другим сервером, выполняемая системным администратором вручную. В этом случае не производится обращений к прежнему владельцу роли. Новый контроллер домена просто "приступает к исполнению обязанностей". Необходимо помнить, что появление в сети прежнего владельца роли после её захвата новым не допустимо для трёх из пяти ролей (владелец схемы, владелец доменных имен, владелец относительных идентификаторов).
| AD Partitions | Разделы AD | Репликация |
| Schema Partition | Набор правил (Конституция) для леса (рабству нет) | Forest-wide replication, FSMO |
| Configuration Partition | Exchange Server, ISA Server, Сайты, их связи и подключения репликации | Forest-wide replication |
| Domain Partition | Информация соответствует ADUC | Domain-wide replication + GC |
| Application Partition | Пример: интегрированная зона DNS | Managed replication |
| Global Catalog (not Partition) | Частичная копия AD только для чтения | Read-only AD copy |
| Файл базы данных AD (хранилище каталогов) называется NTDS.DIT | База данных AD использует расширяемую подсистему хранения Microsoft Jet Blue | Файл базы данных AD имеет две основные таблицы — таблицу данных и таблицу связей |
| Microsoft Jet Blue позволяет каждому контроллеру домена иметь базу размером до 16 терабайт и 1 миллиарда объектов | В Windows Server 2003 добавлена ещё одна таблица для обеспечения уникальности экземпляров дескрипторов безопасности. | |
| Operating Masters | Хозяева Операций | Transfer FSMO roles with |
| Schema Master | мастер схемы - Forest-wide role | AD Schema, NTDSutil |
| Domain Naming Master | мастер именования доменов - Forest-wide role | ADDT |
| Infrastructure Master | мастер инфраструктуры - Domain-wide role | ADUC |
| PDC-Emulator | PDC-эмулятор - Domain-wide role | ADUC |
| RID-Master | мастер относительных идентификаторов - Domain-wide role | ADUC |
| Transfer/Seize FSMO roles | Передача/Захват ролей | Примечания |
| Transfer FSMO roles | Передача ролей Мастеров (Хозяев) Операций | осуществляется с согласия текущих владельцев ролей при помощи инструментов: ADUC, ADDT, AD Schema |
| Seize FSMO roles | Захват ролей Мастеров (Хозяев) Операций | осуществляется при критических обстоятельствах утилитой NTDSutil |
Для чего нужны OU и Группы и чем они отличаются ? (v.2b)
Как и каталоги в файловой системе, OU нужны для организации множества объектов в иерархию, что дает возможность ими управлять. На самом деле нам ведь нужны конечные объекты, так же как нужны файлы в файловой системе. Все остальное просто помогает нам справляться с большим их количеством, распределять их, классифицировать, а также управлять, причем желательно сразу массами объектов.
OU, например, помогают отделить компьютеры от пользователей, от принтеров и от Групп. Т.е., OU используются для группировки объектов, а также для задания прав и политик по отдельным OU. Так, Групповые Политики чаще всего назначают по OU (кроме Сайтов и Доменов). Также, отдельным пользователям можно делегировать права на OU.
Группы же используются для предоставления доступа к ресурсам, к тем же OU или файлам и папкам.
Важно не путать OU и группы, хотя и те и другие могут объединять пользователей, компьютеры и другие сетевые сущности.
OU – это концентрация определенных типов ресурсов – пользователей и компьютеров, а в реальной жизни – людей и средств производства. OU нельзя давать права на другие объекты, но ими самими можно владеть. Аналогия OU с прользователями в реальной жизни - Города с их жителями. При помощи OU можно делегировать управление набором принтеров, т.к. нельзя создать группу принтеров, но можно – OU принтеров.
Если определенным администраторам нужно дать управление набором серверов, то можно создать Группу админов, OU из этих серверов, и, затем, делегировать группе админов управление этим OU.
Групповые Политики также применяются к OU, но не к группам. Исключение – политики учетных записей (account policy), т.е. настройка паролей и блокировка аккаунтов. Политики учетных записей применяются только на уровне всего домена, когда уже безразлично, идет ли речь о Группах или OU (хотя в Windows 2008 это уже не абсолютная истина).
Groups – это хозяева, им даются права на Домены, OU, а также на диски, папки и файлы.
Можно сказать, что Группы – это колониальные страны, а OU или Домены – это их колонии.
Теперь только о группах.
Сначала о традиционно ориентированных, существовавших в эпоху Windows NT.
Local Groups - привязаны к местным ресурсам своего Домена (как женщины к дому).
Global Groups – включают пользователей из своего Домена, а к ресурсам (папке, принтеру), как правило, непосредственно не привязываются (что чаще характерно для мужского населения, обычно менее привязанного к дому).
Local Groups – могут включать в себя Users или Global Groups из своего или из других Доменов, наподобие того, как женщины могут включать в свой круг мужчин из своей или других стран и предоставлять им какие-либо ресурсы.
Global Groups – могут входить в Local Groups своего или других Доменов, наподобие того как мужчины входят в круг женщин своей или других стран и пользуются определенными типами их ресурсов.
Т.е., Локальные Группы как бы притягивают к себе Глобальные Группы, в том числе и из других Доменов, хотя сами за пределы своих Доменов не выходят. А Глобальные Группы, наоборот, стремятся выйти за рамки своих Доменов и воспользоваться ресурсами других Доменов (хотя и своими не пренебрегают).
Существует принцип AGDLP: Account - Global Group - Domain Local Group - Permissions. Это значит, что рекомендуется следующая последовательность действий:
- аккаунты пользователей включать в Глобальные Группы,
- Глобальные Группы в свою очередь включать в Локальные Группы Доменов,
- а Локальные Группы Доменов присоединять уже непосредственно к ресурсам и давать на них необходимые разрешения (permissions).
Такое построение обеспечивает, в конечном итоге, наиболее простое управление ресурсами и задание прав на них, а, кроме того, в таком случае относительно несложно обнаружить, кому какие права даны в соответствии с принадлежностью к группе (да и названия группам можно давать осмысленные и связанные с их целями). Нередко, правда, бывает, что права на ресурсы даются случайно и необдуманно, непосредственно пользователям, без включения их в какие-либо группы, что порождает хаос, который затем очень трудно исправить. Попробуйте, для примера, просканировать все папки и файлы (или OU) на предмет обнаружения того, какой пользователь к ним привязан и с какими правами. Фактически – это нереально. Лучше все делать заранее, ведь, как известно, нет ничего более постоянного, чем временные решения. Однако, правильный подход требует предварительного продумывания и первоначальной затраты усилий, на что в текучке дел всегда не хватает времени. Но все же это лучше, чем потом заниматься тушением пожаров или тотальной переделкой.
С 2000 года (и Windows 2000) началось повальное разложение, появились группы нетрадиционной ориентации. Global Groups теперь могут включать в себя Global Groups, а Local Groups могут включать в себя Local Groups. Конкретные аналогии можете придумать сами.
Кроме того, появились совершенно новые образования – Universal Groups. Их часто называют Универсальными Группами, но точно также их можно назвать Вселенскими Группами, т.к. Universe – это Вселенная. Они - своего рода космополиты-международники. Здесь разложение достигло апогея – эти могут включать в себя кого угодно и откуда угодно, а сами входят куда угодно и в кого угодно. Исключения - Universal Groups не могут входить в Global Groups и не могут включать в себя Local Groups.
Но и теперь, как и раньше, Global Groups выходят за пределы Домена, а Local Groups могут включать в себя группы из других доменов. Local Groups привязаны к ресурсу (как женщины к дому), а Global Groups, как и армии, состоящие из мужчин, выходят на захват чужих ресурсов и территорий (т.е. других Доменов с их пользователями, компьютерами и принтерами).
В 2000 году появились также Локальные Группы Домена. Вероятно, их удобно использовать в случае изменения местонахождения конкретного локального ресурса. Если расшаренная папочка переместилась на другой сервер, например, то не нужно создавать другую локальную группу и перемещать туда все группы и пользователей. Достаточно привязать Локальную Группу Домена к новому ресурсу.
Известный нам принцип AGDLP претерпел изменения и теперь существует принцип AGUDLP: Account - Global Group - Universal Group - Domain Local Group - Permissions. Не всегда обязательно применять его в полной мере, все зависит от конкретных обстоятельств. Но всегда нужно стараться включать пользователей в группы – это должно быть принципом.
А теперь о группах по порядку.
Типы Групп AD.
1. Локальные Группы Машины – находятся в SAM (Security Account Manager), могут включать Глобальные Группы, Локальные Группы своего Домена, Универсальные Группы.
2. Локальные Группы Домена – создаются только на DC. Являются подмножеством возможностей Глобальных Групп. Они могут содержать Глобальные Группы из любого другого домена, но их можно включать только в Локальные Группы своего Домена. Они могут также содержать другие Локальные Группы своего Домена.
3. Глобальные Группы Домена – могут помещаться в другие Глобальные Группы своего Домена.
Они выходят за пределы своего домена в поисках ресурсов. Их направление - вовне. Глобальные Группы включают в себя пользователей и Глобальные Группы своего Домена и предназначены для включения в локальные ресурсные группы как своего, так и других Доменов.
4. Универсальные Группы – сочетают достоинства как локальных групп (могут содержать другие группы), так и глобальных групп (могут помещеться в другие группы). Они, как ферзь, который сочетают достоинства ладьи и туры. Универсальные Группы отрицательно влияют на размер и скорость GC – и в этом их недостаток, поскольку GC знает не только названия Универсальных Групп, но и всех их членов.
Размер групп ограничен 5.000 членов, если функциональный уровень домена ниже чем Windows 2003. В Windows 2003 эта проблема решена. Она была связана с ограничением количества изменений в одной транзакции при репликации (5.000) и с тем, что при единственном изменении членства в группе, передается весь список членов. Хотя ограничение количества изменений в одной транзакции и не снято, однако теперь возможна инкрементальная передача изменений в членстве и транзакция не выходит за пределы максимального количества изменений.
Domain Users группой не являются, несмотря на сходство, и размер этой “не группы” ничем не ограничен.
Итак, обобщим.
То, что управляется – кидаем в OU. Тех, кто управляют – забрасываем в Группу. Затем Группе назначаем полномочия на OU.
И еще. Отдельный User может находиться только в одном OU, но в то же время принадлежать нескольким Группам. Так же, как мы можем жить только в одном Городе, но в то же время быть членами нескольких сообществ (комсомол, шахматный кружок и хор девочек-пенсионерок) одновременно. Т.е. OU – это «место жительства» пользователя, а Группа – одно из его свойств или атрибутов принадлежности и таких свойств-атрибутов может быть несколько или даже много.
Group Policy (v1.2)
- GPO – это набор установок, которые можно применить к компьютеру/пользователю.
- Среди этих установок: системные (OS)/пользовательские, перенаправление папок (Folder Redirection), установка и обновление программ, применение скриптов.
- Можно применять GPO на уровне: Сайта, Домена, OU (SDOU). Есть также GP на уровне локального компьютера.
- Существует возможность блокирования наследования GPO на определённом уровне иерархии SDOU. В то же время существует и противоположная возможность преодоления блокирования наследования GPO при помощи указания настройки No Override или Enforce на более высоком уровне иерархии SDOU.
- При помощи разрешений (Permissions) применение GPO в пределах определенного уровня можно фильтровать, т.е. в пределах OU, например, можно применить GPO только к части пользователей или групп. Применение зависит от наличия прав “Read” и “Apply GPO”. Рекомендация – пользоваться группами, а не пользователями.
- Информация GPO хранится в объекте, называющемся GPT (Group Policy Template), который является папкой в SYSVOL. В папке GPT находятся все файлы GPO. В рамках AD существует также GPC (Group Policy Container).
- Настройки Computer Configuration применяются ко всем компьютерным объектам того контейнера, к которому относится соответствующий GPO.
- Настройки User Configuration применяются ко всем пользовательским объектам того контейнера, к которому относится соответствующий GPO.
- Порядок применения GPO к компьютеру: Local-Site-Domain-OU-Child OU (LSDOU). Каждый следующий GPO переопределяет значения предыдущего, т.е., чем ближе GPO к конечному объекту (или ниже в иерархии), тем он сильнее. С другой стороны, установки No Override или Enforce (не считая их «прямых обязанностей» по преодолению блокирования наследования) «пробивают» настройки нижележащих GPO. Скрипты «бегут» в той же последовательности SDOU, причём у каждого скрипта есть Time-Out в 10 минут, поле чего он «вылетает» в пользу следующего скрипта. После применения компьютерной части всех GPO, перед пользователем появляется экран Logon. После ввода имени и пароля начинается применение пользовательских частей тех же GPO, которые уже применялись к компьютерам, причем в том же самом порядке. Нужно также учесть, что если к некоему иерархическому объекту (например, Домену или OU) применяется сразу несколько GPO, то они следуют в порядке от нижнего к верхнему в списке. Таким образом, сочетание всех изложенных факторов (применение GPO на разных уровнях LSDOU + порядок применения GPO в пределах конкретного уровня + блокирование + No Override/Enforce + фильтрация + возможность связывания одного GPO с несколькими контейнерами на одном или разных уровнях LSDOU) может привести к трудностям в понимании того, что же из множества установок реально применяется к конечному объекту. Поэтому существуют средства RSoP (logging mode) и раздел “Results” с консоли GPMC.
- Перед применением установок GPO, происходит проверка времени ответа/скорости доступа DC к рабочей станции. В случае если определяется Slow Link (время ответа более 10 мс ICMP-Ping или скорость доступа менее 512 кб/с), часть установок не применяется. Настройки определения скорости можно менять при помощи того же GPO:
Computer configuration\Administrative Templates\System\Group Policy
- Применение обновлений по определению: к рабочим станциям обновления применяются каждые 90 минут плюс 30 минут. DC обновляют политику каждые 5 минут. Можно изменить предопределённое время при помощи GPO: Administrative Templates\System\Group Policy. Если возникла необходимость немедленного применения политики, это делается при помощи команды gpupdate или gpupdate /force.
- GPO maintenance. Для создания нового GPO можно использовать Copy/Paste из существующего GPO. Эту операцию можно применять для копирования GPO в другой Домен. При этой операции нужно будет ответить на ряд вопросов. Можно делать Backup/ Restore определённой папки GPO. Можно делать Import забекапенного GPO в текущий, в таком случае имена GPO не играют роли.
- GPO Reporting – возможность при помощи консоли GPMC видеть только изменённые установки определённого GPO без необходимость входа в него и поиска всех изменённых значений !
- GPO Result - возможность увидеть реальные результаты применения GPO к определённому пользователю/компьютеру. Пользователь должен иметь профиль на целевом компьютере (т.е. он должен хотя бы раз зайти и выйти – совершить Logon/Logoff - под своим именем).
- GPO Modeling – моделирование применения GPO к определённому пользователю/компьютеру. Можно делать это с локального компьютера при помощи RSoP (Resultant Set of Policy).
Сайты (v.1.6)
Сайт – территориально-географическое деление, создаваемое для управления трафиком репликации данных AD и DFS и для ускорения процесса пользовательских Logon.
Идея сайтов взята из Exchange Server, начиная с версии 4.0 , когда об Active Directory ещё и не думали. Оттуда же взята и идея механизма (engine) базы данных Active Directory. До появления Windows 2000, Exchange Server имел собственную, отдельную от домена (тогда ещё просто домена безо всякой Active Directory) базу данных пользователей почты. В Windows2000/Exchange2000 их DB слились в единую базу данных Active Directory с общим управлением пользователями (не только счета пользователей, но и почтовые ящики теперь создаются из ADUC).
Репликация, как известно, нужна для синхронизации информации Active Directory между разными DC (в предположении, что в домене будет больше, чем один DC). Идея множественности DC имеет множество плюсов и даже маленьким организациям не стоит иметь меньше двух DC.
Active Directory состоит из разделов (partitions) Домена, Схемы , Конфигурации и Приложений (Applications). Существует также Global Catalog, который разделом не считается, хотя информация о нём хранится в Active Directory аналогичным образом.
Синхронизация информации между DC осуществляется отдельно для каждого раздела, включая топологию (DC, которые в ней участвуют и пути репликации между ними). Active Directory использует модель репликации с несколькими хозяевами (Multi-master replication). Модель репликации Active Directory представляет собой модель с нежёстким согласованием, обладающую сходимостью. Нежёсткое согласование – это возможность временного несоответствия информации на разных DC, а сходимость – приход к соответствию, в случае отсутствия изменений в течении некоторого времени. Это очень напоминает поведение протоколов роутинга.
При репликации используется процесс хранения и ретрансляции (store and forward) или последовательная передача изменений каталога по цепочке DC. При данном способе исходный DC не должен самостоятельно копировать изменения на другие DC, а они передаются как эстафетная палочка. Существует правило: внутри сайта должно быть не более 3-х скачков (hops) для передачи изменений, а для этого (попробуйте нарисовать и проверить) в сайте должно существовать не более 7 DC. Если эти условия не соблюдаются, то потребуются дополнительные соединения между DC.
В прежней модели репликации с единственным хозяином (Single-master replication), которая существовала в Windows Server версий 3.1-4.0, единственный в домене DC, умевший производить изменения (он назывался PDC), должен был самостоятельно и без посредников распространять изменения на все DC в домене. Кроме минусов, здесь был и большой плюс с точки зрения структур баз данных: даже теоретически не должна была сложиться ситуация инконсистентности баз данных домена (имеется в виду несогласованность информации разных DC).
Среди определений сайта есть и такое – это собрание подсетей (скорее всего, в пределах локальной сети), связанных высокоскоростными соединениями. Там, где связь медленная, обычно и пролегает граница сайта.
Цель создания сайта – уменьшить нагрузку на низкоскоростные соединения. Нагрузка создаётся репликацией DC и трафиком Logon (особенно в утренние часы).
Репликация внутри сайта
Репликация происходит почти сразу после изменения информации AD. DC выжидает 15 секунд перед началом распределения изменений. После репликации с одним партнером DC ожидает 3 секунды, а затем начинает репликацию с другим партнером. Процесс репликации инициируется уведомлением DC-отправителя. DC-адресат забирает изменения при помощи RPC (процедуры удаленного вызова). Это тип pull replication или тянущей репликации.
Репликация между сайтами
Главная цель межсайтовой репликации та же, что и создания сайта – т.е., уменьшение трафика репликации. Репликация инициируется согласно расписанию, а не уведомлениями, как это происходит при репликации внутри сайта. Существует окно репликации и интервал. Окно м.б. установлено на нерабочие часы. Интервал действителен только на время окна.
Трафик репликации посылается через серверы плацдармы (Bridhead-servers). В каждом сайте существует один Bridhead-server, который, получив изменения, распределяет их в пределах своего сайта. Это сделано для того, чтобы по медленным связям между сайтами изменения посылались только один раз.
Иными словами Bridgehead-server – это сервер, специально предназначенный принимать трафик репликации с другого сайта и реплицировать его на DC's в локальном сайте. Хотя Bridgehead-servers создаются автоматически, их можно назначать вручную.
Bridgehead-servers общаются между собой при помощи Site-links. Их, в свою очередь, можно объединять Site-link bridges. Site-link bridges представляют собой коллекцию Site-links с целью роутинга между не соседними сайтами.
site bridges are a collection of links to allow routing between non-adjacent sites.
Время ожидания репликации (replication latency).
В пределах сайта время ожидания равно 15 сек * 3 хопа = 45 сек (мах.).
В репликации между сайтами вычисления зависят от множества факторов и потому сложнее.
Срочная репликация (Urgent replication) происходит при:
- изменении политики блокировки учетных записей.
- изменении политики паролей.
- перемещении хозяина RID на другой DC.
- изменении пароля DC.
Срочные обновления, как правило, применяются к репликации внутри сайта.
У этого правила есть исключение: когда пользователь меняет пароль на каком-либо DC, это изменение немедленно копируется прямо в PDC-эмулятор при помощи RPC-подключения и независимо от сайта, которому принадлежит исходный DC. Такая репликация пересекает границы сайта и не использует Bridhead Servers. Т.е. всё в этом случае происходит так, как будто сайтов вообще не существует. Затем PDC-эмулятор обновляет другие DC домена через нормальный процесс репликации. Это сделано для того, чтобы PDC-эмулятор мог служить арбитром конфликтных ситуаций с изменением пароля пользователя в домене. Конечно, такая ситуация может создаться только тогда, когда сайт меньше, чем домен (т.е., когда домен включает в себя несколько сайтов).
Топология репликации.
Топология репликации генерируется автоматически и обычно не требует вмешательства, хотя оно и возможно. На каждом DC выполняется KCC – процесс, ответственный за создание топологии репликации в пределах сайта и между сайтами. KCC начинает работать с момента добавления второго DC в лесу и срабатывает каждые 15 минут. Действия KCC напоминают автоматические вычисления таблиц маршрутизации в роутерах.
При помощи ADSS можно заставить контроллер пересчитать топологию репликации. Это выполняется следующим образом:
ADSS – Server – NTDS Settings – Right click – All Tasks (from menu) – Check Replication Topology.
KCC создаёт объекты связи (connection objects), которые хранятся в разделе конфигурации AD. Объект связи всегда создаётся как одностороннее тянущее (pull) соединение между двумя DC. Обычно создаётся два односторонних соединения, что напоминает создание отношений доверия.
Объекты связи можно менять, редактируя параметры настройки объектов, автоматически созданных KCC, или же добавляя новые объекты вручную. Служба KCC не трогает связи, созданные или изменённые вручную.
Для каждого DC создаётся избыточное кольцо репликации в противоположном направлении, и тогда каждый DC получает 2 входящие и 2 исходящие связи. Каждый DC в сайте может быть удалён от любого другого DC не более, чем на 3 скачка (прыжка, хопа, ретрансляции). Если в сайте существует более 7 DC, то невозможно соблюсти круговую связь с тремя скачками и тогда создаются дополнительные объекты связи.
Важный момент: KCC вычисляет отдельное кольцо топологии репликации для каждого раздела (Partition) каталога AD.
- Для разделов конфигурации и схемы – топология для всех DC в лесу
- Для раздела каталога домена – топология для всех DC в домене
- Для раздела приложений или Application Partition – топология для всех DNS, например
- Для Global Catalog – минимум один DC в каждом домене леса (хотя формально GC разделом и не считается).
Итого, мы насчитали 4 топологии. Для просмотра разделов репликации и топологии можно использовать Replication Monitor из набора Support Tools серверного CD:
X:\Support\Tools\Suptools.msi
После установки инструментов поддержки достаточно открыть Run – replmon.
Кольцо репликации реализуется с помощью объектов связи. KCC старается использовать одни и те же объекты связи для нескольких разных колец репликации различных разделов каталога. В каждом сайте один DC (он же KCC) является ответственным за разработку межсайтовой топологии. Такой DC/KCC обозначается как ISTG (Inter-Site Topology Generator) – генератор межсайтовой топологии. По сути, ISTG – это выделенный межсайтовый KCC, в задачи которого входит:
- - определить серверы-форпосты (Bridgehead Servers) отдельно для каждого раздела каталога в сайте
- - затем создать объекты связи между Bridgehead Servers.
Способы управления репликацией.
Для управления репликацией каталога в AD используются:
- порядковые номера обновлений USN (update sequence numbers)
- значения уровня (high-watermark values)
- векторы новизны (up-to-dateness vectors)
- отметки об изменениях (change stamps).
Способы разрешения конфликтов репликации.
В случаях, когда два или больше администратора одновременно производят изменения, касающиеся одних и тех же объектов, могут возникнуть конфликтные ситуации (хоть и не каждый день). Способы их разрешения следующие:
- Объект, добавленный к удаленному контейнеру, будет перемещен в контейнер LostAndFound.
- Добавление объектов с тем же RDN в тот же контейнер: объект с высшим GUID будет сохранен, а с низким GUID будет переименован.
Репликация удалений объектов.
При удалении аккаунта пользователя или компьютера, он не уничтожается немедленно, а создается объект памятник (tombstone object) с новым атрибутом isDeleted=true плюс старые атрибуты GUID, SID, RDN и USN. Остальные атрибуты удаляются. Tombstone objects хранятся 60 дней, а затем в процессе уборки мусора (garbage collection), которая производится каждые 12 часов, объекты уничтожаются. Если некий DC не реплицировался более 60 дней, он может содержать неактивные объекты (Lingering objects), которые на других серверах уже исчезли. Такие объекты иногда называют фантомами или зомби. Для предупреждения такого явления в Windows 2003, начиная с Service Pack 2, Tombstone objects хранятся 180 дней, т.е. в 3 раза больше прежнего. Время хранения Tombstone objects называется Default Tombstone Lifetime (TSL). Существует известный баг, когда после инсталляции Windows Server 2003 R2 значение TSL остается 60 дней. В таком случае нужно просто установить Service Pack 2 (SP2).
Active Directory troubleshooting (занятия 7 и 8)
1. Инсталлировать и разобрать утилиты AD: GPMC, RSoP, GPResults, GPUpdate etc.
2. Какие свойства компьютеров можно изменить при помощи GPO и реализовать изменения. Конфликты разных GPO.
3. Какие свойства компьютеров можно изменить при помощи Loopback Processing и реализовать изменения.
4. Мониторинг репликации при помощи следующих инструментов: Event Viewer, Repadmin, Replication Monitor (GUI), DCDiag (самостоятельная работа, можно использовать интернет).
5. Перенос (трансфер) и захват ролей при помощи NTDSutil.
6. Имитация проблем, которые могут иметь место при расширении схемы (установка Exchange Server, обновление Домена до новой версии) . Проблемы могут возникнуть, если в течение некоторого времени не выполнялась репликация вследствии отсутствия парнеров. Партнеры по репликации могут отсутствовать в случае, если “некультурным” путем был опущен DC (поломка или по невнимательности). Для имитации проблем нужно удалить Child Domain. Затем хужно очистить его “следы” при помощи NTDSutil. После этого выполнить окончательную “дочистку” при помощи: ADSS, ADUC, DNS. Те, у кого нет Child Domain, могут попробовать удалить Active Directory со второго DC в основном Домене при опущенном первом DC с помощью команды dcpromo /forceremoval, а затем поднять первый DC и очистить “следы” второго DC.
7. NTDSutil – Authoritative and Nonauthoritative restore базы данных AD. Если отказал DC, после его восстановления лучше сделать Nonauthoritative restore. После удаления OU нужно делать Authoritative restore.
8. Обобщение использования NTDSutil: - очистка AD от несуществующих DCs или Child Domains – передача или захват ролей FSMO - восстановление базы данных AD - восстановление журналов транзакций – проверка целостности базы данных AD (проверка таблиц на непротиворечивость) – семантическй анализ базы данных AD (что каждый объект имеет GUID, правильныe SID и реплицированные метаданные) - дефрагментация базы данных AD – перемещения базы данных AD и места расположения журналов транзакций.
9. Хранение данных AD.
В папке %systemroot%\NTDS\ содержатся следующие файлы: NTDS.DIT, Edb.chk, Edb.log, Edbxxxxx.log, Edbtemp.log, Res1.log, Res2.log. Всего 7 файлов. Структура папки напоминает Exchange Server.
NTDS.DIT – основной файл базы данных AD, содержит Partitions,
Edb.chk – файл контрольных точек, 10mb.,
Edb.log – журнал регистрации транзакций,
Edbtemp.log – временный журнал, создаваемый при заполнении Edb.log,
Edbxxxxx.log -
Res1.log, Res2.log – резервные журналы, используются тогда, когда на HDD заканчивается свободное место, которое они и гарантируют.
Сначала выполняется быстрая запись в журналы, затем в RAM, затем в основной файл DB. Если сервер выключается внезапно, то из RAM изменения не передадутся в DB. После перезапуска DC найдет в журнале не переданные транзакции и применит их к DB. Файл контрольных точек (Edb.chk) указывает на то, какие транзакции уже были переписаны в DB из журналов, чтобы не делалась лишняя работа.
10. AD Backup.
Осуществляется при помощи Backup System State. При этом одновременно архивируется несколько разных типов информации из-за их тесной интеграции. Такой Backup всегда является Normal Backup. Желательно делать Backup всех DCs, но минимально, хотя бы носителей ролей Хозяев Операций (FSMO roles).
Нельзя восстанавливать AD из Backup, давность которого превышает время жизни Tombstone Objects (Объектов Памятников). Иначе образуются фантомные объекты, которые существуют только на восстановленных DCs. Backup должен происходить каждую ночь. В хорошей программе существуют Backup Agents, которые умеют копировать Locked files.
Важно восстанавливать папку SYSVOL. В программе Microsoft Backup в окне “Advanced Restore Options” нужно выбрать опцию “When restoring… mark the restored data as the Primary data…”, что бы изменения, восстановленные на данном DC распространились на все другие.
Сказочка про Кащея-Бессмертного, сундук с деньгами и сисадмина И. Царевича
(из несуществующего сборника "Сказки сумасшедших админов или Вам и не снилось")
Автор сказки - Владислав Спектор (v1.1)
Предварительные замечания:
- Данный документ является наброском продолжения известной сказки и рассчитан на системных администраторов, имеющих минимум год опыта работы с Active Directory.
- Данный технический документ служит для лучшей усвояемости (усваимости) материала по курсу Active Directory 2003.
- Действие происходит в наши времена и с учетом сегодняшних реалий.
Жители-участники системы безопасности Active Directory:
Кащей-Бессмертный - стареющий, но все еще стройный, немного даже чересчур, деловой мужчина с седыми висками и замашками театрального злодея.
Баба-Яга – вечно старая, живущая в Из-На-Кур-Нож в районе НИИ-ЧАВО и привычно-недовольная жизнью.
Карабас-Барабас - с поседевшей, но все еще шикарной бородой и неутихающей болью в сердце из-за утраченной карьеры театрального режиссера, предательства целого театрального коллектива и перманентной зависти к Роману Виктюку.
Бармалей - безвредный, ничего от жизни уже не ждущий негодяй, потихоньку спивающийся французским шампанским.
Живут они все в одном лесном хозяйстве-OU (Organizational Unit) со множеством зеленых пригорков и имеющем название " OU_Сказочные_Злодеи". Хозяйство принадлежит Царству-Домену с довольно демократическим режимом, конституцией и свободной политикой паролей.
Хозяином у них и, по совместительству, сисадмином с делегированными полномочиями - небезызвестный в хакерских кругах И. Царевич.
Управляет он этим злодейским OU-хозяйством и, буквально, держит Кащея и других его содельников за яйца (в смысле, в руках, причем Бабы-Яги это как-то меньше всех касается, видимо, из-за уважения к женщинам и природной галантности неисправимого ловеласа), поскольку Иван точно знает, на каком файловом сервере хранится сундучок с деньгами, яйцом и ключами (последние, видимо по недосмотру, раньше называли почему-то иголками), по одному на каждого злодея. А в ключах этих, как известно, хранится доступ всех этих нехороших людей (то бишь, редисок) к деньгам злодейского общака. Немного неясно, правда, как ключи, которые находятся внутри сундука могут дать возможность открыть этот самый сундук, но это ведь всего лишь сказка, тем более, что в "Алисе в Стране Чудес" и не такое бывало. А Льюис Кэрролл, хотя и был математиком, в наше время мог и реальным программером заделаться, а значит и чувство рекурсивности могло быть ему не чуждо.
Итак, дано:
Сундук с деньгами - фолдер, зарытый глубоко в недрах файловой системы.
Яйцо (ACL - Access Control List) - со списком доступа к фолдеру-сундуку и с набором из 4-х ключей, по одному на каждого злодея.
Ключ, а в далеком прошлом, иголка (ACE - Access Control Entry) - несет на кончике SID (такой, как бы, паспорт или, на языке Царства, теудат-зеут старорежимного образца) одного пользователя-злодея со всеми его правами на фолдер.
Если сломать кончик ключа, SID злодея исчезнет из списка доступа (DACL) к сундуку и, соответственно, утратятся все его права доступа на сундук с деньгами. А это, как известно, смерти подобно, ведь что за жизнь, если ни гроша за душой.
В нашем яйце (ACL) есть целых 4 ключа (ACE), несущих финансовую смерть каждому из злодеев.
Если сломать ключ, Кащей просто концы отдаст из-за жадности и бедственного материального положения (хотя я, на самом деле, не понимаю, почему концов у Кащея должно быть несколько, возможно это просто семантический оборот, потому как даже моряки иногда говорят "отдать концы" вместо "отдать швартовы").
И вот, наконец, наступил момент, когда у И. Царевича полностью лопнуло терпение после очередной злостной выходки Кащея (в данном контексте не так уж важно, какой именно) и он таки решился сломать ключ.
Но Кащей был парень не дурак и не лыком шит и заранее полностью отобрал права у всех участников системы безопасности нашего Царства-Домена, включая даже Энтерпрайз-Администраторов, не говоря уже о неправомочном сокрытии местонахождения сундука (в молодости он нередко баловался компьютерами на перфолентах и среди студенток пользовался репутацией крутого компьютерщика, не упоминая уже о некоторых других репутациях). Даже подельникам своим он оставил лишь право на чтение (Read-Only) в отношении содержимого сундука, ведь был он кассиром общака с полными админскими правами (Full Control) на сундук и своего упускать не собирался. Вынашивал он даже план - дождаться удобного момента и сбежать со всей кассой в другое Государства-Домен, с которым не было в тот момент даже односторонних доверительных отношений, не говоря уже о дружески-транзитивных в стиле "Друг моего друга - мой друг" (друг, не drug). Тем более, что в упомянутом государстве все еще царила тоталитарная система в духе Мао Цзе-Дуна и Windows NT с полным отсутствием всякой демократической транзитивности, что Кащею как раз таки и было на руку, на нечистую его.
И тогда И. Царевичу пришлось шевельнуть одной из своих извилин и взять право владения (т.е. Ownership) на папочку-сундучок, ведь все-же был он реальный пацан с реальными правами Энтерпрайз-администратора, причем не только на злодейское OU-хозяйство, но и на папочки всех злодеев на главном сторидж-сервере хозяйства (совместного производства достопочтенных фирм HP/Microsoft). Была, кстати, грешным делом у Царевича мысль прижать Кащея, чтоб поделился запасами из общака и пустить изначально неправедные деньги на праведное дело - настоящий сторидж сказочной фирмы NetApp, а то и, вообще, SAN EMC с настоящей оптикой без дураков и без всяческих паллиативов наподобие iSCSI. Но со вздохом откинул Царевич нелояльные к законам родного Домена мысли и стал претворять в жизнь свой незамысловатый план.
(продолжение, возможно, следует ...)
Извиняюсь за беспокойство. Может ли ктото проконсультироват приватно по AGDLP ?
ОтветитьУдалитьemail:
mikepatter@gmail.com
Спасибо заранее