Время обновления билета kerberos для уз компьютера

Обновлено: 06.07.2024

Kerberos, автоматическое обновление билета. (По истечении срока жизни билета, доступ к шарам в AD прекращается.)

Модератор: SLEDopit

Kerberos, автоматическое обновление билета.

Настроил по многочисленным мануалам аутентификацию и авторизацию пользователей Linux-машины в AD средствами samba, winbind и kerberos. Собственно в целом всё работает, но возникла пара вопросов.
Билет Керберос имеет конечный срок жизни (определяется параметром ticket_lifetime в файле krb5.conf), затем должен производиться запрос нового билета (интервал определяется параметром renew_lifetime в файле krb5.conf). Так вот новый билет по прошествии указанного временного интервала не выдаётся, появляется лишь 2-ой билет в момент первого входа на любую шару, команда klist показывает, что срок жизни нового билета истекает в то же время как и у выданного ранее. Это так задумано ? (или мне надо раскурить man kerberos) или же по-хорошему билеты должны обновляться до посинения, то есть пока пользователь не выполнит logout . Насколько я понял, немного погуглив :-) , керберос предполагает выдачу временного билета. Но в чём тогда смысл указания интервала перезапроса билета ? не для продления ли действия без необходимости производить повторную аутентификацию ?

$ klist
Ticket cache: FILE:/tmp/krb5cc_10003_NbK4Fu
Default principal: user1@WIN2003.LAN

Valid starting Expires Service principal
05/23/09 23:47:12 05/24/09 00:17:12 krbtgt/WIN2003.LAN@WIN2003.LAN
renew until 05/24/09 00:17:12
05/23/09 23:52:39 05/24/09 00:17:12 w2k3$@WIN2003.LAN
renew until 05/24/09 00:17:12

Kerberos 4 ticket cache: /tmp/tkt10003
klist: You have no tickets cache

Вопрос2: При тех же условиях, после прохождения аутентификации в домене, Гномовский nautilus благополучно пускает на все шары Windows2003-сервера, на которые для данного пользователя предоставлен доступ, не запрашивая пароль, но по истечении времени жизни билета, если шара не была ранее подмонтирована, попытка входа на шару приводит к запросу пароля. Заметил, что если выполнить блокировку компьютера, а затем разблокировать - выдаётся новый ключ и вновь появляется доступ к шарам без запроса пароля.

Это событие создает каждый раз, когда Центр рассылки ключей выдает билет на предоставление билетов Kerberos (TGT).

Это событие создается только на контроллерах домена.

Если проблема TGT не удается, вы увидите событие сбой с полем кода результатов, не равное "0x0".

Это событие не создает коды результатов: 0x10 и 0x18. Событие"4771:предварительная проверка подлинности Kerberos не удалось". создает вместо этого.

Рекомендации см. в Рекомендации мониторинга безопасности для этого события.

XML события:

Необходимые роли сервера: Контроллер домена Active Directory.

Минимальная версия ОС: Windows Server 2008.

Версии события: 0.

Описания полей:

Сведения о учетной записи:

Имя учетной записи [Type = UnicodeString]: имя учетной записи, для которой запрашивался билет TGT. Имя учетной записи компьютера заканчивается $ символом.

Пример учетной записи пользователя: dadmin

Пример учетной записи компьютера: WIN81$

Предоставлено имя realm [Type = UnicodeString]: имя области Kerberos, к которой принадлежит имя учетной записи. Это может отображаться в различных форматах, включая следующие:

Пример имени домена NETBIOS: CONTOSO

Полное имя домена в нижнем регистре: contoso.local

Полное имя домена в верхнем регистре: CONTOSO.LOCAL

Kerberos Realm — это набор управляемых узлов с одной и той же базой данных Kerberos. База данных Kerberos расположена в компьютерной системе Master Kerberos, которая должна храниться в физически безопасной комнате. Домен Active Directory — пример Области Kerberos в мире Microsoft Windows Active Directory.

