OpenDJ supports two mechanisms to protect access to the directory, access control instructions and privileges. Access control instructions apply to directory data, providing fine-grained control over what a user or group member is authorized to do in terms of LDAP operations. Most access control instructions specify scopes (targets) to which they apply such that an administrative user who has all access to dc=example,dc=com need not have any access to dc=example,dc=org. Privileges control the administrative tasks that users can perform, such as bypassing the access control mechanism, performing backup and restore operations, making changes to the configuration, and so forth. Privileges are implemented independently from access control. By default, privileges restrict administrative access to directory root users, though any user can be assigned a privilege. Privileges apply to a directory server, and do not have a scope. Some operations require both privileges and also access control instructions. For example, in order to reset user's passwords, an administrator needs both the password-reset privilege and also access control to write userPassword values on the user entries. By combining an access control instruction with a privilege, you can effectively restrict the scope of that privilege to a particular branch of the Directory Information Tree. This chapter covers both access control instructions and privileges, demonstrating how to configure both.

Access control OpenDJ directory server access control instructions (ACIs) exist as operational aci attribute values on directory entries, and as global ACIs stored in the configuration. ACIs apply to a scope defined in the instruction, and set permissions that depend on what operation is requested, who requested the operation, and how the client connected to the server. For example, the ACIs on the following entry allow anonymous read access to all attributes except passwords, and allow read-write access for directory administrators under dc=example,dc=com. dn: dc=example,dc=com objectClass: domain objectClass: top dc: example aci: (target ="ldap:///dc=example,dc=com")(targetattr != "userPassword")(version 3.0;acl "Anonymous read-search access"; allow (read, search, compare)(userdn = "ldap:///anyone");) aci: (target="ldap:///dc=example,dc=com") (targetattr = "*")(version 3.0; acl "allow all Admin group"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";) OpenDJ directory server's default behavior is that no access is allowed unless it is specifically granted by an access control instruction. In addition privileges assigned to certain users such as cn=Directory Manager allow them to bypass access control checks. OpenDJ directory server provides several global ACIs out of the box to facilitate evaluation while maintaining a reasonable security policy. By default users are allow to read the root DSE, to read the schema, to use certain controls and extended operations, to modify their own entries, to bind, and so forth. Global ACIs are defined on the access control handler, and apply to the entire directory server. You must adjust the default global ACIs to match the security policies for your organization, for example to restrict anonymous access. ACI attribute values use a specific language described in this section. Although ACI attribute values can become difficult to read in LDIF, the basic syntax is simple. targets(version 3.0;acl "name";permissions subjects;) The following list briefly explains the variables in the syntax above. targets The targets specifies entries, attributes, controls, and extended operations to which the ACI applies. To include multiple targets, enclose each individual target in parentheses, (). When you specify multiple targets, all targets must match for the ACI to apply (AND). name Supplies a human-readable description of what the ACI does. permissions Defines which actions to allow, and which to deny. Paired with subjects. subjects Identify clients to which the ACI applies depending on who connected, and when, where, and how they connected. Paired with permissions. Separate multiple pairs of permissions subjects definitions with semicolons, ;. When you specify multiple permissions-subjects pairs, at least one must match (OR).

Access control Targets The seven types of ACI targets identify the objects to which the ACI applies. (target = "ldap:///DN") (target != "ldap:///DN") Sets the scope to the entry with distinguished name DN, and to child entries. You can use asterisks, *, to replace attribute types, attribute values, and entire DN components. In other words, the following specification targets both uid=bjensen,ou=People,dc=example,dc=com and also cn=Frank Zappa,ou=Musicians,dc=example,dc=com. (target = "ldap:///*=*,*,dc=example,dc=com") The DN must be in the subtree of the entry on which the ACI is defined. If you do not specify target, then the entry holding this ACI will be affected. If targetscope is also omitted, then this entry and all subordinates will be affected. (targetattr = "attr-list") (targetattr != "attr-list") Replace attr-list with a list of attribute type names, such as userPassword, separating multiple attribute type names with ||. This specification affects the entry where the ACI is located, or the entries specified by other targets in the ACI. You can use an asterisk, *, to specify all non-operational attributes, although you will see better performance when explicitly including or excluding attribute types needed. You can use a plus, +, to specify all operational attributes. If you do not include this target specification, then by default no attributes are affected by the ACI. (targetfilter = "ldap-filter") (targetfilter != "ldap-filter") Sets the scope to match the ldap-filter dynamically, as in an LDAP search. The ldap-filter can be any valid LDAP filter. (targattrfilters = "expression") (targattrfilters != "expression") Use this target specification when managing changes made to particular attributes. Here expression takes one of the following forms. Separate expressions with semicolons, ;. op=attr1:filter1[&& attr2:filter2 …][;op=attr3:filter3[&& attr4:filter4 …] …] Here op can be either add for operations creating attributes, or delete for operations removing them. Replace attr with an attribute type. Replace filter with an LDAP filter that corresponds to the attr attribute type. (targetscope = "base|onelevel|subtree|subordinate") Here base refers to the entry where the ACI is defined, onelevel to immediate children, subtree to the base entry and all children, and subordinate to all children only. If you do not specify targetscope, then the default is subtree. (targetcontrol = "OID") (targetcontrol != "OID") Replace OID with the object identifier for the LDAP control to target. Separate multiple OIDs with ||. This target cannot be restricted to a specific subtree by combining it with another target. (extop = "OID") (extop != "OID") Replace OID with the object identifier for the extended operation to target. Separate multiple OIDs with ||. This target cannot be restricted to a specific subtree by combining it with another target.

Access control Permissions ACI permission definitions take one of the following forms. allow(action[, action …]) deny(action[, action …]) Although deny is supported, avoid restricting permissions by using deny. Instead, explicitly allow access only where needed. What looks harmless and simple in your lab examples can grow difficult to maintain in a real-world deployment with nested ACIs. Replace action with one of the following. add Entry creation, as for an LDAP add operation all All permissions, except export, import, proxy compare Attribute value comparison, as for an LDAP compare operation delete Entry deletion, as for an LDAP delete operation export Entry export during a modify DN operation. Despite the name, this action is unrelated to LDIF export operations. import Entry import during a modify DN operation. Despite the name, this action is unrelated to LDIF import operations. proxy Access the ACI target using the rights of another user read Read entries and attributes search Search the ACI targets. Needs to be combine with read in order to read the search results. selfwrite Add or delete own DN from a group write Modify attributes on ACI target entries

Access control Subjects ACI subjects match characteristics of the client connection to the server. Use subjects to restrict whether the ACI applies depending on who connected, and when, where, and how they connected. authmethod = "none|simple|ssl|sasl mech" authmethod != "none|simple|ssl|sasl mech" Here you use none to mean do not check, simple for simple authentication, ssl for certificate-based authentication over LDAPS, sasl mech for SASL where mech is DIGEST-MD5, EXTERNAL, or GSSAPI. dayofweek = "day[, day …]" dayofweek != "day[, day …]" Replace day with one of sun, mon, tue, wed, thu, fri, sat. dns = "hostname" dns != "hostname" You can use asterisks, *, to replace name components, such as dns = "*.myCompany.com". groupdn = "ldap:///DN[|| ldap:///DN …]" groupdn != "ldap:///DN[|| ldap:///DN …]" Replace DN with the distinguished name of a group to permit or restrict access for members. ip = "addresses" ip != "addresses" Here addresses can be specified for IPv4 or IPv6. IPv6 addresses are specified in brackets as ldap://[address]/subnet-prefix where /subnet-prefix is optional. You can specify individual IPv4 addresses, addresses with asterisks (*) to replace subnets and host numbers, CIDR notation, and forms such as 192.168.0.*+255.255.255.0 to specify subnet masks. ssf = "strength" ssf != "strength" ssf > "strength" ssf >= "strength" ssf < "strength" ssf <= "strength" Here the security strength factor pertains to the cipher key strength for connections using DIGEST-MD5, GSSAPI, SSL, or TLS. For example, to require that the connection must have at least 128 bits of encryption, specify ssf >= 128. timeofday = "hhmm" timeofday != "hhmm" timeofday > "hhmm" timeofday >= "hhmm" timeofday < "hhmm" timeofday <= "hhmm" Here hhmm is expressed as on a 24-hour clock. For example, 1:15 PM is written 1315. userattr = "attr#value" userattr != "attr#value" userattr = ldap-url#LDAPURL" userattr != ldap-url#LDAPURL" userattr = "[parent[child-level]. ]attr#GROUPDN|USERDN" userattr != "[parent[child-level]. ]attr#GROUPDN|USERDN" The userattr subject specifies an attribute that must match on both the bind entry and the target of the ACI. To match when the attribute on the bind DN entry corresponds directly to the attribute on the target entry, replace attr with the attribute type, and value with the attribute value. To match when the target entry is identified by an LDAP URL, and the bind DN is in the subtree of the DN of the LDAP URL, use ldap-url#LDAPURL. To match when the bind DN corresponds to a member of the group identified by the attr value on the target entry, use attr#GROUPDN. To match when the bind DN corresponds to the attr value on the target entry, use attr#USERDN. The optional inheritance specification, parent[child-level]., lets you specify how many levels below the target entry inherit the ACI. Here child-level is a number from 0 to 9, with 0 indicating the target entry only. Separate multiple child-level digits with commas (,). userdn = "ldap-url++[|| ldap-url++ …]" userdn != "ldap-url++[|| ldap-url++ …]" To match the bind DN, replace ldap-url++ with either a valid LDAP URL such as ldap:///uid=bjensen,ou=People,dc=example,dc=com, ldap:///dc=example,dc=com??sub?(uid=bjensen), or a special LDAP URL-like keyword from the following list. ldap:///all Match authenticated users. ldap:///anyone Match anonymous and authenticated users. ldap:///parent Match when the bind DN is a parent of the ACI target. ldap:///self Match when the bind DN entry corresponds to ACI target.

Access control Evaluation Understanding how OpenDJ evaluates the aci values is critical when implementing an access control policy. The rules the server follows are simple. To determine if an operation is allowed or denied, the OpenDJ server looks in the directory for the target of the operation. It collects any aci values from that entry, and then walks up the directory tree to the suffix, collecting all aci values en route. Global aci values are then collected. It then separates the aci values into two lists; one list contains all the aci values that matches the target and denies the required access, and the other list contains all the aci values that matches the target and allows the required access. If the deny list contains any aci values after this procedure, access will be immediately denied. If the deny list is empty, then the allow list is processed. If the allow list contains any aci values, access will be allowed. If both lists are empty, access will be denied. Some operations require multiple permissions and involve multiple targets. Evaluation will therefore take place multiple times. For example a search operation requires the search permission for each attribute in the search filter. If all those are allowed, the read permission is used to decide what attributes and values can be returned.

Access control Operations The minimal access control information required for specific LDAP operations is described here. Add The ACI must allow the add permission to entries in the target. This implicitly allows the attributes and values to be set. Use targetattrfilters to explicitly deny access to any values if required. For example, the ACI required to allow uid=bjensen,ou=People,dc=example,dc=com to add an entry is: aci: (version 3.0;acl "Add entry"; allow (add)(userdn = "ldap:///uid=bjensen,ou=People,dc=example,dc=com");) Bind Because this is used to establish the user's identity and derived authorizations, ACI is irrelevant for this operation and is not checked. To prevent authentication, disable the account instead. For more information see Managing Accounts Manually. Compare The ACI must allow the compare permission to the attribute in the target entry. For example, the ACI required to allow uid=bjensen,ou=People,dc=example,dc=com to compare values against the sn attribute is: aci: (targetattr = "sn")(version 3.0;acl "Compare surname"; allow (compare)(userdn = "ldap:///uid=bjensen,ou=People,dc=example,dc=com");) Delete The ACI must allow the delete permission to the target entry. This implicitly allows the attributes and values in the target to be deleted. Use targetattrfilters to explicitly deny access to the values if required. For example, the ACI required to allow uid=bjensen,ou=People,dc=example,dc=com to delete an entry is: aci: (version 3.0;acl "Delete entry"; allow (delete) (userdn = "ldap:///uid=bjensen,ou=People,dc=example,dc=com");) Modify The ACI must allow the write permission to attributes in the target entries. This implicitly allows all values in the target attribute to be modified. Use targetattrfilters to explicitly deny access to specific values if required. For example, the ACI required to allow uid=bjensen,ou=People,dc=example,dc=com to modify the description attribute in an entry is: aci: (targetattr = "description")(version 3.0; acl "Modify description"; allow (write)(userdn = "ldap:///uid=bjensen,ou=People,dc=example,dc=com");) ModifyDN If the entry is being moved to a newSuperior, the export permission must be allowed on the target, and the import permission must be allowed on the newSuperior entry. The ACI must allow write permission to the attributes in the old RDN and the new RDN. All values of the old RDN and new RDN can be written implicitly; use targetattrfilters to explicitly deny access to values used if required. For example, the ACI required to allow uid=bjensen,ou=People,dc=example,dc=com to rename entries named with the uid attribute to new locations: aci: (targetattr = "uid")(version 3.0;acl "Rename uid= entries"; allow (write, import, export)(userdn = "ldap:///uid=bjensen,ou=People,dc=example,dc=com");) Search ACI is required to process the search filter, and to determine what attributes and values may be returned in the results. The search permission is used to allow particular attributes in the search filter. The read permission is used to allow particular attributes to be returned. If read permission is allowed to any attribute, the server will automatically allow the objectClass attribute to also be read. All values of readable attributes can be implicitly read; to restrict this use targetattrfilters. For example, the ACI required to allow uid=bjensen,ou=People,dc=example,dc=com to search for uid attributes, and also to read that attribute in matching entries is: aci: (targetattr = "uid")(version 3.0;acl "Search and read uid"; allow (search, read)(userdn = "ldap:///uid=bjensen,ou=People,dc=example,dc=com");)

Privileges Privileges provide access control for server administration independently from access control instructions. Directory root users, such as cn=Directory Manager, are granted privileges in the following list and marked with an asterisk (*) by default. Other administrator users can be assigned privileges, too. backend-backup* Request a task to backup data backend-restore* Request a task to restore data from backup bypass-acl* Perform operations without regard to ACIs bypass-lockdown* Perform operations without regard to lockdown mode cancel-request* Cancel any client request config-read* Read the server configuration config-write* Change the server configuration data-sync Perform data synchronization disconnect-client* Close any client connection jmx-notify Subscribe to JMX notifications jmx-read Read JMX attribute values jmx-write Write JMX attribute values ldif-export* Export data to LDIF ldif-import* Import data from LDIF modify-acl* Change ACIs password-reset* Reset other users' passwords privilege-change* Change the privileges assigned to users proxied-auth Use the Proxied Authorization control server-lockdown* Put OpenDJ into, and take OpenDJ out of, lockdown mode server-restart* Request a task to restart the server server-shutdown* Request a task to stop the server subentry-write* Perform LDAP subentry write operations unindexed-search* Search using a filter with no correponding index update-schema* Change OpenDJ schema definitions * = default directory root user privileges

For root directory administrators, by default cn=Directory Manager, you configure privileges using the dsconfig command. For non-root directory administrators, you add privileges with the ldapmodify command. Start dsconfig in interactive mode. $ dsconfig --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password Select the Root DN menu. Select View and edit the Root DN. Edit the default-root-privilege-name. Make sure you apply the changes when finished. Privileges are specified using the ds-privilege-name operational attribute, which you can change on the command-line using ldapmodify. Determine the privileges to add. $ cat privilege.ldif dn: uid=kvaughan,ou=People,dc=example,dc=com changetype: modify add: ds-privilege-name ds-privilege-name: config-read ds-privilege-name: password-reset This example lets the user read the server configuration, and reset user passwords. In order for the user to be able to change a user password, you must also allow the modification using ACIs. For this example, Kirsten Vaughan is a member of the Directory Administrators group for Example.com, and already has access to modify user entries. Prior to having the privileges, Kirsten gets messages about insufficent access when trying to read the server configuration, or reset a user password. $ ldapsearch --port 1389 --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" --bindPassword bribery --baseDN cn=config "(objectclass=*)" SEARCH operation failed Result Code: 50 (Insufficient Access Rights) Additional Information: You do not have sufficient privileges to perform search operations in the Directory Server configuration $ ldappasswordmodify --port 1389 --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" --bindPassword bribery --authzID "dn:uid=scarter,ou=People,dc=example,dc=com" --newPassword changeit The LDAP password modify operation failed with result code 50 Error Message: You do not have sufficient privileges to perform password reset operations Apply the change as a user with the privilege-change privilege. $ ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --filename privilege.ldif Processing MODIFY request for uid=kvaughan,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=kvaughan,ou=People,dc=example,dc=com At this point, Kirsten can perform the operations requiring privileges. $ ldapsearch --port 1389 --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" --bindPassword bribery --baseDN cn=config "(objectclass=*)" dn: cn=config ds-cfg-return-bind-error-messages: false ds-cfg-default-password-policy: cn=Default Password Policy,cn=Password Policies, cn=config … $ ldappasswordmodify --port 1389 --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" --bindPassword bribery --authzID "dn:uid=scarter,ou=People,dc=example,dc=com" --newPassword changeit The LDAP password modify operation was successful For deployments with more than one administrator, you no doubt use a group to define adminstrative rights. You can use a collective attribute subentry to specify privileges for the administrator group. Collective attributes provide a standard mechanism for defining attributes that appear on all the entries in a particular subtree. OpenDJ extends collective attributes to give you fine-grained control over the which entries in the subtree are targetted. Also, OpenDJ lets you use virtual attributes, such as isMemberOf to construct the filter for targetting entries to which the collective attributes apply. This allows you, for example, to define administrative privileges that apply to all users who belong to an administrator group. Create an LDAP subentry that specifies the collective attributes. $ cat collective.ldif dn: cn=Administrator Privileges,dc=example,dc=com objectClass: collectiveAttributeSubentry objectClass: extensibleObject objectClass: subentry objectClass: top cn: Administrator Privileges ds-privilege-name;collective: config-read ds-privilege-name;collective: config-write ds-privilege-name;collective: ldif-export ds-privilege-name;collective: modify-acl ds-privilege-name;collective: password-reset ds-privilege-name;collective: proxied-auth subtreeSpecification: {base "ou=people", specificationFilter "(isMemberOf=cn=Directory Administrators,ou=Groups,dc=example,dc=com)" } $ ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --defaultAdd --filename collective.ldif Processing ADD request for cn=Administrator Privileges,dc=example,dc=com ADD operation successful for DN cn=Administrator Privileges,dc=example,dc=com The Directory Administrators group for Example.com includes members like Kirsten Vaughan. Observe that the change takes effect immediately. $ ldappasswordmodify --port 1389 --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" --bindPassword bribery --authzID "dn:uid=scarter,ou=People,dc=example,dc=com" --newPassword changeit The LDAP password modify operation was successful

Access control Examples Access control instructions are defined in the data, as values for aci attributes. They can be imported in LDIF. They can be modified over LDAP. Yet in order to make changes to ACIs users first need the modify-acl privilege described previously. By default, only the root DN user has the modify-acl privilege. Global ACIs on cn=Access Control Handler,cn=config can be set using the dsconfig command. Global ACIs have attribute type ds-cfg-global-aci. Modify global ACIs from the Access Control Handler menu in dsconfig. Replication Data access Default global ACIs set up the following access rules. Users can employ LDAP controls and perform extended operations. Anonymous read access is allowed for most user data attributes. Users can read password values on their own entries after binding. (Also by default, password values are hashed.) Anonymous read access is allowed for schema-related operational attributes. Anonymous read access is allowed for root DSE attributes describing what the server supports. Anonymous read access is allowed for operational attributes related to entry updates and entry identification. Access to replication data is denied. Users with write access to add ACIs and with the modify-acl privilege can use the ldapmodify command to change ACIs located in user data. This section therefore focuses on ACI examples, rather than demonstrating how to update the directory for each example. To update ACIs, either change them using the ldapmodify command, or using OpenDJ Control Panel. If you use OpenDJ Control Panel, find the entry to modify in the Manage Entries window. Then try View > LDIF View to edit the entry. Control Panel checks your syntax and lets you know if you made an error before it saves any changes. For hints on updating directory entries with ldapmodify, see the section on Modifying Entry Attributes, keeping in mind that the name of the ACI attribute is aci as shown in the examples that follow. This works when the only attributes you do not want world-readable are password attributes. aci: (target ="ldap:///dc=example,dc=com")(targetattr != "authPassword || userPassword")(version 3.0;acl "Anonymous read-search access"; allow (read, search, compare)(userdn = "ldap:///anyone");) Access control Disabling anonymous access By default OpenDJ denies access unless an access control explicitly allows access.This does not apply to the directory root user, such as cn=Directory Manager, who bypasses ACIs. However, OpenDJ also allows anonymous access by default to use some controls, to perform certain extended operations, to view root DSE operational attributes, to view directory schema definitions, to view some other operational attibutes, and to perform compare and search operations. These default capabilities are defined on the global-aci property of the access control handler, which you can read by using the dsconfig get-access-control-handler-prop command. $ dsconfig get-access-control-handler-prop --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --property global-aci To disable anonymous read access for example, use the dsconfig set-access-control-handler-prop command. First, remove the global-aci attribute value that allows anonymous read access. Do not wrap the lines in the following example if you use it as the basis for your script. $ dsconfig \ set-access-control-handler-prop \ --remove global-aci:\(targetattr!=\"userPassword\|\|authPassword\|\|changes\|\ \|changeNumber\|\|changeType\|\|changeTime\|\|targetDN\|\|newRDN\|\ \|newSuperior\|\|deleteOldRDN\|\|targetEntryUUID\|\|changeInitiatorsName\|\ \|changeLogCookie\|\|includedAttributes\"\)\(version\ 3.0\;\ acl\ \"Anonymous\ \ read\ access\"\;\ allow\ \(read,search,compare\)\ \ userdn=\"ldap:///anyone\"\;\)\ --hostname opendj.example.com \ --port 4444 \ --bindDN cn=Directory\ Manager \ --bindPassword password \ --trustAll \ --no-prompt If the global-aci does not match the ACI exactly then the command fails to remove the value. An alternative approach is to use the dsconfig command interactively, adding the --commandFilePath option. You can then use the command you capture to remove the property value on other servers for example. To use the dsconfig command this way, start the command as follows. $ dsconfig --port 4444 --hostname opendj.example.com --bindDN "cn=Directory Manager" --bindPassword password --commandFilePath /tmp/captured-command.sh Next, add a global ACI value that allows authenticated users to perform read operations. You can use dsconfig interactively to add the ACI value as shown below (targetattr!= … userdn="ldap:///all";). global-aci: (targetattr!="userPassword|| authPassword||changes||changeNumber||changeType||changeTime||targetDN||newRDN|| newSuperior||deleteOldRDN||targetEntryUUID||changeInitiatorsName|| changeLogCookie||includedAttributes")(version 3.0; acl "Authenticated users read access"; allow (read,search,compare) userdn="ldap:///all";) Notice that these changes are made to the OpenDJ directory server configuration, and so are not replicated to other servers. You must instead apply the changes separately to each server. Directory Administrators need privileges as well for full access to administrative operations. aci: (target="ldap:///dc=example,dc=com") (targetattr = "* || +")(version 3.0;acl "Admins can run amok"; allow( all, proxy, import, export) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";) Notice both targetattr = "* || +", which permits access to both all user attributes and all operational attributes, and allow(all, proxy, import, export), which permits not only all user operations, but also proxy authorization as well as data import and export operations. By default this capability is set in a global ACI. aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr = "authPassword || userPassword")(version 3.0;acl "Allow users to change pass words"; allow (write)(userdn = "ldap:///self");) For some static groups such as carpoolers and social club members, you might choose to let users manage their own memberships. aci: (target ="ldap:///ou=Self Service,ou=Groups,dc=example,dc=com")( targetattr = "member")(version 3.0;acl "Self registration"; allow(selfwrite)( userdn = "ldap:///uid=*,ou=People,dc=example,dc=com");) Let users create and delete self-managed groups. aci: (target ="ldap:///ou=Self Service,ou=Groups,dc=example,dc=com")( targattrfilters="add=objectClass:(objectClass=groupOfNames)")(version 3.0; acl "All can create self service groups"; allow (add)(userdn= " ldap:///uid=*,ou=People,dc=example,dc=com");) aci: (target ="ldap:///ou=Self Service,ou=Groups,dc=example,dc=com")(version 3 .0; acl "Owner can delete self service groups"; allow (delete)(userattr= " owner#USERDN");) This ACI uses IP address and Security Strength Factor subjects. aci: (target = "ldap:///dc=example,dc=com")(targetattr = "*")(version 3.0;acl "Use loopback only for LDAP in the clear"; deny (all)( ip != "127.0.0.1" and ssf <= "1");) The ssf is one for example when using SSL but you have not configured a cipher, so the packets are checksummed for integrity checking by all content is nevertheless sent in clear text.

Access control Debugging Access control Effective rights Once you set up a number of ACIs, you might find it difficult to understand by inspection what rights a user actually has to a given entry. The Get Effective Rights control can help. The control OID, 1.3.6.1.4.1.42.2.27.9.5.2, is not allowed by the default global ACIs. In this example, Babs Jensen is the owner of a small group of people who are willing to carpool. $ ldapsearch --port 1389 --bindDN "uid=bjensen,ou=people,dc=example,dc=com" --bindPassword hifalutin --baseDN "ou=Self Service,ou=Groups,dc=example,dc=com" "cn=*" dn: cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com objectClass: groupOfNames objectClass: top member: uid=bjensen,ou=People,dc=example,dc=com description: People who are willing to carpool owner: uid=bjensen,ou=People,dc=example,dc=com cn: Carpoolers Performing the same search with the get effective rights control, and asking for the aclRights attribute, shows what rights Babs has on the entry. $ ldapsearch --control effectiverights --port 1389 --bindDN "uid=bjensen,ou=people,dc=example,dc=com" --bindPassword hifalutin --baseDN "ou=Self Service,ou=Groups,dc=example,dc=com" "cn=*" aclRights dn: cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:1,read:1,write:0,proxy:0 Requesting the aclRightsInfo attribute results in information about the ACIs applied to arrive at the results. $ ldapsearch --control effectiverights --port 1389 --bindDN "uid=bjensen,ou=people,dc=example,dc=com" --bindPassword hifalutin --baseDN "ou=Self Service,ou=Groups,dc=example,dc=com" "cn=*" aclRights aclRightsInfo dn: cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com aclRightsInfo;logs;entryLevel;read: acl_summary(main): access allowed(read) on e ntry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, objectClas s) to (uid=bjensen,ou=People,dc=example,dc=com) (not proxied) ( reason: evaluat ed allow , deciding_aci: Anonymous read-search access) aclRightsInfo;logs;entryLevel;write: acl_summary(main): access not allowed(write ) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NULL ) to (uid=bjensen,ou=People,dc=example,dc=com) (not proxied) ( reason: no acis matched the subject ) aclRightsInfo;logs;entryLevel;add: acl_summary(main): access not allowed(add) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NULL) to (uid=bjensen,ou=People,dc=example,dc=com) (not proxied) ( reason: no acis matc hed the subject ) aclRightsInfo;logs;entryLevel;delete: acl_summary(main): access allowed(delete) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NULL) to (uid=bjensen,ou=People,dc=example,dc=com) (not proxied) ( reason: evaluated allow , deciding_aci: Owner can delete self service groups) aclRights;entryLevel: add:0,delete:1,read:1,write:0,proxy:0 aclRightsInfo;logs;entryLevel;proxy: acl_summary(main): access not allowed(proxy ) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NULL ) to (uid=bjensen,ou=People,dc=example,dc=com) (not proxied) ( reason: no acis matched the subject ) You can also request the effective rights for another user by using the --getEffectiveRightsAuthzid (short form: -g) option, which takes the authorization identity of the other user as an argument. The following example shows Directory Manager checking anonymous user rights to the same entry. Notice that the authorization identity for an anonymous user is expressed as "dn:". $ ldapsearch --getEffectiveRightsAuthzid "dn:" --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN "ou=Self Service,ou=groups,dc=example,dc=com" "cn=*" aclRightsInfo dn: cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com aclRightsInfo;logs;entryLevel;read: acl_summary(main): access allowed(read) on e ntry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, objectClas s) to (anonymous) (not proxied) ( reason: evaluated allow , deciding_aci: Anony mous read-search access) aclRightsInfo;logs;entryLevel;write: acl_summary(main): access not allowed(write ) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NULL ) to (anonymous) (not proxied) ( reason: no acis matched the subject ) aclRightsInfo;logs;entryLevel;add: acl_summary(main): access not allowed(add) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NULL) to (anonymous) (not proxied) ( reason: no acis matched the subject ) aclRightsInfo;logs;entryLevel;delete: acl_summary(main): access not allowed(dele te) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NU LL) to (anonymous) (not proxied) ( reason: no acis matched the subject ) aclRightsInfo;logs;entryLevel;proxy: acl_summary(main): access not allowed(proxy ) on entry/attr(cn=Carpoolers,ou=Self Service,ou=Groups,dc=example,dc=com, NULL ) to (anonymous) (not proxied) ( reason: no acis matched the subject ) When you need to check access to an attribute that might not yet exist on the entry, you can further use the --getEffectiveRightsAttribute (short form: -e) option, which takes an attribute list as an argument. The following example shows Directory Manager checking anonymous user access to the description attribute for the Self Service groups organizational unit entry. The description attribute is not present on the entry, yet. $ ldapsearch --port 1389 --baseDN "ou=Self Service,ou=groups,dc=example,dc=com" "ou=Self Service" description dn: ou=Self Service,ou=Groups,dc=example,dc=com $ ldapsearch --getEffectiveRightsAuthzid "dn:" --getEffectiveRightsAttribute description --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN "ou=Self Service,ou=groups,dc=example,dc=com" "ou=Self Service" aclRights dn: ou=Self Service,ou=Groups,dc=example,dc=com aclRights;attributeLevel;description: search:1,read:1,compare:1,write:0,selfwrit e_add:0,selfwrite_delete:0,proxy:0 aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0