Сетевой протокол аутентификации Kerberos или зачем нужны утверждения

Kerberos3-01

Это кто же такой там мохнатенький?

У него же глаза виноградинки…

То дрожит и скулит он обиженно,

То рычит и наглеет — бесстыжий он…

Все прекрасно знают, что в доменных службах Active Directory Windows Server 2012 появилось нововведение, именуемое «Динамический контроль доступа». Так как эта тема довольно обширная и достойна того, чтобы была рассмотрена отдельным циклом статей, на этом этапе остановимся лишь на том, что это новый компонент Windows Server 2012, позволяющий эффективно управлять проверкой подлинности на файловых серверах компании.

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

И вот на этом этапе у читателя может возникнуть следующий вопрос: согласно предыдущим двум абзацам выходит, что динамический контроль доступа – интересный компонент, связанный с файловыми серверами и доменными службами Active Directory, но какое же отношение этот компонент имеет к протоколу проверки подлинности Kerberos? Далее в этой статье вы узнаете о том, как связаны Kerberos и динамический контроль доступа, что такое утверждения, а также что собой представляет безопасное туннелированные для гибкой аутентификации FAST. А начнем мы, пожалуй, с середины, а именно с определения утверждений.

 

Что такое утверждения и какая их роль в динамическом контроле доступа

С таким понятием, как утверждения, полагаю, вы уде давно знакомы еще по серверной роли Active Directory Federation Services, однако, напомню, что это такое и что они собой представляют в динамическом контроле доступа.

В более ранних версиях Windows доступ к файлам и ресурсам основывался на идентификаторах безопасности, то есть, доступ предоставлялся, лишь основываясь на том, будет ли удачно пройдена проверка подлинности пользователя, согласно имени учетной записи и его паролю или же входил ли пользователь в определенную группу. С процессом проверки подлинности, кстати, вы могли познакомиться из материала предыдущей статьи данного цикла. Естественно, предоставлять каждому пользователю доступ к сетевым ресурсам в личном порядке просто бессмысленно, так как на это у вас может уйти уйма времени, да и вы, в конце концов, просто когда-то запутаетесь в списках разрешений. Поэтому было принято предоставлять доступ членам определенных групп. И, кстати, нередко происходили такие случаи, когда, по каким-то причинам, доступ к ресурсам получали сотрудники, которые не должны видеть определенные документы. Именно по этой причине в Windows Server 2012 для разграничения доступа для ресурсов, расположенных на файловых хранилищах появилось такое понятие, как утверждения. Итак, что же это такое?

Утверждения представляют собой доверенный источник информации об учетной записи, пытающейся выполнить авторизацию, которая предоставляется в атрибутах Active Directory этой учетной записи. К утверждениям можно отнести подразделение, в котором работает пользователь, его номер комнаты, город, в котором он живет, идентификатор безопасности самого пользователя или его компьютера, причем, в одной записи могут храниться по нескольку утверждений, что позволяет делать политики динамического контроля доступа достаточно гибкими. При помощи утверждений можно ограничивать доступ как к файлам, так и папкам, причем, все созданные вами утверждения будут публиковаться в Active Directory. Причем, для полноценного функционирования динамического контроля доступа и утверждений, в частности, нет каких-либо ограничений, относительно функционального уровня домена или леса вашей организации. Основные требования – это, по крайней мере, один контроллер домена под управлением Windows Server 2012, файловый сервер, работающий под операционной системой Windows Server 2012, а также клиенты под управлением Windows 8, поддерживающие утверждения.

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

В редакторе управления групповой политики разверните узел Конфигурация компьютераПолитикиАдминистративные шаблоныСистемаЦентр распространения ключей и выберите параметр политики «Поддержка KDCтребований, комплексной проверки подлинности и защиты Kerberos». Установив переключатель на опцию «Включить» вы обнаружите, что при помощи управляющего элемента можно выбрать одно из четырех следующих действий:

  • Не поддерживается. Действие, указанное по умолчанию, которое обозначает, что не поддерживаются ни утверждения, ни защита Kerberos, ни комплексная проверка подлинности. Другими словами, выполняется то же действие, как если бы переключатель был установлен на опцию «Не задано» или «Отключено»;
  • Поддерживается. Если вы выберете это действие, то все контроллеры домена в организации начнут информировать о поддержке утверждений, защиты Kerberos, а также о комплексной проверке подлинности для динамического контроля доступа. Это действие считается универсальным;
  • Всегда поддерживать утверждения. Как и при выборе действия, поддерживаются все предыдущие функциональные возможности, а также помимо всего этого поддерживается реакция на события FAST. В этом случае необходимо, чтобы в вашей организации был установлен функциональный уровень домена Windows Server 2012 и, естественно, все контроллеры домены были оснащены операционными системами Windows Server 2012;
  • Отклонять незащищенные запросы на проверку подлинности. Данное действие от предыдущего отличается лишьтем, чтоздесь от всех устройств, которые поддерживают FAST, требуется запрос на проверку подлинности, а все незащищенные сообщения Kerberos будут отклоняться. Как и в предыдущем случае, основным требованием является функциональный уровень домена Windows Server 2012. Если функциональный уровень ниже, то последние два действия работают в режиме действия «Поддерживается».

    Диалоговое окно параметра политики изображено на следующей иллюстрации:

Kerberos3-02

Рис. 1. Включение поддержки динамического контроля доступа

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

Утверждения пользователей могут быть выданы контроллерами доменов под управлением Windows Server 2012 и могут включать в себя большинство пользовательских атрибутов Active Directory. В свою очередь, утверждения устройств выдаются для учетных записей компьютеров и включают в себя большинство атрибутов для этих типов объектов. Поэтому иногда такие утверждения также называются утверждениями компьютеров. Между прочим, утверждения устройств можно выдавать в том случае, если домен ресурса поддерживает утверждения и комплексную проверку подлинности для динамического контроля доступа и защиты Kerberos (о комплексной проверке подлинности и защите Kerberos речь пойдет в следующих разделах статьи).

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

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

Утверждения и центр распространения ключей с сертификатами атрибутов привилегий. Как вы знаете из материала предыдущей статьи данного цикла, KDC позволяет в билете TGT передавать идентификаторы безопасности в сертификатах атрибутов привилегий, PAC. В ранних версиях Windows PAC включали в себя только идентификаторы безопасности пользователей, а также групп, так как в остальных идентификаторах не было никакой необходимости. Теперь же, с выходом Windows Server 2012 и утверждений все стало иначе.

Так как появилось такое нововведение, как динамический контроль доступа, теперь контроллеры домена обязаны считывать различные типы утверждений, опубликованных в Active Directory, обеспечивать авторизацию при помощи этих утверждений, а также обеспечить безопасность такому типу авторизации. Следовательно, контроллер домена должен определять типы утверждений, получать атрибуты данных для осуществлений проверки подлинности, а KDC, в свою очередь, должен вставлять полученные атрибуты данных в PAC для TGT. Идентификаторы утверждений должны добавляться в PAC исключительно для обратной совместимости с более ранними версиями контроллеров домена, то есть, для того, чтобы контроллеры домена смогли как-то отфильтровать, согласно каким идентификаторам безопасности следует обеспечивать проверку подлинности. При получении AS-запроса, KDC проверяет в PAC на наличие бита PA-PAC-OPTION со значением «true». Соответственно, если для этого бита проставлено значение true – включен динамический контроль доступа и следует обрабатывать из доменных служб Active Directory информацию об утверждениях, включающую определенный тип утверждений, согласно идентификатору безопасности из PAC.

Новая защита Kerberos, пришедшая с утверждениями

Ранее, в протоколе Kerberos была одна брешь, а именно отсутствие защищенного канала между самим Kerberos и центром распространения ключей. В Windows Server 2012 эта ситуация исправилась с выходом безопасного туннелирования для гибкой аутентификации (Flexible Authentication Secure Tunneling, FAST).

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

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

