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