On Fri, 2012-05-25 at 16:32 -0400, Fairlight wrote:
Hello,
I've set up OpenLDAP with PAM. Problem is, I needed name differentiation,
which sssd offers.
I've since migrated one of the two servers (I'm using replication) to
authenticate PAM using sssd.
I -can- log in just fine. One problem: the ldap_access_filter is being
ignored. I set it up to filter only to members of a certain group, and
it's just plain letting anyone log in if they're a user and have the
correct password for the account.
I've implemented memberOf as an overlay on the master and shadow LDAP
servers. I've even just totally purged and rebuilt the LDAP database from
original sources, based on something I read that said that if you implement
memberOf, it won't retroactively affect old accounts and groups. Still no
good.
I am -beyond- frustrated with this, and need it to work. I'm working with
an OpenSuSE 11.4 box, but I took out their old 1.4 version of sssd and put
in the latest 1.8.3 yesterday. So I'm working with the latest production
release.
One of the things that bothers me most is that the filter is present, but
even though it should be failing, it is letting anyone in. That makes no
sense to me. It looks like sssd was meant to err on the side of caution,
not permissiveness. That's why I don't understand why it's letting in just
anyone it finds, even if the filter fails. I even tried writing a
completely ridiculous filter that should never ever work (non-existant
group)...the users can still log in.
SSSD *is* deny-by-default. See below for why I suspect that you're
actually not hitting SSSD for evaluation.
Any help I can get at this point would be hugely appreciated. Let me
know
what you might need in terms of seeing configuration. I'll include the
relevant sssd section here [for confidentiality purposes, I changed my
client's domain name to my domain name, but everything else is accurate]:
[
domain/fairlite.com]
access_provider = ldap
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_schema = rfc2307
ldap_uri =
ldap://oh11.fairlite.com
ldap_search_base = dc=fairlite,dc=com
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/oh11.fairlite.com-CA.crt
cache_credentials = false
enumerate = true
ldap_access_filter = memberOf=cn=oh11,ou=Group,dc=fairlite,dc=com
ldap_access_order = filter
It's worth noting that I can't get memberOf to actually supply a memberuid
field with ldapsearch. That said, even if memberOf is -totally- broken,
I'd expect sssd to fail -all- logins, not let everyone in.
Any help I can get...I'd be extremely grateful for it. I really need
sssd's name differentiation. That's critical, and why I'm going with sssd
over direct ldap in the first place.
Ok, I need a little bit of extra information to sort this out. First of
all, can you show me what /var/log/secure (or SUSE's equivalent) shows
during a login?
My best guess is that you are missing pam_sss.so in the 'account' phase
of the PAM stack being executed at login (or it's configured to be
'optional'). Can you show me the /etc/pam.d/<service> file (and any
included files)?
Another possibility would be that (if this is sshd), you are missing
'use_pam yes' in sshd_config, which would mean that it would skip using
SSSD (and any other PAM module) for the account phase as well. If logins
are properly denied by a console login but allowed by SSH, this is a
likely potential culprit.
If none of that proves to be the issue, please set debug_level = 9 in
the [
domain/fairlite.com], restart SSSD, do a login and then send me
your /var/log/sssd/sssd_fairlite.com.log file (or wherever it is put on
SUSE) privately (sanitized of course).