Access control lists (ACLs) define access to objects and attributes in the AS/400 Directory Services LDAP directory. Each object in a directory contains several attributes which describe who is allowed to access information within that object. Click one of the following links to see information on that attribute:
Click here to see an example that incorporates all of the above attributes.
Click here to see the default attribute settings for AS/400 Directory Services.
aclEntry is a multi-value attribute. It contains information that pertains to the access that is allowed to the entry object and to each of its attributes. An aclEntry lists the following types of information:
Scope of protection:
The scope of the protection is based on the following two types of privilege attributes:
Normal groups have an object class of "GroupOfNames", "GroupOfUniqueNames", or a user-defined group. Access control groups are object class "AccessGroup". The "AccessGroup" object class is a subclass of the "GroupOfNames" object class. Groups identified in an aclEntry must be of object class "AccessGroup".
Privilege attributes take the form type:name, where type refers to either "access-id" or "group", and name is the distinguished name.
In the following example, the DN type is "access-id", and the DN itself is "cn=personA, ou=deptXYZ, o=IBM, c=US":
access-id:cn=personA, ou=deptXYZ, o=IBM, c=US
In the following example, the DN type is "group", and the DN itself is "cn=deptXYZRegs, o=IBM, c=US":
group:cn=deptXYZRegs, o=IBM, c=US
Attribute access classes:
Attributes that require similar permission for access are grouped together in classes. Attributes are assigned to attribute classes within the schema files. The three user-modifiable attribute classes are:
Each of these attribute classes is discrete. That is, access to information in one class does not give access to information in any other class. Attributes have a default attribute class of "normal".
In the following example attribute definition, userPassword has been assigned membership in the "critical" access class, while DN has been assigned membership in the "normal" access class:
attributetypes=( 2.5.4.49 NAME ( 'dn' 'distinguishedName' ) DESC ' ' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE userApplications ) IBMAttributetypes=( 2.5.4.49 DBNAME( 'dn' 'dn' ) ACCESS-CLASS normal LENGTH 1000 ) attributetypes=( 2.5.4.35 NAME ( 'userPassword' ) DESC 'Holds a password value for a distinguished name.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 USAGE userApplications ) IBMAttributetypes=( 2.5.4.35 DBNAME( 'userPassword' 'userPassword' ) ACCESS-CLASS critical )
Access permissions:
The following access permissions apply to an entire object:
The following permissions apply to attribute access classes:
Each of the LDAP access permissions is discrete. One permission does not imply another permission. If you give a user (access-id) an aclEntry for a particular object, the user receives that permission. If no permission is given to the user, the user receives permission based on the object's ACL, and the bound user receives the combined permissions of all listed access groups.
| Note: | There are two types of LDAP searches. One retrieves both attributes and values, and the other retrieves only attributes. In order to retrieve both attributes and values, a user must have both read and search permission to the corresponding attributes class. |
If the user is not listed on the ACL, and is not a member of any listed access group, then the user receives permissions listed under the ACL group "CN=Anybody". If this group does not exist, the user is denied access to the object.
In the following example, members of the group "CN=Anybody" have the permission to read, search, and compare all attributes within the "normal" class:
group:cn=Anybody:normal:rsc
In the following example, the user that corresponds to access-id "cn=personA, ou=deptXYZ, o=IBM, c=US" has permission to do the following:
access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rwsc:cr
Each directory object has an aclSource attribute. This attribute reflects the DN with which the ACL is associated. The server keeps this attribute, but it may be retrieved for administrative purposes.
This "true" or "false" object attribute specifies whether or not the object's ACL is propagated to objects below it in the directory hierarchy. An object without an explicit ACL receives its ACL from the first propagating ACL above the object in the directory hierarchy. Propagated ACLs do not accumulate. The scope of a propagated ACL is from the explicitly set propagating ACL down through the directory hierarchy until another propagating ACL is found.
Example 1: Propagation
The entry "ou=deptXYZ, o=IBM, c=US" has the following explicit ACL:
aclPropagate: True aclEntry: group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc aclEntry: access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rsc aclEntry: group:cn=Anybody:normal:rsc aclSource: ou=deptXYZ, o=IBM, c=US
The entry "cn=personA, ou=deptXYZ, o=IBM, c=US" has the following implicit ACL::
aclPropagate: True aclEntry: group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc aclEntry: access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rsc aclEntry: group:cn=Anybody:normal:rsc aclSource: ou=deptXYZ, o=IBM, c=US
In this example, a propagating ACL has been set on "ou=deptXYZ, o=IBM, c=US". On the descendant "cn=personA, ou=deptXYZ, o=IBM, c=US", no ACL has been set. Therefore, the descendant inherits its ACL from the first ancestor with a propagating ACL, which in this case is "ou=deptXYZ, o=IBM, c=US". This is reflected in the aclSource field. The aclEntry and aclPropagate values are identical to the explicit propagating ACL set at "ou=deptXYZ, o=IBM, c=US".
Example 2: Overrides
The entry "o=IBM, c=US" has the following explicit ACL:
aclPropagate: TRUE aclEntry: group:cn=IBMRegs, o=IBM, c=US:normal:rcs:sensitive:rsc aclEntry: group:cn=Anybody:normal:rsc aclSource: o=IBM, c=US
The entry "ou=deptXYZ, o=IBM, c=US" has the following explicit ACL:
aclPropagate: FALSE aclEntry: group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc aclEntry: access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rwsc aclEntry: group:cn=Anybody:normal:rsc aclSource: ou=deptXYZ, o=IBM, c=US
The entry "cn=personA, ou=deptXYZ, o=IBM, c=US" has the following implicit ACL:
aclPropagate: TRUE aclEntry: group:cn=IBMRegs, o=IBM, c=US:normal:rcs:sensitive:rsc aclEntry: group:cn=Anybody:normal:rsc aclSource: o=IBM, c=US
In this example, a propagating ACL has been set on "o=IBM, c=US". On the descendant "ou=deptXYZ, o=IBM, c=US", an explicit ACL has been set which overrides the ACL that would otherwise have been inherited from "o=IBM, c=US". The entry "cn=personA, ou=deptXYZ, o=IBM, c=US" inherits its ACL from the first ancestor with a propagating ACL. Because "ou=deptXYZ, o=IBM, c=US" has the aclPropagate attribute set to "FALSE", "cn=personA, ou=deptXYZ, o=IBM, c=US" inherits its ACL from "o=IBM, c=US". The aclSource attribute reflects this.
The entryOwner attribute specifies the owner of a directory object. The user or group specified by entryOwner receives complete access to all of the object's attributes. In essence, they are the administrator for a particular object.
The ownerSource attribute reflects the DN with which the owner values are associated. The server keeps this attribute, but it can be retrieved for administrative purposes.
Owner propagation works in exactly the same way as ACL propagation works. By default, objects inherit owners through the directory hierarchy, and their ownerPropagate attribute is set to "TRUE". If ownerPropagate is set to "FALSE", the owner becomes an override that pertains only to that particular object.
The following entry shows a typical ACL for the entry "cn=personA, ou=deptXYZ, o=IBM, c=US":
entryOwner: access-id:cn=deptXYQMgr, ou=deptXYZ, o=IBM, c=US
ownerPropagate: TRUE
aclPropagate: TRUE
aclEntry: group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc
aclEntry: access-id:cn=personA, ou=deptXYZ, o=IBM,
c=US:object:ad:normal:rwsc:sensitive:rwsc:critical:rsc
aclEntry: group:cn=Anybody:normal:rsc
aclSource: ou=deptXYZ, o=IBM, c=US
ownerSource: ou=deptXYZ, o=IBM, c=US
The entry inherits both its owner properties and its ACL properties from object "ou=deptXYZ, o=IBM, c=US". Members of the group "cn=deptXYZRegs, o=IBM, c=US" have permission to read, search, and compare objects in both the normal and sensitive attribute classes. They do not have permission to add or delete objects under this object. Nor do they have permission to access any information or change any information on attributes in the critical class.
PersonA has add and delete permission on the object, read, write, search, and compare permissions on normal and sensitive attributes. PersonA also has read, search, and compare permission on critical attributes.
All other users have permission to read, search, and compare attributes in the normal attribute class only.
AS/400 Directory Services ACL defaults:
AS/400 Directory Services has the following ACL defaults, assuming that the administrator DN is "cn=admin, c=US":
entryOwner: access-id:cn=admin, c=US ownerPropagate: TRUE aclPropagate: TRUE aclEntry: group:cn=Anybody:normal:rsc aclSource: default ownerSource: default
| [ Information Center Home Page | Feedback ] | [ Legal | AS/400 Glossary ] |