Как установить kerberos windows

Обновлено: 04.07.2024

В данной инструкции описывается настройка аутентификации пользователей на веб-прокси через протокол Kerberos.

Данный функционал особенно актуален в доменной среде Active Directory (AD), где данная технология позволяет реализовать аутентификацию в стиле Single Sign On (SSO).

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

Настройка SSO аутентификации в Active Directory состоит из нескольких этапов:

Для дальнейшей настроки примем следующие значения:

домен Active Directory

контроллер домена Active Directory

dc.ztest.int (Windows Server 2016)

IP адрес контроллера домена Active Directory

имя устройства TING

IP адрес устройства TING

Установка, настройка контроллера домена, а также разворачивание домена Active Directory должна осуществляться компетентными специалистами согласно документации. Мы предполагаем, что такая настройка уже выполнена согласно предоставленных выше данных.

Настройка домена Active Directory.¶

Создайте на доменном DNS-сервере нужные ресурсные записи для узла TING.

ting IN A 192.168.0.2 в прямой зоне ting.local 2.1.168.192.in-addr.arpa IN PTR ting.ztest.int. в обратной зоне 1.168.192.in-addr.arpa

Проверьте правильность введенных данных, выполнив следующие команды в терминале Windows:

Создайте учетную запись пользователя с правами, достаточными для выполнения LDAP запросов.

Задайте даной учетной записи пароль и установите флажок Срок действия пароля неограничен.

Примечание

Данная учетная запись нам понадобится для настройки LDAP коннектора на устройстве TING.

Настройка устройства TING.¶

1. Настройка имени устройства и DNS¶

Установить флаг Не используйте локальную службу DNS в качестве сервера имен для этой системы
В поле DNS-серверы прописать IP адрес контроллера домена ( 192.168.1.3 )

2. Настройка сетевого времени¶

Перейдите в раздел Службы -> Сетевое время -> Общие.

В поле Серверы времени укажите имя контроллера домена dc.ztest.int либо IP адрес контроллера домена 192.168.1.3 .

Примечание

Время на контроллере домена и устройстве TING должно быть синхронизированно.

3. Настройка LDAP коннектора¶

Пройдите в раздел Система -> Доступ -> Серверы, в правом верхнем углу нажмите на кнопку Добавить сервер и задайте следующие настройки:

Описательное имя	INT-DC
Тип	LDAP
Имя хоста или IP-адрес	192.168.1.3
Значение порта	389
Транспортный протокол	TCP
Версия протокола	3
Привязать параметры доступа	имя и пароль 1
Область поиска	Единичный уровень
Базовый DN	DC=ztest,DC=int
Контейнеры для аутентификации	CN=Users,DC=ztest,DC=int 2
Начальный шаблон	Microsoft AD
Атрибут присвоения имени пользователю	sAMAccountName

имя и пароль учетной записи, созданной при настроке домена для создания LDAP коннектора.

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

4. Проверка LDAP коннектора¶

5. Настройки веб-прокси¶

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Основные настройки прокси, установите флаг Включить прокси, если он еще не установлен.

В разделе Службы -> Веб-прокси -> Администрирование, на вкладке Перенаправляющий прокси -> Настройка Аутентификации, в поле Метод аутентификации укажите ваш настроенный LDAP-коннектор.

6. Установка плагина os-proxy-sso¶

Пройдите в раздел Система -> Прошивка -> Обновления. На вкладке Плагины нажмите на кнопку + напротив плагина os-proxy-sso для его установки.

После установки плагина os-proxy-sso, в разделе Службы -> Веб-прокси появляется подраздел Технология единого входа (SSO).

Настройка аутентификации по протоколу Kerberos может быть осуществлена как вручную, так и автоматически. Предпочтительным является автоматический способ настройки, рассмотренный в п.7. Ручной способ настройки аутентификации по протоколу Kerberos рассматривается в п.8.

7. Автоматическая настройка аутентификации по протоколу Kerberos¶

7.1 Включите Single Sign On

В разделе Службы -> Веб-прокси -> Технология единого входа (SSO), на вкладке Общие настройки, установите флаг Включить единый вход для прокси-сервера.

