On 05/05/2015 06:47 PM, Gordon Messmer wrote:> On 05/05/2015 03:02 AM, Ulrich Hiller wrote: >> /etc/openldap/ldap.conf contains the line: >> ------------------------------------------ >> pam_check_host_attr yes > > /etc/openldap/ldap.conf is the configuration file for openldap clients. > It is not used for system authentication or name service. > >> 'pam_check_host_attr yes' is in /etc/openldap/ldap.conf. /etc/ldap.conf >> is a softlink to that file. > > Those two files have completely different syntax and are used by > different software. Don't symlink them.i deleted the link now. /etc/ldap.conf was not present before. I gave openldap> >> /etc/sssd/sssd.conf: >> -------------------- > > If you're using sssd, then you're not using (or shouldn't be using) the > PADL nss module. In that case, /etc/ldap.conf shouldn't even be present. > >> [domain/default] >> access_provider = ldap >> ldap_access_filter = memberOf=ou=YYYY,o=XXXX >> ldap_access_order = host > > ldap_access_filter should be an LDAP filter, not an OU. However, it's > only used when ldap_access_order=filter. When using > ldap_access_order=host, it should not be present. >ldap_access_filter is now commented out.>> in /etc/nscd.conf: > > nscd is also not used when using sssd. > >> /etc/nsswitch.conf: >> ................... >> passwd: files sss ldap >> shadow: files sss ldap >> group: files sss ldap > > 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 and got "pam_unix(sshd:auth): check pass; user unknown" the same when i set in sssd.conf services = pam 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? I am confused about what to do now. Do i have to configure anything else in /etc/pam.d apart from system-auth? With kind regards, ulrich
Hi, I am confused about what to do now.> Do i have to configure anything else in /etc/pam.d apart from system-auth? >IMO, you have to configure sssd.conf properly. Please add "ldap_user_authorized_host = host" in your sssd.conf which you have not configured. After that please check again. For more information, please refer below link. <https://lists.fedorahosted.org/pipermail/sssd-users/2015-May/003001.html> --Regards Ashishkumar S. Yadav
Hi, added, but no success. My sssd.conf looks now so: [sssd] config_file_version = 2 services = nss,pam domains = default # SSSD will not start if you do not configure any domains. # Add new domain configurations as [domain/<NAME>] sections, and # then add the list of domains (in the order you want them to be # queried) to the "domains" attribute below and uncomment it. [nss] filter_groups = root filter_users = root [pam] # Section created by YaST [domain/default] ldap_uri = ldap://ldap.mpia-hd.mpg.de ldap_search_base = o=mpia 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=people,o=mpia ldap_group_search_base = ou=group,o=mpia access_provider = ldap #ldap_access_filter = memberOf=ou=people,o=mpia ldap_access_order = host ldap_user_authorized_host = host and my nsswitch,conf: passwd: files ldap shadow: files ldap group: files ldap #initgroups: files #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss ldap publickey: nisplus automount: files sss ldap aliases: files nisplus I get a "user unknown". With passwd: files sss ldap shadow: files sss ldap group: files sss ldap in nsswitch.conf all ldap users can login, independently from the host attribute. With kind regards, ulrich On 05/05/2015 08:58 PM, Ashish Yadav wrote:> Hi, > > I am confused about what to do now. >> Do i have to configure anything else in /etc/pam.d apart from system-auth? >> > > IMO, you have to configure sssd.conf properly. > > Please add "ldap_user_authorized_host = host" in your sssd.conf which you > have not configured. > After that please check again. > > For more information, please refer below link. > > <https://lists.fedorahosted.org/pipermail/sssd-users/2015-May/003001.html> > > --Regards > Ashishkumar S. Yadav > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > >
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 ldapThat'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.
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 > >