On 11/29/2018 12:32 AM, Alistair Cunningham wrote:
Thank you, it's now working correctly! We don't need anonymous access.

Is there a neat way to replace the ACL below that needs to be added once for each ou with one single ACL that works for every ou? Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the target part must match the same string in the userdn part?

aci: (target="ldap:///ou=2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,ou=2,dc=example,dc=com";)
you should look into Macro ACIs, cahp 18.16
soemthing like:
aci: (target="ldap:///($dn),dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,($dn),dc=example,dc=com";

or maybe [$dn] in the userdn to be able to target subentries.

Now it is  question if you should use this. If your tree is very dynamic and you add or remove subtrees and don't want to change the acis each time macro acis are the right approach, but if you have a few subtrees which are stable, macroacis can be a bit of overhead in evaluating and adding indiuvidual acis is only a bit tedious in the beginning


On 29/11/2018 03:54, Mark Reynolds wrote:

On 11/27/18 8:15 PM, Alistair Cunningham wrote:
On 28/11/2018 12:08, Mark Reynolds wrote:
On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') in tenant1 can still see people (with objectClass 'inetOrgPerson') in tenant2. Presumably there needs to also be a blanket aci to forbid all telephones from viewing other tenants, that these tenant-specific allow acis then override?

There might be an aci that is allowing anonymous access to basic entries.  By default if there are no ACI's then access is completely blocked except for Directory Manager.  So some aci is allowing access. We need to see all the ACI's you have:

For example, this would list all the aci's under dc=example,dc=com:

# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" aci=* aci

I suspect there is an aci with a userdn that equals "anyone", but we'll see...

There is indeed. Shall I delete it?
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac
  cess"; allow (read, search, compare) userdn="ldap:///anyone";)

That depends.  Do you have any clients that expect to have anonymous access to entries?  Removing this aci will block everyone from access to the database - then you need to add aci's to open up access to the users/groups of your choosing.

So to accomplish what you want in this email then yes delete it, but it could break clients that be expecting anonymous access to be allowed. So be careful :-)


$ ldapsearch -x -D "cn=Directory Manager" -w secret -b "dc=integrics,dc=com" "aci=*" aci
# extended LDIF
#
# LDAPv3
# base <dc=integrics,dc=com> with scope subtree
# filter: aci=*
# requesting: aci
#

# integrics.com
dn: dc=integrics,dc=com
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac
 cess"; allow (read, search, compare) userdn="ldap:///anyone";)
aci: (targetattr="carLicense || description || displayName || facsimileTelepho
 neNumber || homePhone || homePostalAddress || initials || jpegPhoto || labele
 dURI || mail || mobile || pager || photo || postOfficeBox || postalAddress ||
  postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddr
 ess || roomNumber || secretary || seeAlso || st || street || telephoneNumber
 || telexNumber || title || userCertificate || userPassword || userSMIMECertif
 icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for commo
 n attributes"; allow (write) userdn="ldap:///self";)
aci: (targetattr ="*")(version 3.0;acl "Directory Administrators Group";allow
 (all) (groupdn = "ldap:///cn=Directory Administrators, dc=integrics,dc=com");
 )

# 2, integrics.com
dn: ou=2,dc=integrics,dc=com
aci: (target="ldap:///ou=2,dc=integrics,dc=com")(targetattr=*)(version 3.0;acl
  "aci2";allow (read,search) userdn="ldap:///uid=*,ou=2,dc=integrics,dc=com";)

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org


-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, 
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander