[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem with ACLs



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

--
Bill Bradford
Houston, Texas USA