- Детальная проверка kerberos от начала логирования
- » принципы аутентификации по протоколу kerberos
- Kerberos с точки зрения пользователя
- Вторичный kdc
- Делегирование аутентификации по протоколу kerberos
- Идентификация и доступ в active directory
- История создания kerberos
- Линукс клиент kerberos
- Ловушка для хакеров: ложная учетная запись администратора домена
- Настройка
- Обзор
- Простые решения
- Установка
Детальная проверка kerberos от начала логирования
Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:
» принципы аутентификации по протоколу kerberos
Kerberos и PKINIT Часть 1.
Обеспечивая безопасность нельзя забывать о вопросах безопасной аутентификации. В нескольких предыдущих статьях я уже останавливался на некоторых аспектах этой проблемы, и разбирались с двухфакторной аутентификацией. В этой статье мы рассмотрим механизмы работы протокола Kerberos при аутентификации с помощью имени пользователя и пароля и при использовании технологий асимметричной криптографии.
Общие сведения
Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей.
Предусматривается, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы,
Протокол Kerberos может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sign-On (возможность использования единой учетной записи пользователя для доступа к любым ресурсам области).
Протокол основан на понятии Ticket (билет).
Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).
Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Service Ticket (TGS).
Одним из преимуществ протокола Kerberos, обеспечивающим высокий уровень безопасности, является то, что при любых взаимодействиях не передаются ни пароли, ни значения хеша паролей в открытом виде.
Работая с протоколом Kerberos, необходимо, чтобы системные часы всех участвующих во взаимодействии узлов были синхронизированы.
В качестве примера реализации протокола Kerberos имеет смысл отметить доменную аутентификацию пользователей в операционных системах Microsoft, начиная с Windows 2000.
Как работает аутентификация Kerberos?
Рассмотрим, как осуществляется аутентификация посредством протокола Kerberos.
В процессе аутентификации задействованы следующие основные компоненты:
Она ведет базу ученых данных с информацией обо всех участниках безопасности (security principal) своей области. Если речь идет о сетях Windows 2000/2003/2008, понятию «область Kerberos» соответствует понятие «домен».
Вместе с информацией о каждом security principal в базе данных KDC сохраняется криптографический ключ, известный только этому объекту и службе KDC. Указанный ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей.
Примечание: В большинстве практических реализаций протокола Kerberos долговременные ключи создаются на основе пароля пользователя.
Итак, рассмотрим процесс аутентификации пользователя.
1. Получив приглашение на ввод имени пользователя, пароля и домена, пользователь указывает эти данные.
2. Затем компьютер пользователя обращается к службе KDC[1] и передает ей имя пользователя, имя домена, а также текущее время на рабочей станции пользователя, при этом имя пользователя передается в открытом виде, текущее время на рабочей станции пользователя передается в зашифрованном виде и является аутентификатором. Ключ шифрования формируется из пароля пользователя в результате хеширования. См. рис. 1.
1
3. Служба KDC ищет пользователя в AD, выявляет мастер ключ пользователя, который основан на пароле пользователя и расшифровывает аутентификатор, т. е. получает время отправки запроса. Разница во времени отправки запроса и текущего времени на контроллере домена не должно превышать определенного значения, установленного политикой протокола Kerberos[2].
4. Затем KDC создает два объекта:
a. ключ сессии, посредством которого будет обеспечиваться зашифрование данных при обмене между клиентом и службой KDC,
b. билет на получение билета Ticket-Granting Ticket (TGT). TGT включает: вторую копию ключа сессии, имя пользователя, время окончания жизни билета. Билет на получение билета шифруется с использованием собственного мастер ключа службы KDC, который известен только KDC, т. е. TGT может быть расшифрован только самой службой KDC.
5. Служба KDC зашифровывает аутентификатор пользователя (time stamp) и ключ сессии с помощью ключа клиента. После этого эти данные отправляются клиенту. См. Рис. 2.
2
6. Компьютер клиента получает информацию от службы KDC, проверяет аутентификатор, расшифровывает ключ сессии.
7. Теперь клиент обладает ключом сессии и TGT, что предоставляет возможность безопасного взаимодействия со службой KDC. Клиент аутентифицирован в домене и получает возможность осуществлять доступ к ресурсам домена, используя протокол Kerberos.
Итак, клиенту, прошедшему аутентификацию посредством Kerberos, требуется получить доступ к ресурсам на других серверах в том же домене.
1. Клиент обращается к службе KDC. Клиент представляет KDC свой TGT и маркер времени, которые зашифрованы с помощью ключа сессии, известного службе KDC.
2. KDC расшифровывает TGT, используя свой собственный ключ. Маркер времени расшифровывается с помощью сессионного ключа. Теперь KDC может подтвердить, что запрос пришел от «правильного» пользователя, т. к. этот пользователь может использовать этот сессионный ключ. См. рис. 3
3
3. Затем KDC создает пару билетов, один для клиента, один для сервера, к ресурсам которого клиент должен будет получать доступ. Каждый билет содержит имя пользователя, запрашивающего доступ, получателя запроса, маркер времени, показывающий, когда был создан билет, а также срок жизни билета. Оба билета будут также содержать новый ключ, K_cs который, таким образом известен и клиенту и серверу. Этот ключ будет обеспечивать возможность безопасного взаимодействия между ними. KDC шифрует билет сервера, используя мастер – ключ сервера, затем вкладывает билет сервера внутрь билета клиента, который также содержит ключ K_cs
4. Вся эта структура зашифровывается с помощью сессионного ключа, который стал доступен пользователю при аутентификации. После чего эта информация отправляется клиенту. См. Рис. 4
4
5. Получив билет, клиент расшифровывает его с помощью сессионного ключа, т. е. K_cs становится доступным клиенту, K_cs доступен также и серверу. Клиент не может прочитать билет сервера, т. к. он зашифрован на ключе сервера. См. Рисунок 5
Рисунок 5
6. Клиент зашифровывает маркер времени с помощью ключа, K_cs затем отправляет маркер времени и билет сервера самому серверу, к ресурсам которого пытается получить доступ клиент. См. Рис. 6
6
7. Получив эту информацию, на первом этапе сервер расшифровывает свой билет, используя свой долговременный ключ. Это предоставляет возможность получить доступ к K_cs , с помощью которого будет на втором этапе расшифрован маркер времени, полученный от клиента.
8. Теперь и клиент, и сервер обладают ключом K_cs. Следовательно, сервер может быть уверен в том, что клиент правильно идентифицирован, т. к. для шифрования маркера времени был использован K_cs . В случае необходимости ответа сервера клиенту, сервер воспользуется ключом K_cs . Клиент будет знать, что сервер правильно идентифицирован, поскольку сервер должен использовать, чтобы получить K_cs .
Разумеется, представленное в статье описание процедур аутентификации на основе Kerberos является упрощенным, тем не менее, мне представляется, что в значительной степени упростит понимание базовых принципов работы протокола. Если же читателя заинтересует более глубокое понимание работы Kerberos, то могу предложить ознакомиться с материалами, представленными в списке литературы.
В следующей статье мы рассмотрим возможности протокола Kerberos в сочетание с использованием технологий асимметричной криптографии. Именно этот вариант аутентификации является наиболее выгодным с точки зрения безопасности, поскольку позволяет избежать ввода пароля пользователя, что в свою очередь предотвращает его перехват программными и аппаратными средствами, например клавиатурными шпионами. Кроме того, минимизирует риски, связанные с человеческим фактором (подсматривание пароля, социотехника, и т. п.).
Продолжение следует…
Леонид Шапиро
Список литературы
RFC4120 – The Kerberos Network Authentication Service (V5)
RFC4556 – Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
[1] Чтобы обратиться к службе KDC на контроллере домена, необходимо выполнить разрешение имени этой службы в IP-адрес. Этот процесс выполняется с помощью службы DNS, т.е. компьютер клиента должен «знать» адрес сервера DNS.
[2] 5 минут по-умолчанию.
Kerberos с точки зрения пользователя
На пользовательском уровне все реализации Kerberos выглядят однотипно, поэтому рассмотрим, как это происходит в моем случае. Регистрация в Kerberos осуществляется командой kinit, которая автоматически вызывается при моем входе на рабочую станцию под управлением Windows XP.
В результате мне выдается основной документ, удостоверяющий мою личность в Kerberos, – «супербилет», билет, гарантирующий получение доступа к сетевым службам (или TGT – ticket granting ticket). При этом у меня всегда есть возможность зарегистрироваться в Kerberos под другим именем с помощью все той же команды kinit, что приводит к обновлению начального билета.
Вторичный kdc
Когда у вас есть один центр распространения ключей (KDC) в сети, хорошей практикой является создание вторичного KDC на случай, если первичный будет недоступен. Также, если у вас Kerberos клиенты расположены в различных сетях (возможно разделенные роутерами, использующими NAT), разумно будет поместить вторичные KDC в каждую такую сеть.
sudo apt-get install krb5-kdc krb5-admin-server
kadmin -q "addprinc -randkey host/kdc02.example.com"
После, выполняя любые команды kadmin, у вас будет запрашиваться пароль вашей учетной записи username/admin@EXAMPLE.COM
kadmin -q "ktadd -norandkey -k keytab.kdc02 host/kdc02.example.com"
sudo mv keytab.kdc02 /etc/krb5.keytab
Если путь до файла keytab.kdc02 иной, замените соответственно.
Также вы можете вывести список учетных записей в файл keytab, который может быть полезен при решении проблем, используя утилиту klist:
sudo klist -k /etc/krb5.keytab
Опция -k показывает, что это keytab файл.
host/kdc01.example.com@EXAMPLE.COM
host/kdc02.example.com@EXAMPLE.COMsudo kdb5_util -s create
sudo kpropd -S
sudo kdb5_util dump /var/lib/krb5kdc/dump
kadmin -q "ktadd -k keytab.kdc01 host/kdc01.example.com"
sudo mv keytab.kdc01 /etc/krb5.keytabУбедитесь, что это host для kdc01.example.com, перед извлечением Keytab.
sudo kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
Должно вернуться сообщение SUCCEEDED, если распространение сработало. Если вернулось сообщение об ошибке, проверьте /var/log/syslog на вторичном KDC для дополнительной информации.
Вы можете также создать задачу cron для периодического обновления базы данных на вторичных KDC. Например, следующий код будет выгружать базу данных каждый час (обратите внимание, что длинная строка разделена чтобы соответствовать формату документа):
# m h dom mon dow command
0 * * * * /usr/sbin/kdb5_util dump /var/lib/krb5kdc/dump &&
/usr/sbin/kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.comsudo kdb5_util stash
sudo /etc/init.d/krb5-kdc start
Вторичный KDC теперь должен иметь возможность выдавать билеты для своей области. Вы можете это проверить, остановив сервис krb5-kdc на первичном KDC и затем запросив билет с помощью kinit. Если все пойдет хорошо, вы получите билет со вторичного KDC. В противном случае проверяйте /var/log/syslog и /var/log/auth.log на вторичном KDC.
Делегирование аутентификации по протоколу kerberos
Недавно на одной из конференций я выступал с докладом по проблемам делегирования аутентификации по протоколу Kerberos. Я попросил поднять руки тех слушателей, которым хотя бы раз доводилось настраивать процесс делегирования Kerberos. Таких оказалось довольно много.
Тогда я попросил опустить руки тех, кому не удалось правильно выполнить настройку с первой же попытки. Поднятыми остались всего две-три руки. К сожалению, документации по вопросам делегирования и ограниченного делегирования существует немного. Между тем настройка делегирования — это жизненно важный компонент многих корпоративных приложений.
Как уже отмечалось, самый типичный пример делегирования сводится к следующему. Пользователь обращается к приложению (обычно речь идет о веб-приложении), которое затем обращается к некоему ресурсу, например к базе данных SQL Server. Чтобы получить соединение с базой данных, приложение должно представить учетные данные.
Часто соединение устанавливается с использованием выделенной учетной записи службы с правом чтения и записи всех необходимых данных внутри базы данных, как показано на рисунке 1. После этого приложение становится ответственным за контроль над элементами управления доступом непосредственно к данным, поскольку учетная запись службы имеет доступ ко всем объектам.
Еще одна возможность заключается в том, чтобы управлять данными с помощью реализованных в SQL Server собственных средств управления доступом на уровне пользователя или группы. Элементы управления будут работать эффективно лишь в том случае, если приложение установит соединение в контексте пользователя, обращающегося к приложению, как показано на рисунке 2.
Идентификация и доступ в active directory
Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:
- Она должна хранить информацию, о всех объектах Active Directory, среди которых: пользователи, группы безопасности, компьютеры, принтеры и другие объекты идентификации. Под объектом идентификации (identity) подразумевается, некое представление сущности, в задачи которой входит выполнение каких-либо действий в корпоративной сети. Простой пример, есть пользователь Вася и он работает с документами в общей папке на сервере. Эти документы имеют защиту на доступ, который определяет список контроля доступа (Access Contro l List, ACL). Доступом у нужным файлам, управляет подсистема безопасности сервера, где лежит папка, и при обращении к ней он производит сравнение объекта идентификации пользователя с теми объектами, которые присутствуют в его списке ACL, и уже на основании этого, он принимает решение предоставить или запретить пользователю доступ. Так как службы, компьютеры, группы и другие объекты выполняют определенные вещи в локальной сети, то у каждого из них есть свой объект идентификации. Данный объект содержит много информации, уникальной для каждого из них, например, имя пользователя, его идентификатор безопасности (Security Identifier, SID), пароль. Так, что хранилище объектов идентификации, является неотъемлемой частью Identity and Access. Все данные в Active Directory, располагаются в каталоге AD, которым управляет контроллер домена.
- Проверка подлинности объекта идентификации. Тут общий принцип такой, когда пользователь обращается к документу, то сервер его ему не покажет, пока тот, не подтвердит подлинность объекта идентификации, который фигурирует в запросе. Чтобы все это сделать, у пользователя есть некая секретная информация, которая известна ему и инфраструктуре IDA, вот эти данные как раз и сравниваются с теми, что есть в хранилище объектов идентификации в момент проверки подлинности.
История создания kerberos
В 1983 году была начата работа по созданию системы Athena. Работу финансировали компании IBM и DEC, и в 1987 году была выпущена первая версия протокола Kerberos (Kerberos 4). Дальнейшая эксплуатация выявила недостатки протокола, и обновленный вариант Kerberos 5 вышел в свет в 1993 году.
В настоящее время 4 версия практически не используется, но в реализациях протокола от МТИ совместимость с предыдущей версией продолжает сохраняться. К 1993 году протокол Kerberos уже завоевал популярность, и многие компании, разработчики программного обеспечения стремились использовать его в своих программных продуктах.
Но тут имел место юридический казус – дело в том, что в то время в США еще действовали законы, введенные еще во время холодной войны, запрещающие экспорт военных технологий. Поскольку криптографическая защита, использованная в Kerberos, классифицировалась как военная технология, это создавало препятствия для использования его в программных продуктах сторонних фирм и распространения его за пределами США.
Для решения этой проблемы была выпущена версия протокола Kerberos 4, из которого была изъята вся сильная криптография. Эта реализация Kerberos получила название Bones (кости), и ограничения на ее экспорт уже не действовали. В 1997 году группа программистов из Стокгольмского Королевского университета, взяв за основу Bones, проделала обратную работу и вставила недостающую криптографическую функциональность.
Вот так экспортные ограничения Соединенных Штатов способствовали развитию европейского hi-tech. Впоследствии ими же была выпущена реализация протокола Kerberos 5, получившая название Heimdal. Heimdal (Хеймдалль) – это божество из скандинавского пантеона, чьи функции состояли в охране стратегических коммуникаций, а именно – моста, разделяющего Асгард и Мидгард.
Так же, как и в случае с древнегреческим прототипом Kerberos, здесь эксплуатируется образ неподкупного стража. Интересно отметить, что мотивом для программистов из Стокгольмского университета, так же как и для их коллег из МТИ, являлась задача обеспечения публичного доступа к вычислительному кластеру.
Последним эпизодом из истории Kerberos стало объявление компанией Microsoft в 1999 году о поддержке Kerberos в своей будущей операционной системе NT 5.0 (впоследствии названной Windows 2000), что действительно было реализовано в качестве компонента Active Directory. В настоящее время Kerberos является промышленным стандартом удаленной аутентификации пользователей.
Литература, ссылки:
1. Гребенников Р. Танцуем Самбу. – Журнал «Системный администратор», №11, ноябрь 2004 г. – 32-38 с.
Линукс клиент kerberos
Эта часть освещает настройку клиента Kerberos на системе Линукс. Это позволит получить доступ к любому керберезированному сервису как только пользователь удачно авторизуется в системе.
Ловушка для хакеров: ложная учетная запись администратора домена
Впроцессе создания домена Active Directory (AD) автоматически формируется учетная запись администратора для этого домена. Эта учетная запись, на которую возлагаются обязанности по управлению всеми объектами в домене — очевидная мишень для злоумышленников.
Настройка
Вопросы, задаваемые в процессе установки, используются для настройки файла /etc/krb5.conf. Если вам требуется скорректировать настройки KDC, просто измените файл и перезапустите сервис krb5-kdc. Если вам требуется перенастроить Kerberos сначала, возможно для изменения имени области, вы можете это сделать набрав следующее:
sudo dpkg-reconfigure krb5-kdc
sudo kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc steve/admin
WARNING: no policy specified for steve/admin@EXAMPLE.COM; defaulting to no policy
Enter password for principal "steve/admin@EXAMPLE.COM":
Re-enter password for principal "steve/admin@EXAMPLE.COM":
Principal "steve/admin@EXAMPLE.COM" created.
kadmin.local: quitВ примере выше steve – учетная запись, /admin – требование, а @EXAMPLE.COM – определяет область. “Ежедневная” учетная запись, она же пользовательская – steve@EXAMPLE.COM и она будет иметь только обычные права пользователя.
Замените EXAMPLE.COM и steve на ваши имена области и администратора.
steve/admin@EXAMPLE.COM *
Эта запись предоставляет для steve/admin возможность выполнять любые операции над любыми учетными записями в этой области. Вы можете настроить учетные записи более ограниченными правами, которые удобны если вам требуется учетная запись младшего администратора, которую можно использовать на клиентах Kerberos. Пожалуйста, посмотрите страницу руководства (man) по kadm5.acl.
sudo /etc/init.d/krb5-admin-server restart
kinit steve/admin
steve/admin@EXAMPLE.COM's Password:После ввода пароля используйте утилиту klist чтобы увидеть информацию о билете для получения билетов (TGT):
klist
Credentials cache: FILE:/tmp/krb5cc_1000
Principal: steve/admin@EXAMPLE.COM
Issued Expires Principal
Jul 13 17:53:34 Jul 14 03:53:34 krbtgt/EXAMPLE.COM@EXAMPLE.COMгде имя файла кэша krb5cc_1000 составлено из префикса krb5cc_ и id пользователя (uid), который в нашем случае 1000. У вас может возникнуть необходимость добавить запись в /etc/hosts для KDC чтобы клиент мог его найти. Например:
192.168.0.1 kdc01.example.com kdc01
Замените 192.168.0.1 на IP адрес вашего KDC. Обычно такое требуется, когда ваша Kerberos область охватывает различные сети, разделенные роутерами.
_kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com.
_kerberos._udp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com.
_kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1 0 749 kdc01.example.com.
_kpasswd._udp.EXAMPLE.COM. IN SRV 1 0 464 kdc01.example.com.Замените EXAMPLE.COM, kdc01 и kdc02 на ваши имя домена, первичный и вторичный KDC
Смотрите Служба доменных имен (DNS) для детальных инструкций по настройке DNS.
Ваша новая область Kerberos теперь готова аутентифицировать клиентов.
Обзор
Если вы новичок в Kerberos, есть несколько терминов, которые хорошо понять до установки сервера Kerberos. Большинство терминов связаны с вещами, которые могут быть вам знакомы по другим окружениям:
Учетная запись (Principal): любые пользователи, компьютеры или сервисы, предоставляемые серверами, должны быть определены как учетные записи Kerberos .
Требования (Instances): используются для сервисных и специальных административных учетных записей.
Области (Realms): уникальная область управления, обеспечиваемая установкой Kerberos. Представляйте ее себе как домен или группу ваших компьютеров и пользователей, ей принадлежащих. По умолчанию Ubuntu использует имя DNS домена в верхнем регистре (EXAMPLE.COM) в качестве имени области.
Центр распространения ключей (KDC): состоит из трех частей: базы данных всех учетных записей, сервера аутентификации и сервера предоставления билетов. Для каждой области должен быть хотя бы один KDC.
Билет для получения билета (TGT): изданный сервером аутентификации, TGT зашифровывается на пароле пользователя, который известен только пользователю и KDC.
Сервер распространения билетов (TGS): выпускает сервисные билеты для клиентов по запросу.
Билеты (Tickets): подтверждение идентичности двух учетных записей. Одна учетная запись – пользователь, а другая – сервис, запрашиваемый этим пользователем. Билеты устанавливают секретный ключ, используемый для защищенного соединения во время авторизованной сессии.
Файлы ключей (Keytab Files): файлы, извлеченные из базы учетных записей KDC и содержащие ключ шифрования для сервиса или компьютера.
Чтобы сложить все вместе: Область содержит как минимум один KDC, лучше больше для обеспечения безотказности, которые содержат базу данных учетных записей. Когда пользователь под учетной записью заходит на рабочую станцию, которая настроена на Kerberos аутентификацию, KDC выпускает билет для получения билетов (TGT). Если пользователь предоставляет совпадающие параметры, он считается аутентифицированным и может запрашивать билеты для сервисов, поддерживающих Kerberos, на сервере распространения билетов (TGS). Сервисные билеты позволяют пользователю аутентифицироваться на сервисах без ввода имени и пароля.
Простые решения
В большинстве случаев средства аутентификации на базе протокола Kerberos функционируют без сбоев. Но если у вас возникнет необходимость развернуть приложение, предусматривающее ограниченное делегирование Kerberos, вы сможете решить эту задачу лишь при условии четкого представления о том, как функционирует делегированная аутентификация.
Установка
Для данного обсуждения мы создадим домен MIT Kerberos со следующими параметрами (изменяйте их для соответствия вашим требованиям):
Область: EXAMPLE.COM
Первичный KDC: kdc01.example.com (192.168.0.1)
Вторичный KDC: kdc02.example.com (192.168.0.2)
Учетная запись пользователя: steve
Учетная запись администратора: steve/admin
Настоятельно рекомендуется, чтобы ваши авторизованные в сети пользователи имели uid в отдельном диапазоне от ваших локальных пользователей (скажем, начиная с 5000).
Перед установкой сервера Kerberos требуется правильно настроить DNS сервер для вашего домена. Поскольку область Kerberos по соглашению совпадает с именем домена, этот раздел использует домен EXAMPLE.COM, настроенный как Primary Master по документации DNS.
Кроме того, Kerberos – протокол, зависимый от времени. Поэтому если локальное время системы на клиентской машине и на сервере отличается более чем на 5 минут (по умолчанию), рабочая станция не будет аутентифицирована. Для решения проблемы все узлы сети должны синхронизировать свое время по одному серверу NTP. Детали настройки NTP смотрите в разделе Синхронизация времени по NTP.
Первый шаг по созданию области Kerberos – это установка пакетов krb5-kdc и krb5-admin-server. Введите в терминале:
sudo apt-get install krb5-kdc krb5-admin-server
В конце установки у вас запросят сетевые имена серверов Kerberos и административного, которые могут быть одним и тем же или разными серверами для определенной области.
По умолчанию область создается из доменного имени KDC.
Далее создаем новую область с помощью утилиты kdb5_newrealm:
sudo krb5_newrealm