Пользовательский ID [Type = SID]: SID учетной записи, для которой запрашивался билет TGT. Средство просмотра событий автоматически пытается разрешить идентификатор безопасности SID и отобразить имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.

Например: CONTOSO\dadmin или CONTOSO\WIN81$.

NULL SID — это значение показывается в событиях 4768 отказов.

Идентификатор безопасности (SID) — это уникальное значение переменной длины, используемое для идентификации доверяемого (доверителем безопасности). Каждая учетная запись имеет уникальный идентификатор безопасности, выданный центром сертификации, таким как контроллер домена Active Directory, который хранится в базе данных безопасности. Каждый раз, когда пользователь входит в систему, система получает идентификатор безопасности этого пользователя из базы данных и помещает ее в маркер доступа этого пользователя. Система использует идентификатор безопасности в маркере доступа для идентификации пользователя во всех последующих операциях с Безопасностью Windows. Если идентификатор SID использовался как уникальный идентификатор для пользователя или группы, он не может использоваться повторно для идентификации другого пользователя или группы. Дополнительные сведения о SID см. в разделе Идентификаторы безопасности.

Сведения о службе:

Имя службы [Type = UnicodeString]: имя службы в области Kerberos, в которую был отправлен запрос TGT. Обычно имеет значение "krbtgt" для запросов TGT, что означает службу выдачи билетов.

Для событий сбоя имя службы обычно имеет следующий формат: krbtgt/REALM_NAME. Например: krbtgt/CONTOSO.

Service ID [Type = SID]: SID учетной записи службы в области Kerberos, в которую был отправлен запрос TGT. Средство просмотра событий автоматически пытается разрешить идентификатор безопасности SID и отобразить имя учетной записи. Если идентификатор безопасности разрешить не удается, в событии будут отображены исходные данные.

Контроллеры домена имеют определенную учетную запись службы (krbtgt), которая используется службой Центра рассылки ключей (KDC) для выдачи билетов Kerberos. Он имеет встроенный, предварительно определенный SID: S-1-5-21-DOMAIN_IDENTIFIER -502.

NULL SID — это значение показывается в событиях 4768 отказов.

Сведения о сети:

Клиентский адрес [Type = UnicodeString]: IP-адрес компьютера, с которого был получен запрос TGT. Форматы различаются и включают в себя следующее:

Адрес IPv6 или IPv4.

::ffff:IPv4_address.

::1 - localhost.

Клиентский порт [Type = UnicodeString]: исходный номер порта клиентского сетевого подключения (подключение запроса TGT).

Дополнительные сведения:

Параметры билетов [Type = HexInt32]: это набор различных флагов билетов в гексадецимальной форме.

Параметры билетов: 0x40810010

Двоичное представление: 01000000100000010000000000010000

С помощью набора номеров MSB 0 у нас есть набор 1, 8, 15 и 27 = Forwardable, Renewable, Canonicalize, Renewable-OK.

В таблице ниже используется номер "MSB 0", так как в документах RFC используется этот стиль. В стиле "MSB 0" число битов начинается слева.

Наиболее распространенные значения:

0x40810010 - Forwardable, Renewable, Canonicalize, Renewable-OK

0x40810000 — переадвочная, возобновляемая, каноническая

0x60810010 - Forwardable, Forwarded, Renewable, Canonicalize, Renewable-OK

Таблица2. Флаги билетов Kerberos

KILE (Расширение протокола Microsoft Kerberos) — расширения протоколов Kerberos, используемые в операционных системах Майкрософт. Эти расширения предоставляют дополнительные возможности для получения сведений о авторизации, включая членство в группе, интерактивные сведения о логотипах и уровни целостности.

Код результатов [Type = HexInt32]: hexadecimal result code of TGT issue operation. Таблица 3. TGT/TGS выдают коды ошибок". содержит список наиболее распространенных кодов ошибок для этого события.

Табл.3. Коды ошибок TGT/TGS

Тип шифрования билетов [Type = HexInt32]: криптографический набор, который использовался для выпуска TGT.

