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


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

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

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

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

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

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

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

Я довольно сильно разбираюсь в unix / linux в целом, но я не уверен в AD, Kerberos или LDAP.

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

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

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

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

Шаг 4: Настройте Kerberos. Санированная версия /etc/krb5.conf:

includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = CAD.LAB
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 CAD.LAB = {
  kdc = cad_dc_01.cad.lab
 }

[domain_realm]
 .cad.lab = CAD.LAB
 cad.lab = CAD.LAB

Шаг 5: Установка samba.conf достаточно для SSSD. /etc/samba/smb.conf [глобалы], дезинфицированные:

[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: Присоедините систему к САПР. «kinit Administrator», а затем «net ads join -k». Работает без проблем.

Шаг 7. Настройка SSSD. Sanitized /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, я нахожу несколько вещей, которые дают мне представление о том, где что-то прикручивается, но мне не удалось найти способ исправить их: все руководства, которые я прочитал дает последовательность шагов и предполагает, что каждый шаг работает. Я ничего не нашел, чтобы помочь мне разобраться, что случилось, когда один из этих шагов не работает.

Я не буду публиковать весь файл 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
2018-05-31 20:02


Источник


Вы были проверить это сообщение вне? - ewwhite
Вы посмотрели Руководство по интеграции с RHEL Windows? - shodanshok
@ewwhite. Да, я читал это. Это одна из причин, по которым я предпочитаю SSSD. Моя проблема заключается не в выборе того, что нужно использовать, а в том, чтобы работать над документом. - Kill Dash Nine
@shodanshok: это постоянное крепление на моем втором дисплее. Не стесняйтесь смотреть на странице 7, пункт 3.c.b, где последний элемент - «klist -k» и читает «Перечислите ключи для системы и проверьте, есть ли главный хост». Нет примера вывода того, что нужно искать, и никаких рекомендаций по устранению неполадок; документ просто предполагает, что он работает. Я также посмотрел access.redhat.com/solutions/1755013 который является менее запутанным документом. Я следил за ними обоими буквами, заменяя только мои имена, ни один из них не работает, и оба дают те же результаты, о которых я подробно рассказал выше. - Kill Dash Nine
По моему опыту, иногда AD занимает несколько минут, прежде чем вы сможете начать аутентификацию пользователей в системе Linux. Не совсем уверен, почему. Это было также в однодоменном лесу. Теперь, если ваша основная цель - пользовательский аут, давайте сосредоточимся на этом. Можете ли вы предоставить некоторые из ваших / var / log / secure (rhel) для неудачного входа пользователя? Опишите этот рабочий процесс: ssh, сеанс консоли, что? - bgStack15


Ответы:


Консоль SSSD может быть виновником:

Нет основного соответствия rhel7lab.CAD.LAB@CAD, найденного в keytab.

Разве это не должно быть CAD.LAB@CAD.LAB, в соответствии с выходом klist?

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

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

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


0
2018-02-23 08:51



Просто заметил время публикации на вопрос ... ах хорошо. Прошло всего 2 года> _ < - shearn89


Я не уверен, что это напрямую касается вашего вопроса, но вы попробовали realmd? Он обрабатывает много conf автоматически. Это приводит к появлению более предсказуемых ошибок с сообщениями, которые легче Googled.

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

rhel7lab.CAD.LAB

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

LIN3$@LDAP.<REALM>.COM
host/LIN3@LDAP.<REALM>.COM
host/lin3.ldap.<domain>.com@LDAP.<REALM>.COM

0
2018-04-21 03:26