Krb5 linux что это

Linux машина в домене Windows AD с помощью sssd и krb5

Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.

Для примера будем использовать:

Домен = contoso.com
Контроллер домена = dc.contoso.com

Запускаем терминал Ubuntu:

1. Переключаемся под рута

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

3. Редактируем /etc/krb5.conf, в качестве отступов используется табуляция

4. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:

5. Пробуем получить Kerberos ticket от имени администратора домена:

Если тикет получен успешно, то теперь можно сгенерировать Kerberos principals для данного хоста, регистр важен:

Сейчас наш хост должен отобразиться в списке компьютеров в каталоге. Если все так — удаляем полученный Kerberos ticket:

6. Создаем файл /etc/sssd/sssd.conf со следующим содержимым:

Описание параметров конфигфайла sssd можно посмотреть тут

Устанавливаем права доступа для файла sssd.conf:

Перезапускаем SSSD service

7. Редактируем настройки PAM

редактируем файл /etc/pam.d/common-session, после строки

переопределить параметры через системные настройки PAM, вызываем

и отмечаем пункты sss auth и makehomdir. Это автоматически добавит
строчку выше в common-session и она не будет перезатерта при обновлении системы.

Теперь мы можем логиниться на машине доменными пользователями, которым разрешен вход.

P.S.: Можно дать права на использование sudo доменным группам. Используя visudo, редактируем файл /etc/sudoers, или лучше, как рекомендует maxzhurkin и iluvar, создаем новый файл в /etc/sudoers.d/ и редактируем его

добавляем требуемую группу — например, Domain Admins (если в названии группы есть пробелы — их необходимо экранировать):

P.S.S.: Спасибо gotch за информацию о realmd. Очень удобно — если не нужны специфические настройки, то ввод машины в домен занимает, по сути, три (как заметил osipov_dv четыре) команды:

1. Устанавливаем нужные пакеты:

2. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:

3. Проверяем, что наш домен виден в сети:

4. Вводим машину в домен:

5. Редактируем настройки PAM

Дополнительный плюс данного варианта — сквозная авторизация на файловых ресурсах домена.

Источник

MIT krb5-1.4

Введение в MIT krb5

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

Информация о пакете

Контрольная сумма: 2fa56607677544e3a27b42f7cfa1155b

Требуемое дисковое пространство: 55 MB

Расчетное время сборки: 2.55 SBU

Зависимости MIT krb5

Опционально

xinetd-2.3.13 (только серверные сервисы), Linux-PAM-0.78 (для xdm основанных регистраций) и OpenLDAP-2.2.20 (альтернатива базе данных паролей krb5kdc )

Замечание

Некоторые виды средств синхронизации времени необходимы в вашей системе (например NTP-4.2.0), поскольку Kerberos не будет аутентифицировать при временнЫх различиях между керберизованным клиентом и KDC сервером.

Установка MIT krb5

MIT krb5 поставляется в TAR файле, содержащем сжатый пакет и присоединенный PGP ASC файл.

Если у вас установлен GnuPG-1.4.0, вы можете аутентифицировать пакет следующей командой:

Соберем MIT krb5 запуском следующих команд:

Установим MIT krb5 , выполнив следующие команы как пользователь root:

Описание команд

--enable-dns: Этот ключ позволяет областям быть разрешенными, используя DNS сервер.

--enable-static: Этот ключ соберет статические библиотеки в дополнение к разделяемым библиотекам.

Сохраним команду login из пакета Shadow , переместим ksu и login в директорию /bin.

Программы login и ksu скомпонованы с этими библиотеками, хотя мы переместили эти библиотеки в /lib для возможности регистрации без монтирования /usr.

Конфигурация MIT krb5

Файлы конфигурации

/etc/krb5.conf и /var/lib/krb5kdc/kdc.conf

Конфигурационная информация

Настройка Kerberos

Создадим файл конфигурации Kerberos следующей командой:

Вам потребуется установить ваш домен и собственное имя хоста вместо имен [belgarath] и [lfs.org].

default_realm должен быть именем вашего домена, измененным на ALL CAPS. Оно не обязательно, но Heimdal и MIT рекомендуют его.

encrypt = true предосталяет шифрование всего трафика между керберизованными клиентами и серверами. Это не обязательно и может быть удалено. Если вы это сделаете, то сможете сможете шифровать трафик от клиента к серверу, используя вместо этого клиентскую программу.