Таблица4. Типы шифрования Kerberos

Тип предварительной проверки подлинности [Type = UnicodeString]: номер кода типа предварительной проверки подлинности, который использовался в запросе TGT.

Таблица 5. Типы предварительной проверки подлинности Kerberos

Тип	Имя типа	Описание
0	-	Logon без предварительной проверки подлинности.
2	PA-ENC-TIMESTAMP	Это обычный тип для проверки подлинности стандартного пароля.
11	PA-ETYPE-INFO	Тип предварительной проверки подлинности ETYPE-INFO отправляется КДК в KRB-ERROR, указывающее требование о дополнительной предварительной проверке подлинности. Обычно он используется для уведомления клиента о том, какой ключ используется для шифрования зашифрованного времени для отправки значения предварительной проверки подлинности PA-ENC-TIMESTAMP. Никогда не видел этот тип предварительной проверки подлинности в среде Microsoft Active Directory.
15	PA-PK-AS-REP_OLD	Используется для проверки подлинности логотипа смарт-карты.
16	PA-PK-AS-REQ	Запрос, отправленный в KDC в сценариях проверки подлинности смарт-карт.
17	PA-PK-AS-REP	Этот тип также следует использовать для проверки подлинности смарт-карт, но в некоторых средах Active Directory его никогда не видели.
19	PA-ETYPE-INFO2	Тип предварительной проверки подлинности ETYPE-INFO2 отправляется КДК в KRB-ERROR, указывающее требование о дополнительной предварительной проверке подлинности. Обычно он используется для уведомления клиента о том, какой ключ используется для шифрования зашифрованного времени для отправки значения предварительной проверки подлинности PA-ENC-TIMESTAMP. Никогда не видел этот тип предварительной проверки подлинности в среде Microsoft Active Directory.
20	PA-SVR-REFERRAL-INFO	Используется в билетах KDC Referrals.
138	PA-ENCRYPTED-CHALLENGE	Logon using Kerberos Armoring (FAST). Поддерживается начиная с Windows Server 2012 контроллеров домена и Windows 8 клиентов.
-	Этот тип показан в событиях сбоя аудита.

Сведения о сертификате:

Имя эмитента сертификата [Type = UnicodeString]— имя органа сертификации, выдав сертификат смарт-карты. Заполнено в Выданном полем в сертификате.

Серийный номер сертификата [Type = UnicodeString]: серийный номер сертификата смарт-карты. Можно найти в поле Серийный номер в сертификате.

Thumbprint сертификата [Type = UnicodeString]: отпечатки пальцев сертификата смарт-карты. Можно найти в поле Thumbprint в сертификате.

Рекомендации по контролю безопасности

Для 4768 (S, F): запрашивался билет на проверку подлинности Kerberos (TGT).

Вы можете отслеживать все события 4768, в которых клиентский адрес не из вашего внутреннего диапазона IP-адресов или не из частных диапазонов IP-адресов. ****

Если вы знаете, что имя учетной записи следует использовать **** только из известного списка IP-адресов, отслеживайте все значения клиентского адреса для этого имени учетной записи в **** событиях 4768. Если клиентский адрес не из списка допуска, сгенерировать оповещение.

Все клиентские адреса = ::1 означает локализованную проверку подлинности. Если вы знаете список учетных записей, которые должны войти в контроллеры домена, необходимо отслеживать все возможные **** нарушения, при которых клиентский адрес = ::1 и имя учетной записи не разрешается войти в любой контроллер домена.

Все 4768 **** событий со значением полей клиентского порта 0 и > 1024 должны быть рассмотрены, так как для исходяшего подключения использовался хорошо известный < порт.

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

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Для начала проведем небольшой ликбез по терминологии Kerberos и рассмотрим доступные реализации этого протокола в ОС на базе GNU/Linux. Сразу оговорюсь, что мне не удалось найти однозначного перевода терминов, использующихся в Kerberos, поэтому для избежания путаницы основные термины я буду дублировать на английском.
Итак, начнем. Если процитировать Википедию, то

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

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

