Hmmm...., i have made now a complete new install but the problem
persists: ldap authentication works, but the host attribute is ignored.
I have installed CentOS7 64bit with KDE.
I did not do any 'yum update' or install of extra packages so far.
these pam and ldap packages are installed:
openldap-devel-2.4.39-6.el7.x86_64
openssh-ldap-6.6.1p1-11.el7.x86_64
openldap-2.4.39-6.el7.x86_64
python-ldap-2.4.15-2.el7.x86_64
compat-openldap-2.3.43-5.el7.x86_64
openldap-clients-2.4.39-6.el7.x86_64
fprintd-pam-0.5.0-4.0.el7_0.x86_64
gnome-keyring-pam-3.8.2-10.el7.x86_64
pam-1.1.8-12.el7.x86_64
I ran authconfig-tui and set "use ldap", "use md5 password", "use shadow
password", "use ldap authentication", "use tls",
"server=ldap://myldapserver.com";, "basedn=o=XXX"
my /etc/openldap/ldap.conf:
BASE o=XXX
URI ldap://myldapserver.com/
TLS_CACERTDIR /etc/ssl/certs
SASL_NOCANON on
My /etc/sssd/sssd.conf:
[domain/default]
ldap_uri = ldap://myldapserver.com/
ldap_search_base = ou=YYY,o=XXX
ldap_schema = rfc2307bis
id_provider = ldap
ldap_user_uuid = entryuuid
ldap_group_uuid = entryuuid
ldap_id_use_start_tls = True
enumerate = False
cache_credentials = False
ldap_tls_cacertdir = /etc/openldap/cacerts/
chpass_provider = ldap
auth_provider = ldap
ldap_tls_reqcert = never
ldap_user_search_base = ou=YYY,o=XXX
access_provider = ldap
ldap_access_order = host
ldap_user_authorized_host = host
autofs_provider = ldap
[sssd]
services = nss, pam, autofs
config_file_version = 2
domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
My /etc/pam.d/system-auth
#%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 sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 200 quiet_success
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 2000 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 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_systemd.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
My /etc/pam.d/password-auth:
#%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 sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 200 quiet_success
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 2000 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 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_systemd.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
My /etc/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 sss
aliases: files nisplus
nscd is NOT installed
apart from the uid boundary interval in /etc/pam-d i left the files in
this directory as they were created by authconfig. I did not copy
anything from other systems.
ldapsearch can read the user information. The user can again login, no
matter of the contence of the ldap's host attribute.
I feel a bit embarrassed now. but ... does anybody have another idea?
With kind regards, ulrich
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