Параметр [realms] говорит клиентским программам, где искать сервисы аутентификации KDC .

Секция [domain_realm] отображает домен на область.

Создадим базу данных KDC :

Теперь вы должны наполнить базу данных законами (пользователями). С этих пор просто используйте ваше имя обычного пользователя или root.

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

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

При этом должен быть создан файл в /etc с именем krb5.keytab (Kerberos 5) и правами доступа 600 (запись/чтение только для root). Содержание файла keytab без общего доступа является критичным для полной безопасности установки Kerberos.

Наконец, вы захотите добавить законы серверного демона к базе данных и извлечь их в файл keytab. Сделайте это тем же способом, каким вы создали законы хоста. Ниже приведен пример:

Выйдете из программы kadmin (используя quit или exit ) и вернитесь обратно к приглашению оболочки. Запустите демон KDC вручную просто для проверки установки:

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

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

Информация о билете должна быть отображена на экране.

Для проверки функциональности файла keytab выполните следующую команду:

Это должно вывести список законов хоста вместе с методами шифрования, используемым для доступа к законам.

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

Установите стартовый скрипт /etc/rc.d/init.d/kerberos, включенный в пакет blfs-bootscripts-6.0.

Использование керберизованных клиентских программ

Для использования керберизованных клиентских программ ( telnet , ftp , rsh , rcp , rlogin ), вы сначала должны получить билет аутентификации. Используйте программу kinit для получения билета. После получения билета вы можете использовать керберизованные программы для соединения с любым керберизованным сервером в сети. У вас не будет запрашиваться аутентификация во время действия билета (по умолчанию один день), если вы не описываете другого пользователя в качестве аргумента командной строки к программе.

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

Использование керберизованных серверных программ

Использование керберизованных серверных программ ( telnetd , kpropd , klogind и kshd ) требует двух дополнительных шагов конфигурации. Первый — файл /etc/services должен быть обновлен для включения eklogin и krb5_prop. Второй — файл inetd.conf или xinetd.conf должен быть изменен для каждого сервера, который будет активирован, обычно заменяя сервер из Inetutils-1.4.2.

Дополнительная информация

Для дополнительной информации проконсультируйтесь в Документации по krb-1.4 , на которой основаны вышеописанные инструкции.

Содержание

Короткое описание

преобразует листинг таблицы имен кодов ошибок в исходный C файл.

керберизованный FTP клиент.

керберизованный FTP демон.

утилита манипуляции таблицей ключей хоста.

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

сервер для административного доступа в базу данных Kerberos.

утилита базы данных KDC .

удаляет текущую установку билетов.

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

читает и отображает текущие билеты в кеше.

сервер, отвечающий на запросы rlogin .

программа для изменения паролей Kerberos 5.

берет базу данных законов в специфическом формате и преобзазует ее в поток записей базы данных.

получает посылку базы данных kprop и записывает ее как локальную базу данных.

дает информацию о том, как скомпонованы программы с библиотеками.

сервер Kerberos 5.

сервер, отвечающий на запросы rsh .

программа su, использующая протокол Kerberos. Требует правильно настроенный файл /etc/shells и

/.k5login, содержащий авторизованные законы, чтобы стать супер пользователем.

программа для управления таблицами ключей Kerberos.

печатает номера версий ключей законов Kerberos.

керберизованная программа регистрации.

керберизованная клиентская программа rcp.

керберизованная клиентская программа rlogin.

керберизованная клиентская программа rsh.

керберизованная клиентская программа telnet.

керберизованный сервер telnet.

включает Kerberos библиотеку кодов ошибок.

содержит Generic Security Service Application Programming Interface ( GSSAPI ) функции, предоставляющие сервисы безопасности в общем стиле, поддерживаемом при помощи диапазона механизмов и технологий и с этого времени позволяющем переносимость приложений на уровне исходников в другие окружения.

содержит функции административной аутентификации и проверки пароля, требуемые для клиентских программ Kerberos 5.

содержит функции административной аутентификации и проверки пароля, требуемые для серверов Kerberos 5.

библиотека доступа к базе данных аутентификации/авторизации Kerberos 5.

библиотека общего назначения Kerberos 5.

Последнее обновление 2005-02-10 13:19:10 -0700

Источник

Аутентификация файловых серверов GNU/Linux в домене Windows на базе AD. Часть 2

1. Конфигурационные файлы.

