Изучаем принцип работы неimdal kerberos

Key Distribution Center, KDC (или TGS — ticket granting server)

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

Обращение клиента к серверу через KDC

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

Сеансовые мандаты

В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа, общего для данного клиента и KDC, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового мандата («session ticket»). Затем сеансовый мандат целиком шифруется с помощью долговременного ключа, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку мандата, несущего в себе шифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер. Получив ответ KDC, клиент извлекает из него мандат и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из мандата, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот мандат в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет «личность» клиента.
Сервер, получив «удостоверение личности» клиента, прежде всего с помощью своего секретного ключа расшифровывает сеансовый мандат и извлекает из него сеансовый ключ, который затем использует для дешифрования аутентификатора клиента. Если все проходит нормально — делается заключение, что удостоверение клиента выдано доверенным посредником, то есть — службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает её клиенту в качестве собственного аутентификатора.
Одно из достоинств применения сеансовых мандатов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений («credentials cache») клиента, который направляет мандат на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента мандат, дешифрует его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти.
Такой метод дает и ещё одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые мандаты можно использовать многократно. На случай же их хищения устанавливается срок годности мандата, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретной области. Обычно срок годности мандатов не превышает восьми часов, то есть — стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от неё, кэш-память удостоверений обнуляется, и все сеансовые мандаты вместе с сеансовыми ключами уничтожаются.

Drawbacks and limitations

• Single point of failure: It requires continuous availability of a central server. When the Kerberos server is down, new users cannot log in. This can be mitigated by using multiple Kerberos servers and fallback authentication mechanisms.
• In case of symmetric cryptography adoption (Kerberos can work using symmetric or asymmetric (public-key) cryptography), since all authentications are controlled by a centralized key distribution center (KDC), compromise of this authentication infrastructure will allow an attacker to impersonate any user.
• Each network service which requires a different host name will need its own set of Kerberos keys. This complicates virtual hosting and clusters.
• Kerberos requires user accounts and services to have a trusted relationship to the Kerberos token server.
• The required client trust makes creating staged environments (e.g., separate domains for test environment, pre-production environment and production environment) difficult: Either domain trust relationships need to be created that prevent a strict separation of environment domains or additional user clients need to be provided for each environment.

Синхронизация времени

Протокол Kerberos требует соответствия показаний часов всех клиентов и серверов, и при рассинхронизации часов аутентификация становится невозможной.Простой и стандартный путь обеспечения синхронизации — использование сервиса Network Time Protocol (NTP).

Установка пакета (сервер)

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

apt install krb5-kdc krb5-admin-server krb5-user

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

Настройка пакета (сервер Kerberos)

При установке пакета будет создан файл конфигурации сервиса /etc/krb5kdc/kdc.conf со стандартным содержимым, в котором автоматически будет указано имя области Kerberos, полученное из FQDN сервера, на котором выполняется установка:

Kerberos использует для контроля доступа к администрированию сервиса Списки Управления Доступом (Access Control List, ACL) .По умолчанию, список располагается в файле /etc/krb5kdc/kadm5.acl.

Для примера, создадим файл /etc/krb5kdc/kadm5.acl, дающий неограниченные права любому принципалу, чьё  имя заканчивается на /admin:

И создадим новую область Kerberos командой:

krb5_newrealm

Далее, для выполнения задач по администрированию сервиса Kerberos нужно создать принципала с правами администратора.Для этого используем инструмент командной строки kadmin.local, предназначенный для администрировния Kerberos на локальном компьютере.

Инструмент вызывается из командной строки командой 

После вызова инструмента можно ввести симовл «вопросительный знак», в ответ на это будет выдана подсказка по списку команд.

Добавим нового принципала admin/admin командой addprinc:

После ввода команды будет запрошен пароль для создаваемого принципала.

Выход из инструмента kadmin.local осуществляется командой quit.

После создания принципала admin/admin его можно использовать для администрирования сервера Kerberos с удалённых компьютеров с помощью инструмента командной строки  kadmin.Этот инструмент аналогичен инстрменту kadmin.local, однако рассчитан на удалённое подключение, и требует авторизации пользователя через указание принципала и ввод пароля:

kadmin -p admin/admin

Настройка DNS для автоматизации подключения клиентов

Для автоматического получения клиентами адреса сервера Kerberos можно использовать специальные настройки сервера DNS: служебные записи (SRV-записи).Пример таких записей для службы Kerberos см. в статье про сервер DNS

Установка пакетов (клиент)

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

apt install krb5-user

