Я тратил много, много счастливый часов изучения конфигурации sssd, необходимой для интеграции RHEL7 и Active Directory. Большая часть из них включала просмотр множества сообщений здесь об интеграции SSSD и AD, особенно связанных с локальным поиском UID в AD. Хотя они и были поучительными, ни один из них, похоже, не охватил мой сценарий.

Моя проблема в настоящее время заключается в том, что я могу войти в систему через SSH, используя пользователя Windows («DOMAIN1 \ sales1» с использованием пароля пользователя Windows), и SSSD будет правильно проверять состояние пользователя Windows. Если пользователь Windows отключен или срок действия учетной записи истек, вход в систему не выполняется - все в порядке.

Если я вхожу в систему через SSH, используя пользователя Linux с тем же идентификатором, что и пользователь Windows («sales1» с использованием пароля пользователя Linux), SSSD будет искать и соответствовать пользователю Windows в AD, но будет НЕ проверить учетную запись AD. Я применил UID пользователя linux к атрибуту uidNumber пользователя Windows, чтобы помочь пользователю AD-linux соответствовать, но ничего, что я пытаюсь, похоже, не влияет на проверку состояния пользователя AD при входе в систему с использованием учетных данных пользователя linux.

sssd.conf

[sssd]
domains = domain1.local
config_file_version = 2
services = nss, pam
debug_level = 7


[domain/domain1.local]
ad_domain = domain1.local
krb5_realm = DOMAIN1.LOCAL
realmd_tags = manages-system joined-with-adcli 

id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

## We do NOT want offline caching of Windows authentications
cache_credentials = False
krb5_store_password_if_offline = False

## Found this ticket for sssd: https://fedorahosted.org/sssd/ticket/2851
## might be the GC lookup that is stopping expired users from being denied access
ad_enable_gc = False
ldap_id_mapping = False
override_homedir = /home/%u
default_shell = /bin/bash
debug_level = 8

nsswitch.conf

passwd:     files sss
shadow:     files sss
group:      files sss
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
netgroup:   files sss
publickey:  nisplus
automount:  files
aliases:    files nisplus

pam.d / пароль-auth-ac

(как настроено authconfig)

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        [default=1 success=ok] pam_localuser.so
auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

Жизнеспособно ли то, что я пытаюсь достичь, используя SSSD?

Редактировать # 1

Я новичок в sssd и влиянии интеграции AD на систему RHEL, поэтому считаю, что мой подход к решению моих требований неверен.

У меня есть существующий автономный сервер RHEL, на котором запущено приложение, которое использует аутентификацию пользователя Linux (passwd, shadow, groups). Мне было дано требование проверять пользователей приложения в объявлении, прежде чем разрешить им доступ к приложению linux. Приложение ДОЛЖЕН продолжать использовать существующие идентификаторы пользователей и групп linux, так как в настоящее время он не может работать ни с длинными пользователями Windows, ни с идентификаторами пользователя с "@", а большая часть поведения acl построена на существующей группе.

Мой первоначальный подход (который привел к заданию этого вопроса) заключался в том, чтобы использовать sssd & realm для присоединения RHEL к AD, а затем (через pam / sssd) получить логин linux, чтобы найти подходящего пользователя AD для пользователя linux, скорее всего, используя Атрибуты POSIX для пользователя Windows и проверка их учетной записи AD.

Я думаю, что мне действительно нужно достичь
- Установите карту / отношения между пользователем AD и локальным пользователем Linux, который использует приложение

Когда такая карта / взаимосвязь существует:
- Требовать только пароль AD при входе в систему
- Проверка статуса доступа к учетной записи AD (учетная запись включена / срок действия не истек / права входа в систему GPO / член правой группы AD)
- Всегда используйте локальное имя пользователя, uid и gid сопоставленного пользователя.

Я думаю, используя realm permit --groups adgroup@dlomain.ad позволит мне ограничить вход пользователей AD в определенную группу AD (в настоящее время мы не хотим, чтобы пользователи Windows входили в Linux, за исключением случая использования приложения, указанного выше).
Я не уверен в лучшем способе сопоставления пользователей AD с существующими пользователями Linux. В настоящее время приложение создает и поддерживает учетные записи пользователей Linux, поэтому любое решение должно уметь работать с этим.

Из того, что я прочитал за последние 2 недели, я думаю, что у меня есть следующие варианты:
- Используйте локальные переопределения SSSD для сопоставления пользователей AD и Linux.
У меня нет опыта в этом, поэтому я полагаюсь на такие статьи, как SSSD Локальные переопределения как индикаторы того, что это жизнеспособно
- Полагаться на атрибуты POSIX, определенные для пользователя AD.
Это означает, что эти значения будут использоваться пользователем на КАЖДОМ сервере, к которому он подключается, который также ссылается на атрибуты POSIX. Я не уверен, что это разумно в долгосрочной перспективе. Тестирование показало, что с uid, uidNumber и gidNumber, определенными для пользователя Windows, когда пользователь входит в Linux, использует эти значения. Это требует усилий по обслуживанию, чтобы гарантировать, что эти значения определены для пользователя AD.
- Установите IPA и используйте представления id.
У меня нет опыта установки или настройки этого, но мои чтения показывают, что это возможный вариант. Похоже, что использование этой опции требует дополнительных затрат на установку, настройку и обслуживание.

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