Bill, The slapacl command can help here. It analyzes permissions granted by the ACLs and if the -d -1 option (debugging) is included with the command it will tell which ACL is processed that grants what permission. That will help you identify why your user isn't being granted the permissions you expect. Below are a couple examples. You can craft your own slapacl command from them. slapacl -f /usr/local/etc/openldap/slapd.conf -v \ -U bjorn -b "o=University of Michigan,c=US" \ "o/read:University of Michigan" Tests whether the user bjorn can access the attribute o of the entry o=University of Michigan,c=US at read level slapacl -f slapd.conf -v -D "cn=Belle Moxley,ou=Accounting,dc=example,dc=com" -b "cn=Andre Grills,ou=Janitorial,dc=example,dc=com" telephoneNumber/read fax/read facsimileTelephoneNumber/read Tests whether a user from Accounting can access telephone and fax number attributes for a user in Janitorial. Let me know if you need further assistance. Jason Trupp Symas Corporation (855) LDAP-GUY -----Original Message----- From: openldap-technical <openldap-technical-bounces(a)openldap.org&gt; On Behalf Of Bill Bradford Sent: Thursday, August 30, 2018 2:17 PM To: openldap-technical(a)openldap.org Subject: Problem with ACLs Trying to give a single user "read only" access to everything in the database including userPassword info. Here's the LDIF file I'm using w/ldapmodify: dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,dc=domain,dc=com" write by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=Manager,dc=domain,dc=com" write by * read However, authenticating as uid=romanager,ou=Users,dc=domain,dc=com lets that user read his own password hash, but nobody else's. In other words it's authenticating just like any other user, and it's as if the by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read line is being ignored. The change is being applied as I've looked at the database files for the config. I've tried restarting slapd, etc. Any suggestions? @(#) $OpenLDAP: slapd 2.4.44 (Aug 4 2017 14:23:27) $ Bill -- Bill Bradford Houston, Texas USA

Yes sir, per the ldap.conf man page there is no SSL ON option. Please comment that line out and try the slapacl command again. Thanks, Jason Trupp Symas Corporation (855) LDAP-GUY -----Original Message----- From: Bill Bradford <mrbill(a)mrbill.net&gt; Sent: Friday, August 31, 2018 12:56 PM To: Jason Trupp <jtrupp(a)symas.com&gt;; openldap-technical(a)openldap.org Subject: Re: Problem with ACLs On Fri, Aug 31, 2018 at 09:55:25AM -0500, Jason Trupp wrote: <snip> Jason, thanks. I'll start with: my server is working fine, I have a multi-master replication set up (one master in each city) with a read-only slave in each city that the clients hit. Tried this (slapacl) last night, but it seems to be assuming that everything is in ldap.conf instead of in separate files as per the newer config ways: (actual BaseDN replaced with dc=domain,dc=com for security reasons) [root@hou-1 openldap]# slapacl -f /etc/openldap/ldap.conf -v -D "uid=romanager,ou=Users,dc=domain,dc=com" -b "employeeNumber=413111,ou=people,dc=domain,dc=com" userPassword/read 5b897f57 /etc/openldap/ldap.conf: line 15: unknown directive <SSL> outside backend info and database definitions. slapacl: bad configuration file! My /etc/openldap/ldap.conf looks like this: ------------------------------------------- # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never SSL ON TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT allow TLSVerifyClient never TLSCACertificateFile /etc/openldap/certs/ca-bundle.crt TLSCertificateFile /etc/openldap/certs/server.crt TLSCertificateKeyFile /etc/openldap/certs/server.key # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on ------------------------------------------- All of my actual config is under /etc/openldap/slap.d: [root@hou-1 slapd.d]# pwd /etc/openldap/slapd.d [root@hou-1 slapd.d]# find . -print . ./cn=config.ldif ./cn=config ./cn=config/olcDatabase={-1}frontend.ldif ./cn=config/cn=schema.ldif ./cn=config/cn=schema ./cn=config/cn=schema/cn={8}sudo.ldif ./cn=config/cn=schema/cn={3}inetorgperson.ldif ./cn=config/cn=schema/cn={5}openssh-lpk.ldif ./cn=config/cn=schema/cn={6}apple-user.ldif ./cn=config/cn=schema/cn={0}core.ldif ./cn=config/cn=schema/cn={7}domain.ldif ./cn=config/cn=schema/cn={1}cosine.ldif ./cn=config/cn=schema/cn={4}ldapns.ldif ./cn=config/cn=schema/cn={2}nis.ldif ./cn=config/out ./cn=config/olcDatabase={1}monitor.ldif ./cn=config/cn=module{0}.ldif ./cn=config/olcDatabase={0}config.ldif ./cn=config/olcDatabase={2}hdb ./cn=config/olcDatabase={2}hdb/olcOverlay={2}syncprov.ldif ./cn=config/olcDatabase={2}hdb/olcOverlay={1}syncprov.ldif ./cn=config/olcDatabase={2}hdb/olcOverlay={0}syncprov.ldif ./cn=config/olcDatabase={2}hdb.ldif -- Bill Bradford Houston, Texas USA

--On Friday, August 31, 2018 1:55 PM -0500 Bill Bradford <mrbill(a)mrbill.net&gt; wrote: Hi Bill, As was noted to you yesterday on the IRC channel, slapacl takes the same -f/-F flags as the other slap* commands. So if you are using a cn=config based server, then you use -F /path/to/configuration. You would never provide an ldap.conf file to any of these utilities, as that's a client side configuration directive. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

--On Friday, August 31, 2018 2:25 PM -0500 Bill Bradford <mrbill(a)mrbill.net&gt; wrote: Hi Bill, This has nothing to do with ACLs. You failed to even bind to the server. This means that either: (a) The user DN provided to the -D option does not exist on the ldapserver or (b) you provided the wrong password for the user --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

--On Thursday, August 30, 2018 3:17 PM -0500 Bill Bradford <mrbill(a)mrbill.net&gt; wrote: This should also be dn.exact Are you sure this is the DN returned by ldapwhoami? Past that, I'd suggest you test with slapacl and potentially ACL level debugging. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

--On Friday, August 31, 2018 1:59 PM -0500 Bill Bradford <mrbill(a)mrbill.net&gt; wrote: ACLs never apply to the rootdn. This is clearly documented in the man page. This has nothing to do with logging into a linux box. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>