Служба каталогов Active Directory

Group Policy Management Console

В качестве примера установки пакета с помощью назначения мы выбрали пакет MS Group Policy Management Console ( Консоль управления групповыми политиками ). Установочный комплект можно найти в Центре загрузки сайта корпорации Microsoft (пакет распространяется бесплатно).

Рассмотрим теперь подробнее, как работает этот пакет.

Во-первых, установить его можно на компьютер с системам Windows XP/2003. При этом управлять политиками пакет может и в доменах под управлением Windows 2000.

Во-вторых, при просмотре свойств какого либо домена или ОП закладка "Групповые политики" после установки GPMC выглядит по-другому (рис. 6.53):

Рис. 6.53.

На этой закладке вместо списка политик и множества кнопок теперь всего одна кнопка " Open " (" Открыть ").

Отметим основные преимущества этой консоли по сравнению с базовыми возможностями системы.

1. Наглядное отображение иерархии внутри домена со всеми объектами ГП, привязанными к разным уровням иерархии ОП (рис. 6.54):

Рис. 6.54.

На рисунке хорошо видна вся иерархия подразделений внутри домена world.ru. Причем на каждом уровне отображается список политик, привязанных к данному уровню. Например, на уровне домена привязаны политики: стандартная политика домена, политика GPMC (назначение пакета GPMC) и политика MS Office 2003 (публикация пакета MS Office). На уровне подразделения OU-1 включено блокирование наследования политик (синий значок с восклицательным знаком). Стандартная политика домена Default Domain Policy имеет свойство " Не перекрывать " (небольшой значок справа от стрелки на пиктограмме объекта ГП). Включение параметра " Не перекрывать " в этой консоли делается так: щелкнуть правой кнопкой мыши на объекте ГП и в контекстном меню выбрать пункт " Enforce ".

В контейнере " Group Policy Objects " приведен полный список всех объектов ГП.

Для вызова редактора политик нужно щелкнуть правой кнопкой мыши на объекте ГП и в контекстном меню выбрать пункт " Edit ".

В разделе " Group Policy Modeling " можно определить, какой набор политики будет применяться на том или ином уровне иерархии AD (на рис. 6.55 выведен список политик, примененных к подразделению OU-1):

Рис. 6.55.

В разделе " Group Policy Results " можно определить набор параметров, примененных к определенному пользователю или компьютеру в результате наложения всех политик (рис. 6.56, список политик для пользователя Администратор ):

Рис. 6.56.

6.4 Система безопасности (протокол Kerberos, настройка параметров системы безопасности)

Протокол Kerberos

Протокол Kerberos был создан более десяти лет назад в Массачусетском технологическом институте в рамках проекта Athena. Однако общедоступным этот протокол стал, начиная с версии 4. После того, как специалисты изучили новый протокол, авторы разработали и предложили очередную версию — Kerberos 5, которая была принята в качестве стандарта IETF. Требования реализации протокола изложены в документе RFC 1510, кроме того, в спецификации RFC 1964 описывается механизм и формат передачи жетонов безопасности в сообщениях Kerberos.

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

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

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

Простой протокол аутентификации с секретным ключом вступает в действие, когда кто-то стучится в сетевую дверь и просит впустить его. Чтобы доказать своё право на вход, пользователь предъявляет аутентификатор ( authenticator ) в виде набора данных, зашифрованного секретным ключом. Получив аутентификатор, "привратник" расшифровывает его и проверяет полученную информацию, чтобы убедиться в успешности дешифрования. Разумеется, содержание набора данных должно постоянно меняться, иначе злоумышленник может просто перехватить пакет и воспользоваться его содержимым для входа в систему. Если проверка прошла успешно, то это значит, что посетителю известен секретный код, а так как этот код знает только он и привратник, следовательно, пришелец на самом деле тот, за кого себя выдаёт.

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

Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Цербер (или Кербер ) — персонаж греческой мифологии. Этот свирепый пёс о трёх головах, по поверьям греков, охраняет врата подземного царства мёртвых. Трём головам Цербера в протоколе Kerberos соответствуют три участника безопасной связи:

• Клиент — система (пользователь), делающий запрос;
• Сервер — система, которая обеспечивает сервис для систем, чью подлинность нужно подтвердить.
• Центр распределения ключей ( Key Distribution Center, KDC ) — сторонний посредник между клиентом и сервером, который ручается за подлинность клиента. В среде Windows , начиная с Windows 2000, в роли KDC выступает контроллер домена со службой каталогов Active Directory.

В среде Kerberos для входа в систему пользователь должен предоставить свое имя пользователя, пароль и имя домена (часто упоминаемое как Realm, или " Сфера ", в словаре Kerberos), в который он хочет войти. Эта информация посылается KDC, который устанавливает подлинность пользователя. Если пользователь подлинный, ему предоставляется нечто, называемое " билет на получение билета " ( ticket-granting ticket, TGT ).

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

Когда вы хотите получить доступ к серверу, вы сначала должны обратиться к KDC, предъявить свой билет TGT, как подтверждение своей подлинности, а затем уже запросить " билет сеанса " для сервера, с которым вам необходим контакт. Если вы аутентифицированы, вы сможете получить доступ к серверу в соответствии с правами, которыми обладаете. Билет сеанса и TGT, которые вы получаете, имеют ограниченное время действия, которое может настраиваться в групповой политике. Значения по умолчанию составляют для TGT (также упоминаемого как билет пользователя) — 7 дней, а для билета сеанса (также упоминаемого как билет службы) — 10 часов.

В среде с одним доменом аутентификация Kerberos осуществляется очень просто. Однако в среде со многими доменами, этот процесс происходит в несколько этапов. Причина в том, что когда вы пытаетесь получить билет сессии для сервера, он должен быть получен от KDC того домена, в котором расположен сервер. Поэтому вы должны будете получить несколько билетов сессии, для прохождения цепочки доверительных отношений по пути к KDC, к которому вам нужно получить доступ.

Пример, приведенный ниже, демонстрирует шаги, необходимые для того, чтобы клиент, расположенный в домене it.company.ru, получил доступ к серверу в домене sales.company.ru:

• клиент входит в систему как пользователь в домене it.company.ru и получает соответствующий TGT;
• клиент хочет взаимодействовать с сервером в домене sales.company.ru, он контактирует с KDC в домене it.company.ru и запрашивает билет сеанса для KDC в домене company.ru;
• после получения этого билета он контактирует с KDC в домене company.ru и запрашивает билет сеанса для KDC в домене sales.company.ru;
• после получения этого билета он контактирует с KDC в домене sales.company.ru и запрашивает билет для сервера, к которому ему необходим доступ;
• получив билет сессии для доступа к серверу, клиент имеет доступ к нему в соответствии с имеющимися у него разрешениями.