Мы будем настраивать только доступ к серверу GNU/Linux с использованием Samba. Авторизация пользователей останется локальной, с использованием /etc/passwd.
Мы присвоим нашему новому серверу статический IP-адрес. Пусть им будет 192.168.7.9.
Для начала нужно проверить, какой сервер у нас используется в качестве DNS. Им в нашей сети должен быть контроллер домена. У нас адрес сервера определен как 192.168.7.2. Правим файл /etc/resolv.conf. Он должен выглядеть следующим образом:

Проверим, все ли работает:

Естественно, в Вашем случае имена будут другими. Обязательно сделайте в домене lab.local запись в DNS, ссылающуюся на наш новый сервер. Запись в DNS не означает того, что наш GNU/Linux сервер включен в домен. Проверим:

Для корректной работы в домене Windows требуется несколько служб: Kerberos, LDAP и Samba. В общем случае требуется только настройка Samba, настройка других служб не является обязательной. Но будет лучше, если мы их настроим – они могут пригодиться в будущем.
Kerberos настраивается просто – через один файл /etc/krb5.conf. Основными параметрами является REALM, указывающий на наш домен и адрес сервера Kerberos – это адрес контроллера домена. Файл /etc/krb5.conf выглядит примерно так:

Секция [libdefaults] указывает на домен по умолчанию. У нас это LAB.LOCAL. Далее, в секции [realms] указываются параметры для LAB.LOCAL – имя домена и адрес сервера Kerberos. В нашем случае, в качестве сервера Kerbeors выступает контроллер домена. В секции [logging] указывается местоположение лог-файлов. Эти файлы пригодятся для процедуры поиска неисправности, если что-то пойдет не так.
Проверим работу Kerberos:

Команда kinit получает от сервера тикет, а klist показывает полученные тикеты от сервера. Выполнение kinit не является обязательным, но ведь нужно как-то проверить работу Kerberos?
Настройка LDAP тоже не является обязательной – Samba сама построит необходимые файлы и сделает нужные запросы. Но LDAP может пригодиться в дальнейшем. Конфигурация OpenLDAP хранится в файле /etc/openldap/ldap.conf. Обратите внимание – в системе может быть два файла ldap.conf. У них разные предназначения и даже немного разный синтаксис. В каталоге /etc/openldap лежит файл ldap.conf для OpenLDAP (и для Samba), а в файле /etc/ldap.conf хранится конфигурация для разрешения имен через LDAP (для nss_ldap). К файлу /etc/ldap.conf мы вернемся в других статьях, сейчас настроим /etc/openldap/ldap.conf

Как видите, все очень просто – нужно указать URI сервера LDAP (это наш контроллер домена) и базу для поиска.
Теперь переходим к самому сложному – настройке Samba.
В состав Samba входят 3 демона – smbd, nmbd и winbind. Все они берут настройки из файла /etc/samba/smb.conf.
Smbd отвечает за доступ клиентов к службе SMB/CIFS (собственно это и есть сервер Samba). Nmbd – это служба разрешения имен для Netbios. Winbind – служба разрешения имен (и компьютеров и пользователей) через доменные службы Windows.
Во многих руководствах можно встретить упоминание того, что кроме Samba требуется настраивать и winbind – службу, отвечающую за отношения между GNU/Linux и контроллером домена Windows. В частном случае, когда нужно настроить только Samba, настройки winbind можно опустить. Winbind обеспечивает авторизацию в домене Windows самых различных служб, обеспечивая интерфейс между модулями PAM и контроллером домена Windows. При неработающем winbind Samba остается работоспособной. Но настроив winbind мы делаем возможным дальнейшее расширение нашего сервера за счет добавления различных служб, авторизующихся через контроллер домена.
Мы сделаем самый простой сервер, открыв всем пользователям доступ к некоторому общему каталогу файлов и к домашнему каталогу пользователей. Более подробно о настройке доступа к серверу Samba мы будем говорить в других статьях.
В файле /etc/samba/smb.conf мы должны указать следующие строки:

Здесь мы указываем сокращенное наименование нашего домена (LAB) и место, где хранятся пароли – параметр passdb backend, указывающий на то, что пароли находятся на сервере LDAP, в качестве которого выступает контроллер домена. Кстати, можно указать и несколько серверов, перечислив их через пробел. Это пригодится в том случае, если у нас несколько контроллеров домена. Строка usershare allow guests = Yes разрешает пользователям управлять доступом к своим папкам, открывая их для гостей. Остальные строки относятся к управлению печатью и процессу регистрации. В нашем случае они не являются обязательными и перекочевали из конфигурационного файла дистрибутива Samba.
Продолжим редактирование секции [global] файла smb.conf.

