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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to
389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
--
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
|
