[CentOS] ldap host attribute is ignored

Thu May 7 19:07:45 UTC 2015
Ulrich Hiller <hiller at mpia-hd.mpg.de>

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
> 
>