Access rights

Edit online

Access rights apply to an entire object or to attributes of the object.

The LDAP access rights are discreet. One right does not imply another right. The rights can be combined together to provide the wanted rights list by following a set of rules. Rights can be of an unspecified value, which indicates that no access rights are granted to the subject on the target object. The rights consist of three parts:
Action
Defined values are grant or deny. If this field is not present, the default is set to grant.
Permission
There are six basic operations that can be performed on a directory object. From these operations, the base that is set of ACI permissions is taken.
  • Add an entry
  • Delete an entry
  • Read an attribute value
  • Write an attribute value
  • Search for an attribute
  • Compare an attribute value
The following permissions are the possible attribute permissions:
  • Read r
  • Write w
  • Search s
  • Compare c
Additionally, object permissions apply to the entry as a whole. These permissions are:
  • add child entries a
  • delete this entry d
The following table summarizes the permissions that are needed to perform each of the LDAP operations.
Operation Permission Needed
idsldapadd add (on parent)
idsldapdelete delete (on object)
idsldapmodify write (on attributes that are modified)
idsldapsearch
  • read (on attributes in RDN®)
  • search (on attributes that are specified in the search filter)
  • read (on attributes that are returned with just names)**
  • read (on attributes that are returned with values)

    ** search (on attributes that are returned with just names) when pre ISVD 10.0.1 behaviour is configured.
idsldapmodrdn write (on RDN attributes)
Note: ** With IBM® Verify Directory 10.0.1 and later levels, ACL evaluation for search operation is changed to be according to the RFC(https://docs.ldap.com/specs/draft-ietf-ldapext-acl-model-08.txt). Environment variable IBMSLAPD_ENABLE_ACLSEARCH_OLD_BEHAVIOUR is introduced to switch between pre IVD 10.0.1 and current ACL evaluation search behaviour. If environment variable's value is not set or set to FALSE, then new ACL evaluation is performed for search operation. If set to TRUE then the pre IVD 10.0.1 evaluation is done. By default, this is set to FALSE. For example, Add following line under cn=Front End, cn=Configuration of the ibmslapd.conf to enable pre IVD 10.0.1 behaviour.

ibm-slapdSetenv: IBMSLAPD_ENABLE_ACLSEARCH_OLD_BEHAVIOUR=TRUE
The following table summarizes the permissions that are needed to perform the LDAP search operations when IBMSLAPD_ENABLE_ACLSEARCH_OLD_BEHAVIOUR is set to TRUE.
Operation Permission Needed
idsldapsearch
  • search, read (on attributes in RDN)
  • search (on attributes that are specified in the search filter)
  • search (on attributes that are returned with just names)**
  • search, read (on attributes that are returned with values)
For search operations, the subject is required to have search s access to all the attributes in the search filter or no entries are returned. For returned entries from a search, the subject is required to have search s and read r access to all the attributes in the RDN of the returned entries or these entries are not returned.

In the following example, the at.telephoneNumber:r permission set grants members of the cn=Bowling Team, ou=Groups, o=sample read-only access to only the telephoneNumber attribute that is contained in this entry. The at.cn:rsc permission set ensures that the RDN® search criteria is met. For this example only the cn attribute can be used in a search filter. If, for instance, also the title attribute is to be used in a search filter, then an extra at.title:rsc permission needs to be added for the search to be successful.

dn: cn=Bonnie Daniel, ou=Widget Division, ou=Austin, o=sample
objectclass: person
objectclass: organizationalPerson
cn: Bonnie Daniel
sn: Daniel
telephonenumber: 1-812-855-7453
internationaliSDNNumber: 755-7453
title: RISC Manufacturing
seealso: cn=Mary Burnnet, ou=Widget Division, ou=Austin, o=sample
postalcode: 1515
aclentry: group: cn=Bowling Team, ou=Groups, o=sample: at.cn:rsc: 
at.telephoneNumber:r
Access Target:
These permissions can be applied to the entire object (add child entry, delete entry), to an individual attribute within the entry, or can be applied to groups of attributes or Attribute Access Classes.

Attributes requiring similar permissions for access are grouped in classes. Attributes are mapped to their attribute classes in the directory schema file. These classes are discrete; access to one class does not imply access to another class. Permissions are set about the attribute access class as a whole. The permissions that are set on a particular attribute class apply to all attributes within that access class unless individual attribute access permissions are specified.

IBM defines five attribute classes that are used in evaluation of access to user attributes: normal, sensitive, critical, system, and restricted. As examples, the attribute commonName belongs to the normal class, and the attribute userPassword belongs to the critical class. User-defined attributes belong to the normal access class unless otherwise specified.

The following system classes are attributes that apply to access control:
  • aclSource
  • ibm-effectiveAcl
  • ownerSource
These attributes are maintained by the LDAP server and are read-only to the directory users and administrators. OwnerSource and aclSource are described in the Propagation section.
The following restricted classes are attributes that define access control:
  • aclEntry
  • aclPropagate
  • entryOwner
  • ibm-filterAclEntry
  • ibm-filterAclInherit
  • ownerPropagate
By default all users have read-access to the restricted attributes but only entryOwners can create, modify, and delete these attributes.