При необходимости вы можете включить/выключить использование Basic аутентификации, установив/сняв соответствующий флажок Basic Autentification 3

Данная схема аутентификации (Basic) используется для аутентификации пользователей, чьи компьютеры не являются членами домена путем ввода пароля в сплывающем окне браузера.

Если вы отключите Basic аутентификацию, то пользователи, чьи компьютеры не входят в домен, не будут обслуживаться прокси-сервером.

В поле Реализация AD Kerberos выберите значение Windows 2008 with AES.

При нажатии на кнопку Применить будут произведены следующие действия:

происходит автогенерация конфигурационного файла krb5.conf для библиотеки Kerberos

модифицируется конфигурационный файл Squid /usr/local/sbin/squid.conf для загрузки хелпера Kerberos-аутентификации negotiate_kerberos_auth

производится перезапуск веб-прокси сервера Squid

7.2 Настройте аутентификацию по протоколу Kerberos

Перейдите в раздел Службы -> Веб-прокси -> Технология единого входа (SSO) -> Аутентификация по протоколу Kerberos и нажмите кнопку Обновить

Все пункты, кроме Файл keytab должны быть отмечены зеленым.

Если это не так - перепроверьте все шаги.

Создайте учетную запись компьютера с необходимыми SPN в Active Directory:

В поле Имя администратора AD, укажите имя учетной записи администратора домена.

В поле Пароль администратора AD, укажите пароль для учетной записи администратора домена.

Нажмите на кнопку Создать keytab-файл.

создается учетная запись компьютера с именем, указанным на закладке Общие
прописываются необходимые SPN-имена
генерируется keytab-файл /usr/local/etc/squid/squid.keytab на устройстве TING c SPN-именами / ключами для керберизированной службы

Перед созданием keytab файла на контроллере домена не должно быть учетной записи компьютера для устройства TING. Иначе при создании keytab будет ошибка. Если по какой-то причине необходимо пересоздать keytab, то перед его созданием учетную запись компьютера для TING нужно удалить.

Все пункты должны быть отмечены зеленым.

Если это не так - перепроверьте все шаги.

Результат должен быть такой:

7.3 Проверьте правильность настроек.

Для этого введите Имя пользователя и Пароль пользователя домена в соответствующие поля и нажмите Проверить вход через Kerberos

В случае, если все настройки были сделаны верно, вы увидите положительный результат проверки, подобный, как на изображении выше.

7.4 Примените настройки.

Для этого либо в разделе Службы -> Веб-прокси -> Технология единого входа (SSO), на вкладке Общие настройки, либо в разделе Службы->Веб-прокси->Администрирование нажмите кнопку Применить

8. Ручная настройка аутентификации в Active Directory через Kerberos¶

Иногда возникает ситуация, когда по определенным причинам у вас нет доступа к учетной записи администратора домена (к примеру, политики безопасности предприятия).

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

Для ручной настройки аутентификации в Active Directory через Kerberos вам необходимо выполнить все шаги по настройке устройства TING , описанные выше, вплоть до создания учетной записи компьютера в каталоге Active Directory

После чего выполнить следующие шаги:

8.1. Пройдите в раздел Службы -> Веб-прокси -> Технология единого входа (SSO), на вкладку Аутентификация по протоколу Kerberos, нажмите кнопку Обновить - и убедитесь, что все пункты, за исключением Файл keytab отмечены зеленым. Если это не так, то необходимо проверить настройки.

8.2. Создайте в домене учетную запись компьютера с именем, совпадающим в поле Kerberos-аккаунт этой машины в AD на вкладке Службы -> Веб-прокси -> Технология единого входа (SSO) -> Общие настройки

Примечание

Использование учетной записи компьютера предпочтительнее, так-как на учетную запись пользователя групповой политикой может накладываться ограничение на время действия пароля.

Аутентификация в системах Windows. Часть 2 - Kerberos

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

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

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

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

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

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) - пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

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

Для принципалов, которые не являются членами домена AD, могут использоваться специальные keytab-файлы, которые содержат сведения о клиенте, домене и его долговременный ключ. В целях безопасности keytab-файл нельзя передавать по незащищенным каналам, а также следует обеспечить его безопасное хранение у принципала.

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

