[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