[SSSD] ldap_access_filter being ignored?
Stephen Gallagher
sgallagh at redhat.com
Sat May 26 12:26:51 UTC 2012
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120526/692265eb/attachment.sig>
More information about the sssd-devel
mailing list