Желая пройти проверку подлинности в сети, клиент передает KDC открытым текстом свое имя, имя домена и метку времени (текущее время клиента), зашифрованное долговременным ключом клиента. Метка времени в данном случае выступает в роли аутентификатора - определенной последовательности данных, при помощи которой узлы могут подтвердить свою подлинность.

Получив эти данные KDC извлекает долговременный ключ данного пользователя и расшифровывает метку времени, которую сравнивает с собственным текущим временем, если оно отличается не более чем на 5 минут (значение по умолчанию), то метка считается действительной. Эта проверка является дополнительной защитой, так как не позволяет использовать для атаки перехваченные и сохраненные данные.

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

Чтобы лучше понять этот механизм приведем небольшой пример. Если злоумышленник перехватил посланный KDC запрос, то он может на основе открытых данных послать клиенту поддельный сеансовый ключ и TGT, но не сможет расшифровать метку времени, так как не обладает долговременным ключом. Точно также, он может перехватить отправленные клиенту TGT и сеансовый ключ, но также не сможет расшифровать последний, не имея долговременного ключа. Перехватить долговременный ключ он не может, так как они по сети не передаются.

Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.

Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

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

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

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

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

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

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

В продолжение давней темы про использование двухфакторной аутентификации в ОС 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», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании.

Установка клиента Kerberos (версия для linux и windows)

содержание

После того, как cdh включит kerberos, если нам нужно подключить impala или hive локально (тестирование локального кода или инструменты jdbc), нам нужно установить kerberos локально.

Если другим серверам требуется доступ к службам CDH через jdbc, им также необходимо установить клиент Kerberos.

версия для Windows (win10)

Адрес загрузки инсталляционного пакета:

Выбирайте типичный при установке

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

Настроить переменные среды

Если на диске C нет ProgramData, вы можете просмотреть скрытые файлы

Путь KRB5_CONFIG фиксирован, и можно использовать любой каталог KRB5CCNAME. Каталог picc необходимо создать вручную, krb5cache создавать не нужно

Измените файл конфигурации KRB5_CONFIG и скопируйте содержимое krb5.conf сервера kerberos в krb5.ini.

Затем измените файл хоста, добавьте имена хостов ip для всех узлов cdh, а затем вы можете перезапустить

Просто откройте клиент kerberos и войдите в систему.

версия для Linux (suse)

Если вы выполняете установку только под пользователем root, следуйте процедуре ниже.

Разархивируйте клиентский пакет

rpm -ivh krb5-libs-1.15.1-34.el7.x86_64.rpm

Измените / etc / hosts, чтобы добавить имена IP-хостов всех узлов в cdh

Настройте /etc/krb5.conf, если по умолчанию есть контент, просто скопируйте содержимое /etc/krb.conf сервера kerberos

Добавить переменные среды vi / etc / profile

Файл krb5cache не нужно создавать заранее

Тогда вы можете кинить

Если он установлен обычными пользователями

Необходимо настроить переменные среды обычных пользователей

Выполнение корневого пользователя: su-user

Затем добавьте vi .profile следующим образом (если у обычных пользователей нет .profile, просто скопируйте еще один)

export KRB5CCNAME = Домашний каталог обычного пользователя / tmp / krb5cache

Затем в исходном коде вы можете kinit, чтобы обычные пользователи не пострадали, когда root kinit

Основные операции Kerberos

Введите kadmin.local, чтобы войти в командную строку, или напрямую kadmin.local -q «операция, которую необходимо выполнить», не вводя командную строку.

В следующих примерах показаны два разных способа добавления пользователей и указания пароля 131420.

delprinc удалить пользователя

Создать keytab для пользователей

Если вы не добавите-norandkey, после генерации keytab исходный пароль неверен

xst -norandkey -k /home/keytabs/test.keytab test

Изменить пароль пользователя cpw

После изменения пароля пользователя его keytab необходимо повторно создать. Исходный keytab не может быть аутентифицирован.

А пока давайте назовем kinit, для аутентификации keytab не нужно вводить пароль, прямому пользователю kinit необходимо ввести пароль.

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