First, like with most things in LDAP ACLs are configured using the /etc/openldap/slapd.conf file. Below is the pertinent portion of this file that we will be looking at:

# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

Now, if we remove the commented out portions of the file or add more lines we can start to limit who has access to read and/or change what information in the LDAP database. Keep in mind that you always want to back up your slapd.conf file prior to doing so.

You can control access to each element in the database. Each ACL has an “access to” which is the elements in the LDAP database that you are granting or denying access for and then a “by” portion that lists who can do what to that portion of the database. An entire ACL can be listed on one line, as is done with policies that have only one user or group associated to them. For example, the following line gives anyone and everyone read access to the database:
access to dn.base=”” by * read

For ease of use and reviewing, we typically put the “access to” on one line and the subsequent users or groups with access in their own “by” lines for more complicated ACL rule sets. Slapd parses the file in such a way that it realizes that “access to” means the beginning of a new ACL. The following is an example of some more complicated ACLs:

access to attrs=userPassword
by dn="cn=users,dc=318,dc=com" write
by self write
by * compare

access to *
by dn=”cn=computers,dc=318,dc=com” write
by users read
by * auth

Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. In the above example, a user is able to write to their own userPassword record. This means that the user is also able to auth, compare, search and read that record.

ACLs are prosessed from top to bottom. This makes it important to put specific ACLs and by statements above more general ones. ACLs that restrict access to the userPassword attribute, followed by one applicable to *, that is, the entire LDAP database. In the above example, placing the userPassword ACL first causes the rule that allows users to change their own passwords to process before the wildcard that specifies everyone. When a * is used as a wildcard in the access to line of slapd.conf it means the entire database or tree of the LDAP database. When the * is used in the by line it typically denotes all users.

Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. These two points, the first match wins rule and the inclusive nature of access levels, are crucial to understanding how ACLs are parsed. They also are important for making sure your ACLs don’t lead to either greater or lesser levels of access than you intend in a given situation.

It can be time consuming to go through every possible attribute by group and determine who has access to what. However, if you want to have users updating their own addresses, phone numbers, and other information, as can be done with the Directory application, this is often one way to accomplish this goal. You could also provide help desk users the ability to update the database using the Directory application but not allow them to access other records in the LDAP database, such as group memberships. Having a very granular ACL environment for records can also allow you to obtain a maximum level of security.

This can also be put into the schema in order to force replication between hosts. Keep an eye out for that article at a later date.

For what it’s worth, at 318 we’ve found that commenting out each ACL helps us to keep track of who did what, why and what they were thinking when they did it. Happy OD everyone!!!

I’m making a couple assumptions here, so before we start, here they are: You already have ARD 2 installed and set up to administer your client machines with a local account. You have LDAP set up, and your client machines are already bound into the domain.

The theory behind this is creating groups in Workgroup Manager, and then adding users who you want to be authorized to use ARD into those groups. There are 4 groups, ard_admin, ard_interact, ard_manage and ard_reports.

ard_admin will have access to all functions of ARD, ard_interact is simply interaction (like you’d get with VNC alone) with the client, ard_manage allows for more advanced features, and ard_reports can only generate reports from the ARD clients. For a clearer idea, check out the Interact, Manage and Reports items in the menubar of ARD.

Create your groups in Workgroup Manager – you don’t need to add all 4, you can pick and choose which you would like, and they can be created with any GID, it’s only the name which must be exact. Then add your ARD administrative users to their appropriate groups.

To set up the clients, you can either create your own Client Installer, or you can change your existing client settings (under the Manage menu bar item). Using the “Change Client Settings” as an example, click through the screens until you get to the “Incoming Access” screen. From here click the “Set authorized groups to:” checkbox. Keep continuing through once you’ve done this, and eventually you’ll be able to set your selecting machines with these settings.

Do check out some of the other options you can apply to your client machines using this tool, it allows you to set up, or remove local admin users, and set up other tools like openWBEM.

Once you’ve pushed out these setting to your clients, set up the computers you wish to manage in ARD, and put yourself into one of the ard_* groups, you can use your own username and password to add the clients to your computer lists. This will also make your administrative life much easier if you want different ARD users to have different abilities.