--On Friday, September 22, 2017 10:45 AM -0400 Robert Heller heller@deepsoft.com wrote:
Operation 11 *seems* to be fetching the uid, using self, which has write access, which implies read access, which seems to work just fine, using ldapsearch from the command line:
[heller@c764guest ~]$ ldapsearch -D uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid Enter LDAP Password: dn: uid=test2user,ou=People,dc=deepsoft,dc=com uid: test2user
Is PAM actually bound as uid=testuser2, or is it bound as anonymous or some other DN? I can't tell from the little snippet of log that was in this thread. So yes, it works for you using ldapsearch when you bind as uid=test2user, but is that what pam is using?
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
At Fri, 22 Sep 2017 07:36:48 -0700 Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, September 22, 2017 10:45 AM -0400 Robert Heller heller@deepsoft.com wrote:
Operation 11 *seems* to be fetching the uid, using self, which has write access, which implies read access, which seems to work just fine, using ldapsearch from the command line:
[heller@c764guest ~]$ ldapsearch -D uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid Enter LDAP Password: dn: uid=test2user,ou=People,dc=deepsoft,dc=com uid: test2user
Is PAM actually bound as uid=testuser2, or is it bound as anonymous or some other DN? I can't tell from the little snippet of log that was in this thread. So yes, it works for you using ldapsearch when you bind as uid=test2user, but is that what pam is using?
It *seems* to be matching on the ACL for "self" in op 11.
But it turns out that sssd insists on using SSL/TLS, so I need to get that working first...
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org