Настройка клиентов

Настройка клиента Kerberos выполняется командой

dpkg-reconfigure krb5-config

• Попросит указать имя домена (в нашем примере — ASTRADOMAIN.RU);
• Задаст вопрос о необходимости указать сервер(ы) Kerberos в файле конфигурации клиента /etc/krb5.conf.Если ответить «да», то программа попросит ввести имена сервера (серверов) Kerberos Если DNS уже настроен (см «Настройка DNS для автоматизации подключения клиентов»), можно просто ответить «нет».

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

kinit admin/admin
klist

Настройка авторизации клиентов через Kerberos

Для обеспечения возможности авторизации пользователей через Kerberos требуется дополнительно установить пакет libpam-krb5:

apt install libpam-krb5

Задаем прокси-сервер в Internet Explorer 11 с помощью GPO

В этой статье я покажу, как для всех пользователей домена установить одинаковые настройки прокси-сервера в браузере Internet Explorer 11 с помощью групповых политик (GPO) Active Directory.

В более ранних версиях Internet Explorer (версии 6, 7 и 9) настройка параметров Internet Explorer осуществлялась в следующем разделе редактора групповых политик: User configuration -> Policies -> Windows Settings -> Internet Explorer Maintenance. Однако в Internet Explorer 10 (представленном в Windows Server 2012 и Windows 8) разработчики удалили раздел Internet Explorer Maintenance (IEM) из редактора GPO. Кроме того, этот раздел также исчезает и в Windows 7 / Windows Server 2008 R2 после установки Internet Explorer 10 или 11. И даже если на компьютер с IE 10 или 11 продолжает действовать старая доменная политика с IEM, имейте в виду, что реально она не работает.

Совет. В январе 2016 года Microsoft объявила о завершении поддержки всех старых версий Internet Explorer. Таким образом, Iinternet Explorer 11 стал единственной поддерживаемой версией в семействе IE, для которой выпускаются обновления и патчи (А вы уже обновили IE на всех ПК до 11 версии?).

Теперь для управления настройками Internet Explorer необходимо использовать предпочтения групповых политик (GPP — Group Policy Preferences) или расширение Internet Explorer Administration Kit 11 (IEAK 11). Итак, чтобы задать прокси-сервер для IE 11 через предпочтения групповых политик, выполните следующие действия:

1. Откройте консоль редактора Group Policy Management Console (GPMC.msc) на компьютере с Windows 8 / 10 / Server 2012/ R2 и создайте новый или отредактируйте существующий объект GPO, который применяется к пользователям домена (или OU с пользователями). Перейдите в раздел User Configuration -> Preferences -> Control Panel Settings -> Internet Settings . Щелкните ПКМ по разделу и в контекстном меню выберите New-> Internet Explorer 10 (данная политика будет применятся ко всем версиям IE, начиная с IE 10 и выше).
2. В окне, внешним видом повторяющим локальные настройки браузера IE, перейдите на вкладку Connections и нажмите кнопку LAN Settings
3. Поставьте галку “Use a proxy server for your LAN” и укажите IP адрес и TCP порт вашего прокси сервера (например, 192.168.1.11:3128). Чтобы активировать эту настройку нажмите клавишу F5 (в результате цвет подчеркивания в названии поля поля сменился с красного на зеленый цвет). Обратное действие – отключение параметра производится с помощью клавиши F7.
4. Если нужно задать список исключения для прокси сервера, необходимо нажать на кнопку Advanced. В открывшемся окне в поле Do not use proxy servers for addresses beginning with нужно через точку с запятой (;) указать список IP адресов или доменов, для доступа к которым не нужно использовать прокси сервер, например: 192.*;*.vmblog.ru
5. Сохраните изменения, нажав дважды ОК.

Примечание. Данное правило GPP будет применяться только для IE 10 и 11, если у вас в сети остались компьютеры с более старой версией Internet Explorer, для них по аналогии нужно создать отдельные правила GPP.

Осталось назначить данный объект GPO на нужный контейнер Active Directory с пользователями, обновить групповые политики на клиентских компьютерах ( gpupdate /force ) и проверить, что в настройках IE у пользователей выставились указанные вами параметры прокси-сервера.

Совет. Чтобы новые политики с настройками IE можно было редактировать из ОС Windows Server 2008 или 2008 R2, нужно скачать Administrative Templates for Internet Explorer и скопировать файлы Inetres.admx и Inetres.adml в локальный каталог %SYSTEMROOT%\PolicyDefinitions\

Кроме того, задать параметры прокси можно напрямую через реестр. Воспользуемся другой возможностью GPP. В редакторе GPO перейдите в раздел User Configuration -> Preferences -> Registry и в ветке HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings создайте три параметра реестра со следующими значениями:

источник

10.7.3 Сервер Kerberos с сервисами Heimdal

Для начала нам потребуется копия файла настройки
Kerberos,
/etc/krb5.conf.
Просто скопируйте его с KDC на клиентский
компьютер безопасным способом (используя сетевые утилиты, такие
как scp(1), или физически, с помощью дискеты).

Затем вам понадобится файл /etc/krb5.keytab.
Это основное различие между сервером, поддерживающим
Kerberos и рабочими станциями —
на сервере должен быть файл keytab.
В этом файле находится центральный ключ сервера, который позволяет
KDC проверять все другие идентификаторы. Он
должен быть помещен на сервер безопасным способом, поскольку
безопасность сервера может быть нарушена, если ключ станет
общедоступен. Это означает, что его передача через незашифрованный
канал, такой как FTP — очень плохая
идея.

Обычно перенос файла keytab на сервер
производится с помощью программы kadmin.
Это удобно, поскольку вам потребуется также создать запись хоста
(KDC часть krb5.keytab)
с помощью kadmin.

Обратите внимание, что должны быть уже зарегистрированы в
системе и необходимо наличие прав на использование интерфейса
kadmin в файле kadmind.acl.
Обратитесь к разделу «Remote administration» в info
страницах Heimdal (info heimdal) за деталями по
составлению списка доступа. Если вы не хотите включать удаленный
доступ kadmin, можете просто подключиться к
KDC через защищенное соединение (локальную
консоль, ssh(1) или Kerberos
telnet(1)) и выполнять администрирование локально с помощью
kadmin -l

После добавления файла /etc/krb5.conf,
вы можете использовать kadmin с сервера
Kerberos. Команда
add --random-key позволит вам добавить запись
для сервера, а команда ext позволит перенести
эту запись в собственный keytab файл сервера. Например:

# kadmin
kadmin> add --random-key host/myserver.example.org
Max ticket life :
Max renewable life :
Attributes []:
kadmin> ext host/myserver.example.org
kadmin> exit

Обратите внимание, что команда ext
(сокращение от «extract») сохраняет полученный ключ в
файле /etc/krb5.keytab по умолчанию. Если на KDC не запущен
kadmind (возможно по соображениям безопасности)
и вы не можете получить доступ к kadmin
удаленно, возможно добавление записи хоста
(host/myserver.EXAMPLE.ORG) непосредственно
на KDC с последующим извлечением ее во временный
файл (и перезаписью /etc/krb5.keytab на
KDC) примерно так:

Если на KDC не запущен
kadmind (возможно по соображениям безопасности)
и вы не можете получить доступ к kadmin
удаленно, возможно добавление записи хоста
(host/myserver.EXAMPLE.ORG) непосредственно
на KDC с последующим извлечением ее во временный
файл (и перезаписью /etc/krb5.keytab на
KDC) примерно так:

# kadmin
kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
kadmin> exit

Затем вы можете скопировать keytab на сервер защищенным способом
(например, используя scp или дискету).
Убедитесь, что используемое имя keytab не совпадает с именем
по умолчанию во избежание перезаписывания keytab на
KDC.

Теперь ваш сервер может связываться с KDC
(добавлен файл krb5.conf) и идентифицировать
себя (добавлен файл krb5.keytab). Теперь вы
готовы к включению некоторых сервисов
Kerberos. В этом примере мы включим
сервис telnet, поместив в
/etc/inetd.conf нижеприведенную строку и
перезапустив сервис inetd(8) командой
/etc/rc.d/inetd restart:

telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user

Can Kerberos Be Hacked?

Yes. Because it is one of the most widely used authentication protocols, hackers have developed several ways to crack into Kerberos. Most of these hacks take advantage of a vulnerability, weak passwords, or malware – sometimes a combination of all three. Some of the more successful methods of hacking Kerberos include:

• Pass-the-ticket: the process of forging a session key and presenting that forgery to the resource as credentials
• Golden Ticket: A ticket that grants a user domain admin access
• Silver Ticket: A forged ticket that grants access to a service
• Credential stuffing/ Brute force: automated continued attempts to guess a password
• Encryption downgrade with Skeleton Key Malware: A malware that can bypass Kerberos, but the attack must have Admin access
• DCShadow attack: a new attack where attackers gain enough access inside a network to set up their own DC to use in further infiltration