SSSD игнорирует ldap_access_filter

SSSD игнорирует ldap_access_filter

Я настроил sssd и LDAP. Пользователи проходят аутентификацию и входят в систему. Проблема в том, что sssd, похоже, игнорирует опцию ldap_access_filter и позволяет всем пользователям входить в систему. Я проверил логи/отладку и pam_sss каждый раз авторизует пользователей независимо от фильтра (я пробовал несколько разных фильтров, все с одинаковым результатом).

Это команда, используемая для настройки системы:

authconfig 
    --updateall --passalgo=md5 --enableldap --enableldapauth  \
    --ldapserver=ldaps://ldap.example.com  \
    --ldapbase=ou=people,dc=example,dc=com \
    --enableldaptls --enableldapstarttls --disablekrb5 \
    --ldaploadcacert=http://certserver/cacerts/cacert.pem \
    --enablesssd --enablesssdauth --enableshadow \ 
    --enablecachecreds --enablemkhomedir

Это /etc/sssd/sssd.conf:

[domain/default]
debug_level = 9
ldap_id_use_start_tls = True
cache_credentials = True
ldap_search_base = ou=people,dc=example,dc=com
id_provider = ldap
auth_provider = ldap
ldap_access_filter = memberOf=cn=sysadmins,ou=people,dc=example,dc=com
chpass_provider = ldap
ldap_uri = ldaps://ldap.example.com
ldap_tls_cacertdir = /etc/openldap/cacerts
[sssd]
services = nss, pam
config_file_version = 2

domains = default
[nss]

[pam]

[sudo]

[autofs]

[ssh]

[pac]

Pam.d/system-auth:

auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

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

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so md5 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_oddjob_mkhomedir.so
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

Пример /var/log/secure:

Dec 30 17:40:36 test login: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost=  user=testacct
Dec 30 17:40:36 test login: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=testacct
Dec 30 17:40:36 test login: pam_unix(login:session): session opened for user testacct by LOGIN(uid=0)
Dec 30 17:40:36 test login: LOGIN ON tty1 BY testacct

решение1

Причина, по которой это не работает, в том, что вы не указываете фактический фильтр. Вы должны понимать, что такое "фильтр" согласно LDAP и SSSD. Вот мой собственный sssd.conf с фильтрами.

Мой фильтр доступа LDAP говорит, что если у пользователя, входящего в систему, есть host=servername или host=ALL, он может получить доступ к этой машине.

[домен/по умолчанию]

ldap_id_use_start_tls = Истина
cache_credentials = Ложь
ldap_search_base = dc=example,dc=net?sub?|(хост=palaceredirect.example.net)(хост=ALL)
ldap_group_search_base = ou=Группа,dc=пример,dc=net
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://library.example.net
ldap_tls_cacertdir = /etc/openldap/cacerts
поставщик_доступа = ldap
ldap_access_filter = (|(хост=palaceredirect.example.net)(хост=ALL))
ldap_schema = rfc2307bis
перечислить = Истина
autofs_provider = ldap

[сссд]
версия_файла_конфигурации = 2
службы = nss, pam, sudo, autofs

домены = по умолчанию

[нсс]

[пэм]

[судо]

[автофс]

Можете игнорировать мою базу поиска. Смысл этого был в том, чтобы позволить "enumerate = True" работать эффективно для getent passwd.

решение2

Хотя я всегда использовал /etc/security/access.conf для управления доступом к серверу, согласно документации (и рабочему примеру Сокеля), вы, возможно, пропустили строку «access_provider=ldap» в sssd.conf.

решение3

Попробуйте использовать следующее, так как это сработало для меня на базе дистрибутива CentOS.

access_provider = ldap
ldap_access_order = filter
ldap_group_member = member
ldap_access_filter = (memberOf=cn=vpn-clients,ou=Groups,dc=example,dc=com)

Связанный контент