На клиенте и сервере:

/etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

Настройка сети

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

krb5-kdc – сервис KDC
krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

Базовые настройки

После установки пакетов на сервере нужно инициализировать realm командой
А на клиенте – обновить файлы конфигурации:
Также на клиенте и сервере надо добавить следующие строки в /etc/krb5.conf:
Теперь создадим на сервере нового пользователя c именем testuser
На клиенте теперь можно проверить, правильно ли мы настроили сеть и Kerberos:

Настройка аутентификации по открытому ключу

Для работы модуля pkinit нам придется воспользоваться openssl в качестве мини-УЦ, чтобы создать ключевые пары и сертификаты клиента и сервера.

На сервере:

Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
otherName – поле, задающее нашего принципала, для которого выписывается сертификат

kdc.pem
kdckey.pem
cacert.pem

Дальнейшие действия будем выполнять на клиенте

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду
и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

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

Почем не отрабатывает команда "kinit --renew"

sudo писал(а):
КОД: ВЫДЕЛИТЬ ВСЁ * */1 * * * root /usr/bin/kinit --renew > /dev/null 2>&1
Не подойдёт, так как kinit требует введения пароля, что в использовании Cron невозможно.

У меня китайская FreeBSD, в ней все возможно.

Issued Expires Principal
May 11 09:49:51 >>>Expired<<< krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

Вводим тупо. Не дает обновиться.

Оно и понятно почему - потому, что хоть иногда надо читать маны.

