Вопрос: RHEL, SSSD, Active Directory

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

Здесь много настроек, поэтому, пожалуйста, терпите меня.

Во-первых, цель состоит в том, чтобы все наши системы Linux и Unix аутентифицировались с помощью AD. Это не обязательно для нескольких сотен систем; управление учетными записями пользователей давно перестало быть проблемой.

У нас есть несколько экземпляров AD: один из них - это «управляющий AD» («MAD»), в котором должны находиться все учетные записи системных администраторов. MAD не доверяет другим доменам. Все остальные домены («CAD», «FAD», «BAD») доверяют MAD. Большинство систем будут связаны с CAD, FAD или BAD. С MAD будут связаны только внутренние системы.

Основная платформа - RHEL, и у меня есть смесь 5, 6 и 7. 5 не исчезнет в ближайшее время, и, несмотря на то, что она перестанет поддерживать RH в меньше чем через год мне все еще нужно интегрировать население 5 человек с AD. Любое решение должно работать в 5, 6 и 7, поскольку мы не хотим поддерживать несколько способов работы.

Мои основные варианты (по крайней мере, те, над которыми я работаю) - это Winbind и SSSD. Учитывая выбор между двумя, я бы предпочел SSSD, поскольку Winbind «довольно старый». Еще одно требование: "группы" и "идентификатор" производить информацию из AD, поскольку мы намерены использовать функцию OpenSSH "AllowGroups" для ограничения входа в систему определенными группами AD.

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

Я довольно силен в unix / linux в целом, но я не силен в AD, Kerberos или LDAP.

Для лабораторных целей я ' m, начиная с новой установки RHEL7 с ISO (кикстарт с некоторыми базовыми настройками), без установки битов аутентификации в KS.

Шаг 1: Время синхронизации. Готово.

Шаг 2: Установите / активируйте oddjob. Готово.

Шаг 3: Убедитесь, что для целевой системы есть как прямые, так и обратные записи DNS. Готово. Пока что вручную я не могу полагаться на более поздние шаги, чтобы исправить это. Я справлюсь.

Шаг 4: Настройте Kerberos. Дезинфицированная версия /etc/krb5.conf:[1250ptingStep 5: Настройте samba.conf ровно для SSSD. Раздел /etc/samba/smb.conf [globals], очищен:

[global]
workgroup = CAD
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
log file = /var/log/samba/%m.log
log level = 0
password server = cad_dc_01.cad.lab
realm = CAD.LAB
security = ads

Шаг 6: Присоедините систему к CAD. «Администратор kinit», за которым следует «присоединиться к сетевой рекламе -k». Работает без проблем.

Шаг 7: Настройте SSSD. Продезинфицирован /etc/sss/sssd.conf:

[sssd]
domains = CAD
services = nss, pam
config_file_version = 2
cache_credentials = true
debug_level = 7

[domain/CAD]
enumerate = true
# I know enumerate will cause problems later, I'm only turning it on for lab
debug_level = 7
id_provider = ad
ad_server = cad_dc_01.cad.lab
auth_provider = ad
chpass_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%u

[nss]
debug_level = 7

[pam]
debug_level = 7

, за ним следует "systemctl start sssd". Кажется, что это работает, но никакие логины AD не работают.

Просматривая /var/log/sssd/sssd_CAD.log, я нахожу несколько вещей, которые дают мне ключ к пониманию того, где что-то не так, но я не удалось найти способ их исправить: каждое прочитанное мной руководство содержит последовательность шагов и предполагает, что каждый шаг работает. Я не нашел ничего, что могло бы помочь мне понять, что случилось, когда один из этих шагов не работает.

Я выиграл » t публиковать весь sssd_CAD.log, если кто-то не спросит, но вот первые признаки того, что что-то не так.

(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [ad_set_sdap_options] (0x0100): Option krb5_realm set to CAD
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [sdap_set_sasl_options] (0x0100): Will look for rhel7lab.CAD.LAB@CAD in default keytab
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching rhel7lab.CAD.LAB@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching rhel7lab$@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching host/rhel7lab.CAD.LAB@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching *$@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching host/*@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [match_principal] (0x1000): Principal matched to the sample (host/*@(null)).
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [select_principal_from_keytab] (0x0200): Selected primary: host/rhel7lab.CAD.LAB
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [select_principal_from_keytab] (0x0200): Selected realm: CAD.LAB

Есть более поздние записи, в которых жалуются на то, что sssd_ad не подключен к AD, но это неудивительно, учитывая то, что я здесь вижу.

Итак: свежий образ с timesync / krb5.conf / smb.conf, все готово, теперь "kinit Administrator", за которым следует "klist"

[root@rhel7lab]# kinit Administrator
Password for Administrator@CAD.LAB: 
[root@rhel7lab]# net ads join -k
Using short domain name -- CAD
Joined 'RHEL7LAB' to dns domain 'CAD.dev'
[root@rhel7lab]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@CAD.LAB

Valid starting       Expires              Service principal
05/31/2016 12:46:35  05/31/2016 22:46:35  krbtgt/CAD.LAB@CAD.LAB
        renew until 06/07/2016 12:46:30
05/31/2016 12:46:39  05/31/2016 22:46:35  cifs/CADDC01.CAD.LAB@CAD.LAB
        renew until 06/07/2016 12:46:30
05/31/2016 12:46:39  05/31/2016 22:46:35  ldap/cad_dc_01.cad.lab@CAD.LAB
        renew until 06/07/2016 12:46:30
[root@rhel7lab]# 

Я предполагаю, что этот список должен быть намного длиннее, но не сильным в ограничении , Я не знаю, правда ли это на самом деле, если не то, как это должно выглядеть, и как это сделать.

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

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

Спасибо, -9

6
задан 31 May 2016 в 23:02
2 ответа

Ваша конфигурация SSSD может быть виновником:

В keytab не обнаружено соответствие принципала rhel7lab.CAD.LAB@CAD.

Разве это не должно быть (скрыто) согласно klist вывод?

Можете ли вы попробовать эту конфигурацию SSSD (обратите внимание на суффикс по умолчанию):

[sssd]
domains = CAD
default_domain_suffix = CAD.LAB
services = nss, pam
config_file_version = 2
cache_credentials = true
debug_level = 7

Перезапустите SSSD, посмотрите, работает ли он?

0
ответ дан 3 December 2019 в 00:44

Я не уверен, что он напрямую отвечает на ваш вопрос, но пробовали ли вы realmd? Он автоматически обрабатывает БОЛЬШУЮ установку файла conf . Это, как правило, приводит к более предсказуемым ошибкам с сообщениями, которые легче найти в Google.

В вашем случае поиск по ключевым таблицам со смешанным регистром мне кажется неправильным:

rhel7lab.CAD.LAB

Ваше имя хоста или хосты запись с заглавной буквы? Области Kerberos должны быть полностью заглавными, но я не думаю, что это применимо ни к чему другому. Вот пример списка, созданного во время «соединения областей» на тестовом стенде:

LIN3$@LDAP.<REALM>.COM
host/LIN3@LDAP.<REALM>.COM
host/lin3.ldap.<domain>.com@LDAP.<REALM>.COM
0
ответ дан 3 December 2019 в 00:44

Теги

Похожие вопросы