Hi
I was wonder were do I place acl for cn=Subschema as there doesn;t seems to be a db defined for it or is it the same as cn=schmea ?
thanks
Alex
On 01/20/2010 07:17 AM, Alex Samad wrote:
Hi
I was wonder were do I place acl for cn=Subschema as there doesn;t seems to be a db defined for it or is it the same as cn=schmea ?
Regardless of which database it is attached to, you can define any ACLs in the global section of the configuration file (before any database declarations).
Hope this helps, Jonathan
On Thu, Jan 21, 2010 at 12:03:32PM +0100, Jonathan Clarke wrote:
On 01/20/2010 07:17 AM, Alex Samad wrote:
Hi
I was wonder were do I place acl for cn=Subschema as there doesn;t seems to be a db defined for it or is it the same as cn=schmea ?
Regardless of which database it is attached to, you can define any ACLs in the global section of the configuration file (before any database declarations).
I am using cn=config/dynamic config so I am not using any slapd.conf.
from my reading of slapd-config I gather this is not the same,
cause I can put it in olcDatabase=frontend,cn=config which is like a default and the man page seems to suggest that you put acl's with the db's they are mean to control (although now that I re read it, it seems like the acl's are all meant to be in the frontend db).
Hope this helps, Jonathan
--On Friday, January 22, 2010 8:28 AM +1100 Alex Samad alex@samad.com.au wrote:
On Thu, Jan 21, 2010 at 12:03:32PM +0100, Jonathan Clarke wrote:
On 01/20/2010 07:17 AM, Alex Samad wrote:
Hi
I was wonder were do I place acl for cn=Subschema as there doesn;t seems to be a db defined for it or is it the same as cn=schmea ?
Regardless of which database it is attached to, you can define any ACLs in the global section of the configuration file (before any database declarations).
I am using cn=config/dynamic config so I am not using any slapd.conf.
from my reading of slapd-config I gather this is not the same,
cause I can put it in olcDatabase=frontend,cn=config which is like a default and the man page seems to suggest that you put acl's with the db's they are mean to control (although now that I re read it, it seems like the acl's are all meant to be in the frontend db).
There are still global level ACLs that don't apply to a database. Like cn=subschema.
For example in my DB:
[root@freelancer cn=config]# grep olcA olcDatabase={-1}frontend.ldif olcAccess: {0}to * by dn.children="cn=admins,cn=zimbra" write by * +0 break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Friday, January 22, 2010 8:28 AM +1100 Alex Samad alex@samad.com.au wrote:
On Thu, Jan 21, 2010 at 12:03:32PM +0100, Jonathan Clarke wrote:
On 01/20/2010 07:17 AM, Alex Samad wrote:
Hi
I was wonder were do I place acl for cn=Subschema as there doesn;t seems to be a db defined for it or is it the same as cn=schmea ?
Regardless of which database it is attached to, you can define any ACLs in the global section of the configuration file (before any database declarations).
I am using cn=config/dynamic config so I am not using any slapd.conf.
from my reading of slapd-config I gather this is not the same,
cause I can put it in olcDatabase=frontend,cn=config which is like a default and the man page seems to suggest that you put acl's with the db's they are mean to control (although now that I re read it, it seems like the acl's are all meant to be in the frontend db).
There are still global level ACLs that don't apply to a database. Like cn=subschema.
For example in my DB:
[root@freelancer cn=config]# grep olcA olcDatabase={-1}frontend.ldif olcAccess: {0}to * by dn.children="cn=admins,cn=zimbra" write by * +0 break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read
Just to clarify - what used to be considered "global" for a lot of these settings is now owned by the frontendDB, ever since OpenLDAP 2.3.
Now (since 2.3) "global" settings are only those which affect the entire slapd environment - such as loglevel, number of threads, etc.
ACLs, and other settings which affect particular database operations, are all associated to a specific DB. "Global ACLs" are those which are configured on the frontendDB.
On Fri, Jan 22, 2010 at 08:28:52AM +1100, Alex Samad wrote:
On Thu, Jan 21, 2010 at 12:03:32PM +0100, Jonathan Clarke wrote:
On 01/20/2010 07:17 AM, Alex Samad wrote:
Hi
I was wonder were do I place acl for cn=Subschema as there doesn;t seems to be a db defined for it or is it the same as cn=schmea ?
Regardless of which database it is attached to, you can define any ACLs in the global section of the configuration file (before any database declarations).
I am using cn=config/dynamic config so I am not using any slapd.conf.
from my reading of slapd-config I gather this is not the same,
cause I can put it in olcDatabase=frontend,cn=config which is like a default and the man page seems to suggest that you put acl's with the db's they are mean to control (although now that I re read it, it seems like the acl's are all meant to be in the frontend db).
More investigation from
http://www.openldap.org/doc/admin24/access-control.html#Access%20Control%20v...
When evaluating whether some requester should be given access to an entry and/or attribute, slapd compares the entry and/or attribute to the <what> selectors given in the configuration. For each entry, access controls provided in the database which holds the entry (or the global access directives if not held in any database) apply first, followed by the global access directives (which are held in the frontend database definition). However, when dealing with an access list, because the global access list is effectively appended to each per-database list, if the resulting list is non-empty then the access list will end with an implicit access to * by * none directive. If there are no access directives applicable to a backend, then a default read is used.
so to me it read
database acl first frontend acl's
so is it best practice to put everything in the frontend ?
I have been thing about setting up a 2 node multi master & 3 nodes of just consumer nodes. These consumer nodes might consume from other areas as well.
My Issue has been how to replicate the acl's with out replicating a lot cn=config. My thought was to place all the db acl's in the olcDatabase={2}hdb,cn=config record and then allow repication of this with the same dn that is allowed to replicate the actual db.
from there I got to thinking about cn=schema and where was the best place to place the acls. Taking into consideration that I might want to have different schema's loaded on difference consumers (not the multi masters).....
alex
Hope this helps, Jonathan
Alex Samad wrote:
On Fri, Jan 22, 2010 at 08:28:52AM +1100, Alex Samad wrote:
On Thu, Jan 21, 2010 at 12:03:32PM +0100, Jonathan Clarke wrote:
On 01/20/2010 07:17 AM, Alex Samad wrote:
Hi
I was wonder were do I place acl for cn=Subschema as there doesn;t seems to be a db defined for it or is it the same as cn=schmea ?
Regardless of which database it is attached to, you can define any ACLs in the global section of the configuration file (before any database declarations).
I am using cn=config/dynamic config so I am not using any slapd.conf.
from my reading of slapd-config I gather this is not the same,
cause I can put it in olcDatabase=frontend,cn=config which is like a default and the man page seems to suggest that you put acl's with the db's they are mean to control (although now that I re read it, it seems like the acl's are all meant to be in the frontend db).
More investigation from
http://www.openldap.org/doc/admin24/access-control.html#Access%20Control%20v...
When evaluating whether some requester should be given access to an entry and/or attribute, slapd compares the entry and/or attribute to the <what> selectors given in the configuration. For each entry, access controls provided in the database which holds the entry (or the global access directives if not held in any database) apply first, followed by the global access directives (which are held in the frontend database definition). However, when dealing with an access list, because the global access list is effectively appended to each per-database list, if the resulting list is non-empty then the access list will end with an implicit access to * by * none directive. If there are no access directives applicable to a backend, then a default read is used.
so to me it read
database acl first frontend acl's
so is it best practice to put everything in the frontend ?
Only if your entire ACL config is meant to apply uniformly to all the databases in the server. Usually that won't be the case; people tend to create multiple databases because different parts of their DIT need different settings.
openldap-technical@openldap.org
-
Alex Samad -
Howard Chu -
Jonathan Clarke -
Quanah Gibson-Mount