Технология FAST представляет собой защиту для обмена между службой проверки подлинности и службой предоставления билетов. Исходя из названия, не сложно догадаться, что FAST обеспечивает, грубо говоря, стандартизированный канал, предназначенный для передачи данных предварительной проверки подлинности по туннелю. Между прочим, некоторые данные предварительной проверки подлинности, используемые FAST, называются «FAST-фактором». FAST-фактор выполняет минимальную работу, необходимую для расширения Kerberos, для поддержки новой схемы предварительной проверки подлинности. Главное, что FAST-фактор не должен использоваться за пределами самого FAST.

Защищенный канал, полученный благодаря технологии FAST, увеличивает защиту сетевого мониторинга и даже позволяет системам, подключенным к домену, защищать проверку подлинности пользователей Kerberos от спуфинга ошибок KDC Kerberos, связанных с переходом на использование NTLM или менее надежного шифрования. В сочетании с секретными ключами, FAST отчасти позволяет защищаться даже от активных атак.

А если появились новые функциональные возможности – должен появиться и какой-то параметр политики, позволяющий эффективнее использовать такой компонент. FAST не может быть исключением. В редакторе управления групповыми политиками можно найти параметр политики «Активировать ошибку запроса проверки подлинности, если защита Kerberos недоступна», который определяет, требуется ли, чтобы сообщения Kerberos, отправляемые компьютером на контроллер домен были защищены. Следовательно, желательно сразу активировать данный параметр политики. Диалоговое окно свойств этого параметра политики изображено на следующей иллюстрации:

Kerberos3-03

Рис. 2. Активация ошибки запроса проверки подлинности

Если хотите узнать больше информации о FAST, рекомендую ознакомиться с RFC 6113.

Комплексная проверка подлинности

В дополнение к безопасному туннелированию для гибкой аутентификации, в протоколе Kerberos Windows Server 2012 еще появилось такое нововведение, как комплексная проверка подлинности. Сейчас, благодаря комплексной проверке подлинности, центр распространения ключей может создавать билеты служб с данными авторизации не только для конкретных пользователей, но еще и для устройств, для которых настроена поддержка данных авторизации. Защищенный запрос TGS билета TGT компьютера считается безопасным, благодаря защищенному туннелю, используемому клиентом Kerberos и KDC. Сам KDC проверяет целевую службу, на наличие поддержки комплексной проверки, и если все нормально, то добавляет в PAC билета службы данные авторизации из первичного билета TGT компьютера и защищенного TGT пользователя.

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

Основным требованием применения комплексной проверки подлинности является наличие контроллеров домена, работающих исключительно под операционной системой Windows Server 2012. Это объясняется тем, что если в корневых доменах леса существуют контроллеры доменов под управлением систем, выпущенных ранее Windows Server 2012, то последние будут отменять утверждения. В связи с этой отменой утверждений будут возникать периодические сбои управления доступом, и данные утверждения не будут передаваться доверенному лесу. И второе требование – это, как минимум, значение «Поддерживается» для параметра политики «Поддержка KDCтребований, комплексной проверки подлинности и защиты Kerberos», который был рассмотрен в одном из предыдущих разделов данной статьи.

Как и все компоненты, комплексная проверка подлинности также настраивается средствами групповой политики. Для активации комплексной проверки подлинности в узле «Kerberos» можно найти параметр политики «Поддерживать комплексную проверку подлинности». Установив переключатель на опцию «Включить», вы можете выбрать из соответствующего раскрывающегося списка три возможных действия: «Всегда», что означает, что KDC будет предоставлять комплексную проверку подлинности для указанного компьютера, «Автоматически» — предоставление комплексной проверки подлинности только в том случае, если установлено приложение, которое поддерживает динамический контроль доступа, а также «Никогда», что приравнивается к отключенному параметру политики. Диалоговое окно данного параметра политики вы можете увидеть ниже:

Kerberos3-04

Рис. 3. Поддержка комплексной проверки подлинности

Хотите ли вы знать больше?

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

Следующая статья данного цикла будет полностью посвящена делегированию проверки подлинности, включая нововведения в ограниченном делегировании, появившиеся в Windows Server 2012.

Pin It

2 thoughts on “Сетевой протокол аутентификации Kerberos или зачем нужны утверждения

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *

    Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.