On Fri, Aug 31, 2018 at 09:55:25AM -0500, Jason Trupp wrote:

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.

<snip>

Let me know if you need further assistance.

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

-----Original Message----- From: openldap-technical openldap-technical-bounces@openldap.org On Behalf Of Bill Bradford Sent: Thursday, August 30, 2018 2:17 PM To: openldap-technical@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

On Fri, Aug 31, 2018 at 12:58:48PM -0500, Jason Trupp wrote:

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.

It's complaining about every line in the file it appears.

[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 5b898250 /etc/openldap/ldap.conf: line 16: unknown directive <TLS_CACERTDIR> outside backend info and database definitions. slapacl: bad configuration file!

Bill

On Fri, Aug 31, 2018 at 11:05:34AM -0700, Quanah Gibson-Mount 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.

Quanah,

*facepalm* my mistake.

Got further this time. slapacl says it should work:

[root@hou-1 openldap]# slapacl -F /etc/openldap/slapd.d -v -D "uid=romanager,ou=Users,dc=domain,dc=com" -b "employeeNumber=413111,ou=people,dc=domain,dc=com" userPassword/read authcDN: "uid=romanager,ou=users,dc=domain,dc=com" read access to userPassword: ALLOWED

But when I try to look up data with ldapsearch, as that user:

$ ldapsearch -x -W -H ldaps://hou-1.master.ldap.prod.domain.com -D "uid=romanager,ou=Users,dc=domain,dc=com" -b "ou=people,dc=domain,dc=com" -s sub employeeNumber=413111 Enter LDAP Password: ldap_bind: Invalid credentials (49)

It works as RootDN of course:

$ ldapsearch -x -W -H ldaps://hou-1.master.ldap.prod.domain.com -D "cn=manager,dc=domain,dc=com" -b "ou=people,dc=domain,dc=com" -s sub employeeNumber=1809 |grep userPassword Enter LDAP Password: userPassword:: PASSWORDHASH-SANITIZED

HOWEVER, I can set up a profile in Apache Directory Sudio with the same user (uid=romanager,ou=Users,dc=domain,dc=com) as BindDN, WITH password, click "Check Authentication" and it passes the test, and connect/bind to the directory as that user.. but then it will only show me userPassword for the user I used for BindDN itself, and none else.

I can connect with ADS using the RootDN info as BindDN and see all info for every user, as expected.

Thank y'all for all of the help so far. It's really appreciated.

Even if I've made a couple of stupid goof mistakes.

Bill

On Fri, Aug 31, 2018 at 11:33:59AM -0700, Quanah Gibson-Mount 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

RESOLVED!

So this apparently boils down to something wrong with how I created the new account. No idea why I could bind w/ADS but not ldapsearch, but anyway:

When I added an ACL for *my* user account to be able to read everything, and bound using MY account and password (instead of the new account), EVERYTHING works as expected - full access to other user's password hashes, but no ability to make changes.

So I just need to figure out what went wrong there and fix it, and that's all on my end.

Thanks again everyone for your help.

Bill

On Fri, Aug 31, 2018 at 08:23:37AM -0700, Quanah Gibson-Mount wrote:

--On Thursday, August 30, 2018 3:17 PM -0500 Bill Bradford mrbill@mrbill.net wrote:

...

by dn="cn=Manager,dc=domain,dc=com" write

This should also be dn.exact

I'll fix that. but this user (rootDN) has the required privs and already works fine so far for a couple of years now.

...

by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read

Are you sure this is the DN returned by ldapwhoami?

I'm not logging in to a Linux box as this user; I'm using this DN as credentials (in Apache Directory Studio, ldapsearch, etc) and connecting just fine - just not with the ability to read other user's passwords.

Past that, I'd suggest you test with slapacl and potentially ACL level debugging.

See reply I just sent to Jason about slapacl not behaving.

Thanks. I hope to be able to hammer this out today. My end result is to have a user with all the privs of the RootDN, but as "read-only" and without the ability to make any changes - so that we don't have to give out the RootDN and password to apps that want to authenticate against LDAP.

Bill