Строки domain logons и domain master разрешают использовать Samba в качестве контроллера домена. Это не наш случай и поэтому для них установлено No.
Строка security = ADS имеет ключевое значение. Тем самым мы указываем Samba, что сервер является членом домена Windows и за авторизацию отвечает AD. Строка encrypt passwords = yes означает, что используются зашифрованные пароли.
Продолжим редактировать все ту же секцию [global].

Эти строки относятся к управлению соединением с LDAP сервером. Заметьте, что форма записи DN администратора имеет форму user@domain – она должна совпадать с тем, что мы указывали при тестировании Kerberos. Остальные строки указывают суффиксы различных местоположений в AD.
Следующие строки относятся уже к Kerberos:

Здесь мы указываем REALM и метод аутентификации в Kerberos.
Теперь строки, которые относятся к настройке winbind:

Здесь указаны различные параметры работы Winbind – форма разделитя имен домена и пользователя, разрешение для winbind перечислять имена пользователей и групп, разрешение оффлайновой аутентификации и т.п. Эти настройки рекомендованы разработчиками Samba.
Секция глобальных настроек закончена. Обратите внимание, что у нас нет строк password server и idmap backend, которые можно встретить в других руководствах. Samba должна сама разобраться, откуда берутся пароли.
Переходим к настройке каталогов. Здесь все просто:

К стандартному списку разделяемых каталогов, распространяемому вместе с дистрибутивом Samba мы добавили только секцию [SRV] – общедоступный каталог.
Конфигурирование всех необходимых файлов закончено, и мы приступаем к проверке работоспособности нашего сервера.

2. Проверка работоспособности.

Здесь мы проверим корректность наших настроек и включим наш новый сервер в домен Windows. Сначала проверим корректность настройки Samba:
l
Как видно, каких либо серьезных предупреждений и ошибок конфигурации у нас нет.
Теперь запустим по очереди демоны smbd, nmbd и winbindd. Сделаем это через файлы /etc/init.d/smb, /etc/init.d/nmb и /etc/init.d/winbind. Можно выполнить это и вручную, что может оказаться полезным для получения различной дополнительной информации. О том, как это сделать можно прочесть во встроенных руководствах (man) по smbd, nmbd и winbindd.
Проверим состояние нашего домена и нашего сервера в домене. Состояние домена можно получить командой net ads info

Как видно, все в порядке. Если какие-то параметры, выводимые командой не совпадают с нашим планом – надо искать причину. Теперь проверим состояние нашего сервера в домене:
l
Отсюда следует, что наш сервер не включен в домен. Запрос к контроллеру домена делается от имени администратора, и пароль нужно указывать от учетной записи администратора домена Windows.
Теперь мы должны включить наш сервер в домен:
l
Итак, наш новый сервер включен в домен, о чем свидетельствуют строки:

Динамическое изменение DNS у нас не прошло. Это не страшно, поскольку оно и не планировалось. Теперь рекомендуется перезапустить все наши процессы – smbd, nmbd и winbindd. Заметим, что после перезапуска до дальнейших проверок должно пройти несколько минут.
Проверим статус нашего сервера в домене:

В ответ мы получим распечатку состояния нашего нового сервера в домене. Там будут указаны различные поля AD, относящиеся к нашему серверу. Так же наш сервер GNU/Linux мы увидим на вкладке Computers, запустив средство администратора AD на контроллере домена.

Можно проверить список пользователей домена:
l
И проверим работу winbind:

И получим список пользователей в домене:
l
Можно проверить состояние домена через wbinfo:
l
Все в порядке. Теперь самая главная проверка – попробуем открыть каталоги на нашем новом сервере, используя рабочую станцию под управлением Windows 7. Наша рабочая станция включена в домен. Мы должны увидеть наш новый сервер на вкладке Network обозревателя Windows, либо указав имя или IP адрес:

Теперь можно переходить к дальнейшим процедурам настройки нашего сервера. В дальнейшем мы рассмотрим некоторые нюансы описанного процесса в зависимости от дистрибутива GNU/Linux и подробнее рассмотрим настройку прав доступа к серверу Samba.
Работа выполнена на базе Информационно-вычислительного центра МЭИ.

Источник