-R, --renew
Try to renew ticket. The ticket must have the `renewable' flag
set, and must not be expired.

Возьмем новый билет и ставим флаг

Обновим билет пару раз для наглядности (прошу заметить, что никаких паролей не требуется)

Issued Expires Principal
Jun 16 08:21:11 Jun 16 18:21:11 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL

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

Вы бы лучше другую мою ошибку заметили, что написав команду под рутом crontab -e в конфигурации cron'a я указал root , что возможно только при правке системного crontab

Авторизация FreeBSD heimdal в AD используя ключи. (Согласен с автором . 3 вариант самый оптимальный, но FreeNAS после ребута не хотел принимать старый билетик и приходилось опять же ручками получать новый)

Статья написана в стиле "пометка что-бы не забыть", многие моменты подразумеваются известными и акцент делается на "подводные камни". В интернете по этому вопросу увы ничего не нашел, так же бьються над аналогичными проблемами ребята из Juniper Networks (не подсоединяет к домену) и IBM ( не получает список пользователей).

Для того, что бы службы на FreeBSD могли получать TGS (Ticket Granting Service - тикет на доступ к службе)
от Active Directory Key Distribution Center необходимо что бы в системе FreeBSD был TGT (Ticket Granting Ticket - тикет на получение тикетов).

В стандартном варианте настройке родного Kerberos (Heimdal 0.x_чего_то_там) на FreeBSD (вплоть до версии 7.1.) используется файл

/etc/krb5.conf [man krb5.conf]

и в файле-кеше ключей (обычно /tmp/krb5cc_0, т.к. все делается из под рута) появляется TGT, используя который
другие службы (pam_krb5, ldap, samba) могут обращаться к службам AD.

Для автоматизации получения ключа используются разные методы. Все они используют cron, для периодического получения/обновления ключа.

1.) Самый простой это

КОД: ВЫДЕЛИТЬ ВСЁ echo MyPassword | kinit DomainAdministrator

Метод прост, но "светит пароль" администратора, что не является хорошим тоном.

2.) Второй способ описан в статье Microsoft "Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability"
Заключается метод в следующем: создается пользовательский аккаунт, через который будет авторизоваться сервер.
С использованием команды из пакета Windows Resource Kit или Windows Support Tools

КОД: ВЫДЕЛИТЬ ВСЁ C:>Ktpass.exe -princ HOST/my_bsd_hostname@NT-DNS-REALM-NAME -mapuser user_account_for_bsd -pass account_password_for_bsd -out unixmachine.keytab

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

КОД: ВЫДЕЛИТЬ ВСЁ kinit -k HOST/my_bsd_hostname@NT-DNS-REALM-NAME

3.) Наиболее элегантный.

Для получения ключей используется Samba 3.xx, которая чаще всего используется в связке с Active Directory.
Метод также подразумевает получение ключей в /etc/krb5.keytab и авторизацию через
КОД: ВЫДЕЛИТЬ ВСЁ kinit -k

для получения ключей наобходимо использовать

КОД: ВЫДЕЛИТЬ ВСЁ net -U DomainAdministrator net ads keytab ADD HOST

эта команда получает ключи в файл (по умолчанию) /etc/krb5.keytab
КОД: ВЫДЕЛИТЬ ВСЁ Vno Type Principal
5 des-cbc-crc HOST/my_bsd_hostname@NT-DNS-REALM-NAME
5 des-cbc-md5 HOST/my_bsd_hostname@NT-DNS-REALM-NAME
5 arcfour-hmac-md5 HOST/my_bsd_hostname@NT-DNS-REALM-NAME
Требования: Реализация Kerberos на FreeBSD heimdal не использует (пока что) tcp для Kerberos запросов, поэтому пользователь
DomainAdministrator должен быть в одной единственной группе (Domain Admins) и по возможности в самом верхнем OU.
Иначе будут ошибки

КОД: ВЫДЕЛИТЬ ВСЁ response too big for UDP, use TCP instead

Получив ключи, следует произвести некоторые магические действия с Active Directory.
В моем случае был Microsoft Windows Server 2008 Enterprise SP1, по традиции при его выпуске была допущена ошика
в реализации kerberos из-за чего при использовании

КОД: ВЫДЕЛИТЬ ВСЁ kinit -k HOST/my_bsd_hostname@NT-DNS-REALM-NAME

Microsoft Windows Server 2008 всех версиий возвращает KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN из-за неправильной
интерпретации косой черты ("/") в имени принципала.
Лечится это частным патчем от Microsoft [KB951191], который Microsoft почему то высылает только по запросу
на электронный адрес, да еще в придачу защифрованным паролем. (актуально на 15.05.2009)

Далее для авторизации через kinit к сожалению не используется аттрибут serivcePrincipalName объекта
типа Computer, который создается при подключении Samba к домену и чьи ключи Samba помещает в /etc/krb5.keytab.
Для того, что бы этот аккаунт использовался для авторизации необходимо сделать два вещи

а.) установить аттрибут userPrincipalName в HOST/my_bsd_hostname@NT-DNS-REALM-NAME (по умолчанию он пуст для объекта Computer)
б.) установить отметку "Без предварительной проверки Kerberos". Это легче сказать чем сделать, т.к. диалоговое окно для таких
манипуляций доступно только для объектов типа User. Отметка это лишь бит в целом числе, поэтому.
Я использовал ADSI Edit (входит в поставку Windows Server 2008) для правки аттрибута userAccountControl объекта типа Computer, представляющего
FreeBSD в домене:

КОД: ВЫДЕЛИТЬ ВСЁ userAccountControl = 0x411000 (4263936 decimal) [ WORKSTATION_TRUST_ACCOUNT | DONT EXPIRE PASSWD | DONT REQUIRE PREAUTH ]

После установки патча, манипуляций с объектов Computer account, представляющего FreeBSD и прописав в cron

КОД: ВЫДЕЛИТЬ ВСЁ 0 * * * * /usr/bin/kinit --renew
* 2 * * * /usr/bin/kinit -k HOST/my_bsd_hostname@NT-DNS-REALM-NAME

Server: krbtgt/NT-DNS-REALM-NAME@NT-DNS-REALM-NAME
Ticket etype: arcfour-hmac-md5, kvno 2
Auth time: May 19 11:10:22 2009
End time: May 19 21:10:22 2009
Renew till: May 26 11:10:22 2009
Ticket flags: forwardable, renewable, initial

Читайте также: