Access determination

The same bound user might be granted different access permissions to an entry if:
  • the user is an LDAP root administrator and the server is, or is not, in maintenance mode
  • the user is the masterserverDN or peerserverDN
  • the user is the entry owner
  • the user has specific access permissions set for:
    • the bind DN,
    • alternate DNs,
    • pseudo DNs,
    • groups the bind or alternate DNs are members of
  • the user has matching ACL filters

See Querying effective permissions for using the GetEffectiveACL extended operation in the ldapexop utility.

The z/OS® LDAP server uses the following algorithm to determine the permissions to grant a bound user:
Note: When you see "additional access information", it refers to:
  • the IP address of the client connection
  • the bind mechanism used to bind to the LDAP server
  • if encryption was used to bind to the LDAP server
  • the time of day that the directory entry was accessed
  • the day of week that the directory entry was accessed
An LDAP root administrator, masterServerDN, peerServerDN, and entryOwner matches are first evaluated:
  1. if the bind DN is an LDAP root administrator and the server is in maintenance mode, then
    • full access is given
    • then, the algorithm ends and the server continues to process the request
  2. if the bind DN is the masterServerDN or peerServerDN, then
    • full access is given
    • then, the algorithm ends and the server continues to process the request
  3. if the bind DN is an LDAP administrator with the appropriate authority (see Administrative group and roles for more information about administrative role authority), then
    • full access is first applied
    • then, permissions for all aclFilter values matching the LDAP administrator's bind DN and additional access information are applied
    • finally, the algorithm ends and the server continues to process the request
  4. if the bind DN matches a base entryOwner, or the bind DN and additional access information match an ownerFilter, then
    • full access is given if no matching ownerFilter specify the deny operator
    • then, the algorithm ends and the server continues to process the request
  5. if the alternate DN matches a base entryOwner, or the alternate DN and additional access information match an ownerFilter, then
    • full access is given if no matching ownerFilter specify the deny operator
    • then, the algorithm ends and the server continues to process the request
  6. if the group DN that the bind or alternate DNs belongs to matches a base entryOwner, or the group DNs and additional access information match an ownerFilter, then:
    • full access is given if no matching ownerFilter specify the deny operator
    • then, the algorithm ends and the server continues to process the request
If a match is not found or an ownerFilter denied access above, then aclEntry values are evaluated as follows:
  1. if no aclEntry attributes are specified, then the default permissions are applied, or
  2. if the bind is anonymous, and a base aclEntry matches the cn=anybody pseudo DN, or filter in an aclFilter component match the cn=anybody pseudo DN and additional access information, then:
  3. if a base aclEntry value matches the bind DN or filter in an aclFilter component matches the bind DN and additional access information, then:
  4. if a base aclEntry value matches the alternate DN or filter in an aclFilter component matches the alternate DN and additional access information, then:
  5. if the entry DN matches the bind DN, and a base aclEntry matches the cn=this pseudo DN, or filter in an aclFilter component match the cn=this pseudo DN and additional access information, then:
  6. if the entry DN matches an alternate DN, and a base aclEntry matches the cn=this pseudo DN, or filter in an aclFilter component match the cn=this pseudo DN and additional access information, then:
  7. if a base aclEntry value matches the group DN that the bind or alternate DNs belongs to or filter in an aclFilter component match the group DN and additional access information, then:
  8. if the bind DN is authenticated, and a base aclEntry matches the cn=authenticated pseudo DN, or filter in an aclFilter component match the cn=authenticated pseudo DN and additional access information, then:
  9. if the bind is authenticated, and a base aclEntry matches the cn=anybody pseudo DN, or filter in an aclFilter component match the cn=anybody pseudo DN and additional access information, then:
  10. the bound user does not receive any permissions
Step a. The algorithm applies permissions and ends as follows:
  • any matching base permissions are first applied
  • then, any matching aclFilter permissions are applied
  • finally, the algorithm ends and the server continues to process the request
Step b.
  • the union of matching base permissions is first applied
  • then, any matching aclFilter permissions are applied
  • finally, the algorithm ends and the server continues to process the request
Note: In each of these steps, permissions for matching filters can be set if base permissions are set or not.

If at least one aclEntry matches, access to system attributes are always granted read, search, and compare permissions, unless they are explicitly overridden.

The way aclFilter permissions are applied depends on the value specified for the operation (replace, union, and intersect). If there are one or more matching aclFilters, up to three temporary ACLs are formed from the union of all permissions for each operation. These are applied to the bound user's effective permission as follows:
  1. If there are filter permissions for the replace operation, the bound user's base effective ACL is replaced by the replace filter permissions to form a new effective permission.
  2. If there are any filter permissions for the union operation, the bound user's new effective permission becomes the union of the union filter permissions and the existing effective permission. The existing effective permission is produced by step 1, or if step 1 did not apply, it is the base effective permission.
  3. If there are any filter permissions for the intersect operation, the bound user's new effective permission becomes the intersect of the intersect filter permissions and the existing effective permission. The existing effective permission is produced by step 2, or if step 2 did not apply, then it is the existing effective permission produced by step 1, or if step 1 did not apply, it is the base effective permission.
When using attribute-level permissions or grant/deny support, the order of evaluation of the separate permissions clauses is important. The access control permissions clauses are evaluated in a precedence order, not in the order in which they are found in the ACL entry value. There are four types of permissions settings: access-class grant permissions, access-class deny permissions, attribute-level grant permissions, and attribute-level deny permissions. The precedence for these types of permissions is as follows (from highest precedence to lowest):
  • attribute-level deny permissions
  • attribute-level grant permissions
  • access-class deny permissions
  • access-class grant permissions

Using this precedence, a deny permission takes priority over a grant permission (for the same item specified) while attribute-level permissions take precedence over access-class permissions.

A similar grant or deny precedence exists for the grant or deny support provided for ownerFilter. A deny always takes precedence over a grant of entryOwner access.

Access determination examples

The following are examples that illustrate the permissions that users have for entries and attribute types.

Example 1: 
aclEntry: group:cn=Anybody:normal:rsc
In this example, unauthenticated (anonymous) users have permission to read, search, and compare all attributes within the normal attribute access class. ACL entry values for unauthenticated users use pseudoDN cn=Anybody.
Example 2: 
aclEntry: access-id:cn=personA,ou=deptXYZ,o=IBM,c=US:object:ad:normal:rwsc:sensitive:rwsc:critical:rsc
In this example, the user corresponding to cn=personA, ou=deptXYZ, o=IBM, c=US has permission to add entries below the entry, to delete the entry, to read, write, search, and compare both normal and sensitive attributes, and to read, search and compare critical attributes.
Example 3:
aclEntry: group:cn=Authenticated:normal:rwsc:sensitive:rwsc
In this example, users who have authenticated to the directory where a specific aclEntry value does not apply, are allowed to read, write, search, and compare, normal and sensitive attributes in the directory entry.
Example 4: 
aclEntry: cn=Tim,dc=yourcompany,dc=com:at.cn:deny:w:normal:rwsc
In this example, cn=Tim,dc=yourcompany,dc=com is granted read, write, search, and compare to normal attributes except for the cn attribute in which write access is denied. Note that the following ACL entry results in the same access: 
aclEntry: cn=Tim,dc=yourcompany,dc=com:normal:rwsc:at.cn:deny:w
The evaluation of the permissions clauses is based on precedence, not order in the ACL entry value.
Example 5:
aclEntry: cn=Karen,dc=yourcompany,dc=com:normal:rwsc:sensitive:rsc:at.userpassword:w:
 critical:deny:rwsc
In this example, cn=Karen,dc=yourcompany,dc=com is granted read, search, and compare to normal and sensitive attributes, and write to normal attributes and the userpassword attribute. All access to critical attributes (except for write in userpassword) is turned off.
Example 6: 
aclEntry: group:cn=group1,dc=yourcompany,dc=com:normal:rwsc
aclEntry: group:cn=group2,dc=yourcompany,dc=com:sensitive:rwsc:at.cn:deny:w
In this example, a member of group1 is only granted read, write, search, and compare to normal attributes. A member of both group1 and group2 is granted read, write, search, and compare to normal and sensitive attributes, excluding write access to the cn attribute. This is an example where a member of both groups is granted access to less information than what is granted to each of the two groups individually.
Example 7: 
aclEntry: access-id:cn=Tim,dc=yourcompany,dc=com:normal:rwsc:at.cn:rsc
In this example, cn=Tim,dc=yourcompany,dc=com is granted read, write, search, and compare on normal attributes and read, search, and compare on the cn attribute. Note that cn=Tim,dc=yourcompany,dc=com also has write access to the cn attribute by virtue of cn having an access class of normal.
Example 8: 
aclEntry: access-id:cn=Tim,dc=yourcompany,dc=com:normal:rwsc:at.cn:deny:rsc
In this example, cn=Tim,dc=yourcompany,dc=com is granted read, write, search, and compare on normal attributes and denied read, search, and compare on the cn attribute. Note that cn=Tim,dc=yourcompany,dc=com still has write access to the cn attribute by virtue of cn having an access class of normal.
Example 9: 
aclEntry: cn=Ken, o=Your Company:normal:rsc
aclEntry: aclFilter: (&(|(ibm-filterSubject=cn=Ken, o=Your Company)
 (ibm-filterIP=129.176.132.*))(ibm-filterTimeOfDay>=09:00)
 (ibm-filterTimeOfDay<=17:00)(ibm-filterDayOfWeek>=1)
 (ibm-filterDayOfWeek<=5)):union:normal:w
In this example, cn=Ken, o=Your Company is granted read, write, search, and compare access on normal attributes when authenticated from any IP address on Monday through Friday from 9:00 a.m. to 5:00 p.m.. On any other time or day, cn=Ken, o=Your Company is only granted read, search, and compare access on normal attributes.

If another user binds from IP address 129.176.132.28 on Monday through Friday from 9:00 a.m. to 5:00 p.m., they are granted write access on normal attributes.

Example 10: 
aclEntry: group:cn=group1, o=Your Company:system:rsc:normal:sw
aclEntry: aclFilter: (&(ibm-filterSubject=cn=group1, o=Your Company)
 (ibm-filterIP=129.176.*)(ibm-filterBindMechanism=CRAM-MD5)
 (ibm-filterConnectionEncrypted=true)):intersect:system:rsc:normal:s
In this example, if cn=Ken,o=Your Company is a member of cn=group1,o=Your Company, binds from IP address 129.176.113.76 using a CRAM-MD5 mechanism, over an encrypted SSL connection. cn=Ken,o=Your Company is granted system:rsc and normal:s permissions. Note the intersect operation restricted permissions by disposing of normal:w permissions.
Example 11: 
aclEntry: access-id:cn=Joe,dc=yourcompany,dc=com,o=IBM:normal:r
aclEntry: group:cn=group1,dc=yourcompany,dc=com:normal:rw
aclEntry: group:cn=group2,dc=yourcompany,dc=com:critical:rw
aclEntry: aclFilter:(&(ibm-filterSubject=cn=group1,dc=yourcompany,dc=com)
 (ibm-filterIP=129.176.*)):union:normal:sc
In this example, if cn=Joe,dc=yourcompany,dc=com,o=IBM is a member of cn=group1,dc=yourcompany,dc=com and binds from IP address 129.176.53.92, cn=Joe,dc=yourcompany,dc=com,o=IBM is only granted read permission on normal attributes, for the following reasons:
  • There is a specific access-id value for cn=Joe,dc=yourcompany,dc=com,o=IBM, therefore, only that base access-id ACL is granted, and no group ACLs are granted. cn=Joe,dc=yourcompany,dc=com,o=IBM's effective permission, before any filters are applied, is normal:r.
  • The resulting subject that is tested for membership in the filter is cn=Joe,dc=yourcompany,dc=com,o=IBM. It does not match, therefore, the ACL filter does not apply.

A member of cn=group1,dc=yourcompany,dc=com that binds from IP address 172.191.214.98 is only granted read and write permissions on normal attributes.

A member of both cn=group1,dc=yourcompany,dc=com and cn=group2,dc=yourcompany,dc=com that binds from IP address 129.176.98.112, is granted read, write, search, and compare access on normal attributes (because of the union with the filter), and is granted read and write access on critical attributes.

Example 12: 
aclEntry: access-id:cn=Mary,dc=yourcompany,dc=com,o=IBM:normal:rw
aclEntry: group:cn=group1,dc=yourcompany,dc=com:normal:rwsc
aclEntry: aclFilter:(|(ibm-filterSubject=cn=group1,dc=yourcompany,dc=com)
 (ibm-filterIP=129.176.92.*)):intersect:normal:rsc:critical:r
In this example, if cn=Mary,dc=yourcompany,dc=com,o=IBM (who is not a member of group1,dc=yourcompany,dc=com) binds from IP 129.176.92.113, cn=Mary,dc=yourcompany,dc=com,o=IBM is granted read permission on normal attributes. This is because cn=Mary,dc=yourcompany,dc=com,o=IBM's effective permission is determined by the intersect of normal:rw and the ACL filter. Note the intersect operation restricted permissions by disposing of normal:wsc and critical:r while keeping normal:r permissions.
Example 13: 
aclEntry: group:cn=group1,dc=yourcompany,dc=com:normal:rwsc
aclEntry: aclFilter:(ibm-filterIP=129.176.*):replace:normal:rw
aclEntry: aclFilter:(!(ibm-filterSubject=cn=group1,dc=yourcompany,dc=com))
 :replace:normal:deny:w
In this example, a member of cn=group1,dc=yourcompany,dc=com that binds from IP address 129.176.29.52 is granted read and write access to normal attributes. The base aclEntry for cn=group1,dc=yourcompany,dc=com is first applied, and is then replaced by the aclEntry with aclFilter for ibm-filterIP=129.176.*.
Example 14: 
aclEntry: aclFilter:(ibm-filterIP=129.176.29.52):intersect:normal:sc
aclEntry: aclFilter:(ibm-filterIP=129.176.*):replace:normal:r
aclEntry: aclFilter:(ibm-filterSubject=cn=group1, o=Your Company)
 :union:critical:r
aclEntry: aclFilter:(ibm-filterIP=129.176.29*):union:sensitive:r
aclEntry: aclFilter:(ibm-filterSubject=cn=Mary, o=Your Company)
 :intersect:normal:r
aclEntry: group:cn=group1, o=Your Company:normal:rw
aclEntry: aclFilter:(ibm-filterSubject=cn=group1, o=Your Company)
 :replace:normal:rwsc
In this example, if cn=Mary, o=Your Company, a member of cn=group1, o=Your Company, binds from IP address 129.176.29.52, cn=Mary, o=Your Company's effective permission is determined by all of the aclEntry values above, as follows:
  1. cn=Mary, o=Your Company's base effective permission is granted read and write permissions on normal attributes. This is because cn=Mary, o=Your Company is a member of cn=group1, o=Your Company.
  2. The replace filters that match for cn=Mary, o=Your Company are then joined to produce one replace filter with read, write, search, and compare access on normal attributes. These permissions now become cn=Mary, o=Your Company's effective permission, replacing Mary base effective permission.
  3. The union filters that match for cn=Mary, o=Your Company are then joined to produce one union ACL with read permissions on sensitive and critical attributes. These permissions are joined with cn=Mary, o=Your Company's effective permission that was produced in step 2. This produces cn=Mary, o=Your Company's new effective permission, granting read, write, search, and compare permissions on normal attributes, and read permissions on sensitive and critical attributes.
  4. Finally, the intersect filters that match for cn=Mary, o=Your Company are joined to produce one intersect ACL with read, search, and compare access on normal attributes. These permissions are intersected with the effective permission produced by step 3, to produce cn=Mary, o=Your Company's final effective permission, giving Mary read, search, and compare access on normal attributes.
Example 15: 
entryOwner: ownerFilter:(&(ibm-filterSubject=cn=Ken, o=Your Company)
 (ibm-filterIP=129.176.132.*))
In this example, cn=Ken, o=Your Company is given owner access only when bound from an IP address within the 129.176.132.* subnetwork.
Example 16: 
entryOwner: access-id:cn=Ken, o=Your Company
entryOwner: ownerFilter:(&(ibm-filterSubject=cn=Ken, o=Your Company)
 (ibm-filterIP=129.176.132.*)):deny
In this example, cn=Ken, o=Your Company is granted owner access when bound from an IP address that is not within the 129.176.132.* subnetwork. However, cn=Ken, o=Your Company is denied owner access when bound from an IP address that is within the 129.176.132.* subnetwork.

Search

In order to read an attribute from the directory, the user must have read permission for the specific attribute or for the attribute access class that the attribute belongs.

Filter

In order to use an attribute in a search filter supplied on a search operation, the user must have search permission for the specific attribute or for the attribute access class that the attribute belongs.

Compare

In order to perform a compare operation on an attribute/value combination, the user must have compare permission for the specific attribute or for the attribute class that the attribute belongs.

Requested attributes

If the user has the search permission on all attributes contained in the filter, the server returns as much information as possible. All requested attributes that the user has read permission for are returned.

For example, allow the aclEntry be

group:cn=Anybody:normal:rsc:sensitive:c:critical:c

and allow the client to perform an anonymous search

ldapsearch -b "c=US" "cn=LastName" title userpassword telephoneNumber

where title is a normal attribute, telephoneNumber is a sensitive attribute, and userpassword is a critical attribute. Users performing anonymous searches are given the permission granted to the cn=Anybody group. In this example, permission exists to the filter because cn is in the normal attribute access class, and cn=Anybody has s (search) permission to the normal attribute access class. What is returned however, is only the title attribute for any matching entry. The telephoneNumber and userPassword attributes are not returned because cn=Anybody does not have read permissions on the sensitive and critical attribute access classes.