Thanks a lot for the explanation. I have confused some things while crawling through the manuals. Now i have removed the 'ldap' from the /etc/nsswitch.conf. Now it looks like this: 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 nisplu My /etc/openldap/ldap.conf is this: TLS_CACERTDIR /etc/openldap/cacerts/ SASL_NOCANON on URI ldap://ldap.mydomain.tld BASE o=XXX The sssd.conf is this: [sssd] config_file_version = 2 services = nss, pam, autofs domains = default [nss] filter_groups = root filter_users = root [pam] [domain/default] ldap_uri = ldap://ldap.mydomain.tld ldap_search_base = 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/ssl/certs chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=YYY,o=XXX ldap_group_search_base = ou=YYY,o=XXX access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host autofs_provider = ldap krb5_realm = # [autofs] When i stop the sssd deamon, no login at all is possible. But when i start sssd, again login is successful, independendly from what i write into ldap_access_order and ldap_user_authorized_host (if i don't commit syntax errors). I also tried with ldap_access_filter and inserting "pam_check_host_attr yes" into ldap.conf. Still the same: When username and password are correct, the host atribute is ignored. Is there another config file i have to edit? With kind regards, ulrich On 05/05/2015 11:43 PM, Gordon Messmer wrote:> On 05/05/2015 11:14 AM, Ulrich Hiller wrote: >> On 05/05/2015 06:47 PM, Gordon Messmer wrote: >>> This is wrong. Don't use sss and ldap together. It's redundant. At >>> best it will cause performance problems. >>> >>> Get rid of the ldap module and see if the system starts working >>> correctly with just sssd. It's possible that right now sssd is >>> correctly filtering users, but the PADL ldap module is providing them. >> >> This was a good hint (i should have got the idea myself). >> Now i set >> passwd: files ldap >> shadow: files ldap >> group: files ldap > > That's exactly the opposite of what I suggested. Your system is now > using the deprecated PADL ldap module for name service instead of sssd. > > You should probably remove nscd and nss-pam-ldapd from your system > entirely. They're deprecated, and they're going to waste your time. > >> and got "pam_unix(sshd:auth): check pass; user unknown" > > That seems consistent with having "ldap" in nsswitch.conf and no > /etc/ldap.conf. > > Don't use "ldap". Use "sss". > >> So, does it mean only the NSS is providing the ldap user information, >> and sssd cannot read the pam information? So pam is not set up correctly? > > That's a confusing question, so let me explain the stack a little. > > At one end you have your applications. Everything that needs to resolve > user names, groups, hosts, services, etc is here. For example, "ls". > "ls" reads directories and stats files, those files have numeric user > and group IDs, which need to be resolved to names. > > In the middle you have glibc and its "nss" API. "nss" provides a single > interface to applications for resolving names and numbers for the types > defined in nsswitch.conf. > > At the other end of the stack you have nss modules. These include the > "unix" module which reads files in /etc, the deprecated LDAP module from > PADL, and the sss module that's part of sssd. > > (sssd extends the stack a little bit. it provides one interface to nss, > and has its own modules to resolve names through LDAP and other > directories) > > PAM is completely separate from all of that. PAM provides > authentication services. It's a completely different interface from > resolving names and numbers. > > So, right now it sounds like you have the system configured to read > information from the "ldap" module, but that module needs > /etc/ldap.conf. You should be using the "sss" module in nsswitch.conf > instead. > >> I am confused about what to do now. >> Do i have to configure anything else in /etc/pam.d apart from >> system-auth? > > You probably shouldn't ever touch the files in /etc/pam.d. > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >
On 05/06/2015 07:24 AM, Ulrich Hiller wrote:> > Now i have removed the 'ldap' from the /etc/nsswitch.conf. Now it looks > like this:Looks good.> My /etc/openldap/ldap.conf is this:OK, but that file isn't used for name service or authentication. Mostly just the openldap tools (ldapsearch, ldapadd, ldapmodify).> The sssd.conf is this:...> [nss] > filter_groups = root > filter_users = rootnitpick: those are the defaults. Probably don't need to set them.> [domain/default] > ldap_id_use_start_tls = True > ldap_tls_cacertdir = /etc/ssl/certs > ldap_tls_reqcert = neverNot sure about that setting. "allow" is probably what you want if you're using starttls.> access_provider = ldap > ldap_access_order = host > ldap_user_authorized_host = host...> When i stop the sssd deamon, no login at all is possible.OK. Remember that previously you had both sssd and ldap configured to provide user information. You'll want to watch the logs for more information. Start by determining whether the problem is in the name service or authentication step. Use "id <user>" or "getent passwd <user>" to determine whether user information is available through sssd. If it is not, then you probably want to start paring out settings that you added (assuming that you started with a file written by authconfig) until that's working. If user data is available, then start looking at your pam configuration. It looks like you made some changes there, and not all of them make sense. In the auth stack, you're calling pam_unix.so twice. Remove the last one. You've also marked pam_sss.so as required instead of sufficient, which is definitely wrong. On success of a "sufficient" module, processing stops. On success of a "required" module, processing will continue, and will reach pam_deny.so. See the man page for pam.conf for more information.
Thanks a lot for looking over the config. I am at the topic "user data is available" id <username> and getent passwd and ldapsearch -x -b "ou=XXX,o=YYY" uid=<username> give the correct results ldapsearch gives also the correct host attribute i have set in the ldap server. Regarding the manpage of sssd.conf the lines access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host should be correct. login with the wrong password gives a denied login. login with the correct password always works. This is my sitution since the begin of my thread. When i login from a "wrong" host which is different than the one in the host attribute of the ldap, i expect a message like the one from my opensuse boxes where it works: opensuse: sshd[7926]: pam_sss(sshd:account): Access denied for user>username>: 6 (Permission denied)But instead i get centos: sshd[7929]: pam_unix(sshd:session): session opened for user <username> and i am in. [ ssh'ing and login locally at the console give the same results ] So, maybe it is a pam problem. Comparing the pam.d of my opensuse boxes with my centos box i see common-* files which are inluced, e.g. in the sshd file. They do not exist in centos. Instead i have there the system-auth where the common files should be combined. Fiddling around with the contence of my opensuse commen-* in my centos box's system-auth i did not get further. I have installed on centos: fprintd-pam-0.5.0-4.0.el7_0.x86_64 pam-1.1.8-12.el7.x86_64 gnome-keyring-pam-3.8.2-10.el7.x86_64 pam_krb5-2.4.8-4.el7.x86_64 Are you sure i do not need nss-pam-ldapd? Googling around i have read something about a /etc/nslcd.conf which comes with this package. Is that needed? On my opensuse i have much more: gnome-keyring-pam-3.10.1-6.1.x86_64 pam-config-0.86-2.1.2.x86_64 pam-1.1.8-6.1.x86_64 gnome-keyring-pam-32bit-3.10.1-6.1.x86_64 pam-modules-12.1-20.1.2.x86_64 pam_ldap-186-6.1.3.x86_64 pam-devel-1.1.8-6.1.x86_64 pam-32bit-1.1.8-6.1.x86_64 pam-modules-32bit-12.1-20.1.2.x86_64 pam_ldap-32bit-186-6.1.3.x86_64 With kind regards and sorry for the stupid newbie's questions, ulrich On 05/06/2015 07:02 PM, Gordon Messmer wrote:> On 05/06/2015 07:24 AM, Ulrich Hiller wrote: >> >> Now i have removed the 'ldap' from the /etc/nsswitch.conf. Now it looks >> like this: > > Looks good. > >> My /etc/openldap/ldap.conf is this: > > OK, but that file isn't used for name service or authentication. Mostly > just the openldap tools (ldapsearch, ldapadd, ldapmodify). > >> The sssd.conf is this: > ... >> [nss] >> filter_groups = root >> filter_users = root > > nitpick: those are the defaults. Probably don't need to set them. > >> [domain/default] >> ldap_id_use_start_tls = True >> ldap_tls_cacertdir = /etc/ssl/certs >> ldap_tls_reqcert = never > > Not sure about that setting. "allow" is probably what you want if > you're using starttls. > >> access_provider = ldap >> ldap_access_order = host >> ldap_user_authorized_host = host > ... >> When i stop the sssd deamon, no login at all is possible. > > OK. Remember that previously you had both sssd and ldap configured to > provide user information. > > You'll want to watch the logs for more information. > > Start by determining whether the problem is in the name service or > authentication step. Use "id <user>" or "getent passwd <user>" to > determine whether user information is available through sssd. If it is > not, then you probably want to start paring out settings that you added > (assuming that you started with a file written by authconfig) until > that's working. > > If user data is available, then start looking at your pam configuration. > It looks like you made some changes there, and not all of them make > sense. In the auth stack, you're calling pam_unix.so twice. Remove the > last one. You've also marked pam_sss.so as required instead of > sufficient, which is definitely wrong. On success of a "sufficient" > module, processing stops. On success of a "required" module, processing > will continue, and will reach pam_deny.so. See the man page for > pam.conf for more information. > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >