[SSSD] ldap_access_filter
Hi there! I've been playing with the SSSD 'ldap_acces_filter' directive. access_provider = ldap ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com I expected a similar functionality to the old ldap.conf: pam_groupdn cn=HOSTNAME,ou=hosts,dc=example,dc=com pam_member_attribute member In the old case, a query was issued to the LDAP backend looking for a member within cn=HOSTNAME,ou=hosts,dc=example,dc=com (the host object). In the new case (SSSD), this query is made (excerpt from my OpenLDAP server): SRCH base=uid=aborrero,ou=users,dc=example,dc=com scope=0 deref=0 filter=((uid=aborrero)(objectClass=posixAccount)(member=cn=centos6,ou=hosts,dc=example,dc=com)) This means that SSSD is looking inside the user object, instead of the host object. In sssd-ldap(5) I don't see any additional options to configure this behavior. To migrate to SSSD I would require to filter member which are declared within host objects. Could you please give me some advices about this? Also, please point me to the right mailing list if this is not the one. regards. -- Arturo Borrero González Departamento de Seguridad Informática (n...@cica.es) Centro Informático Científico de Andalucía (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejería de Economía, Innovación, Ciencia y Empleo Junta de Andalucía smime.p7s Description: S/MIME Cryptographic Signature ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] ldap_access_filter
On Fri, Jan 24, 2014 at 02:44:49PM +0100, Arturo Borrero wrote: Hi there! I've been playing with the SSSD 'ldap_acces_filter' directive. access_provider = ldap ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com I expected a similar functionality to the old ldap.conf: pam_groupdn cn=HOSTNAME,ou=hosts,dc=example,dc=com pam_member_attribute member In the old case, a query was issued to the LDAP backend looking for a member within cn=HOSTNAME,ou=hosts,dc=example,dc=com (the host object). In the new case (SSSD), this query is made (excerpt from my OpenLDAP server): SRCH base=uid=aborrero,ou=users,dc=example,dc=com scope=0 deref=0 filter=((uid=aborrero)(objectClass=posixAccount)(member=cn=centos6,ou=hosts,dc=example,dc=com)) This means that SSSD is looking inside the user object, instead of the host object. In sssd-ldap(5) I don't see any additional options to configure this behavior. To migrate to SSSD I would require to filter member which are declared within host objects. Could you please give me some advices about this? Also, please point me to the right mailing list if this is not the one. regards. I'm confused a bit, are you sure pam_groupdn has anything to do with host objects? Per the pam_ldap man page, the functionality should ensure that the user logging in is a member of a group with a certain DN: pam_groupdn groupdn Specifies the distinguished name of a group to which a user must belong for logon authorization to succeed. pam_member_attribute attribute Specifies the attribute to use when testing a user's membership of a group specified in the pam_groupdn option. In that case, maybe the simple access provider would be what you're looking for? Can you paste an example of a user entry and the entries that restrict his login? ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] ldap_access_filter being ignored?
Only Stephen Gallagher would say something like: 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). /etc/ssh/sshd_config does contain UsePAM yes /etc/pam.d/sshd: auth requisite pam_nologin.so auth includecommon-auth account requisite pam_nologin.so account includecommon-account password includecommon-password session required pam_loginuid.so session includecommon-session session optional pam_lastlog.so silent noupdate showfailed /etc/pam.d/common-auth: auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_sss.so use_first_pass auth required pam_deny.so /etc/pam.d/common-account: accountsufficient pam_unix.so account [default=bad success=ok user_unknown=ignore] pam_sss.so /etc/pam.d/common-password: password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 password sufficient pam_unix.so nullok md5 shadow use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so /etc/pam.d/common-session: sessionrequired pam_limits.so sessionrequired pam_unix.so sessionsufficient pam_sss.so sessionoptional pam_gnome_keyring.soauto_start only_if=gdm,lxdm /etc/sssd/sssd.conf domain definition: [domain/fairlite.com] debug_level = 9 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 Logging from /var/log/messages after logging in with user in question: May 26 11:30:52 oh11 sshd[23246]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=shell1.somehost.com user=fairlite May 26 11:30:52 oh11 slapd[10761]: conn=1102 op=13 SRCH base=dc=fairlite,dc=com scope=2 deref=0 filter=((uid=fairlite)(objectClass=posixAccount)) May 26 11:30:52 oh11 slapd[10761]: conn=1102 op=13 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap May 26 11:30:52 oh11 slapd[10761]: conn=1102 op=13 SEARCH RESULT tag=101 err=0 nentries=1 text= May 26 11:30:52 oh11 slapd[10761]: conn=1102 op=14 SRCH
[SSSD] ldap_access_filter being ignored?
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. 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. mark- -- Fairlight- ||| My classmates would copulate with | Fairlight Consulting __/\__ ||| anything that moved, but I never | http://www.fairlite.com ||| saw any reason to limit myself. - | fairl...@fairlite.com \/||| -Emo Phillips | (502) 509-3840 ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
