An important principle that guided the designers of the access control scheme is that if a user does not have access rights to some or all of the information required by an operation, then the operation result or error returned to the user will be the same as if that information did not exist in the Directory. In other words, the operation result or error will be the same as the one the user would have received, if the only information present in the Directory was information to which the user did have access rights. Fig. 8.4 summarises the responses that are given to a user for each combination of information present and permission to access it. It can be seen that the user is only allowed to access the information, when they have the appropriate permission. It is impossible for a user to deduce that information is present in the Directory, but that they do not have permission to access it, since the Directory response to this is the same as if the information was not present. The precise response received by the user will depend upon the operation and the permission that is denied. For example, when reading attributes from an entry, those for which permission is denied will simply be omitted from the result. If permission to read the entry is denied, then the user will be given the error response Name Error (No such object).
However, if the information owner so desires it, it is possible to disclose to a user that the information is present, but that they do not have access rights to it. This is achieved by giving the user a minimum permission (DiscloseOnError), the effect of which is either to qualify a result as having some information missing, or to turn a Not Present error response into a Security Error 'insufficient access rights'.
If the user only wishes to read the types of attribute present in the entry, then they must have Read permission (grant Read) for each attribute type that is returned in the result. Attribute types for which the user has no Read permission, are excluded from the result.
If this would mean that no attribute types are returned, then an error is returned to the user instead of an empty set of entry information.
When a Read result is incomplete, because the user did not have Read permission to one or more of the attribute types or values that were requested, the user is normally unaware that some information has been withheld. The user is led to believe that it did not exist. However, if the user has DiscloseOnError permission to any of the omitted pieces of information, the user is told that they only received part of the entry information. (This is notified via the incompleteEntry boolean in the response being set to True.)
Finally, the user needs Compare permission (grant Compare) for each
attribute value that is to be compared against the presented one. Attribute
values without this permission are ignored. True will be returned to the
Compare operation, only if an identical attribute value to that presented
by the user, actually exists in the entry, and the user has Compare permission
Note. 'Identical' actually means that the value presented by the user gives a True response when comparing it to an attribute value stored in the entry, using the equality matching rule defined for the attribute (§ 5.7).
There is an added complication with the List operation, which arises
if some of the subordinates are in other DSAs. The DSA will need to chain
the operation to the subordinate DSAs, unless a copy of all the necessary
information is held locally.
Note.The totality of information needed by the superior DSA, for complete local processing of the List operation, is: the access control information, the RDN, and the object class of the subordinate entry. The latter is needed in order to determine if the subordinate is an alias or not.
Likewise, the subordinate DSA, in order to correctly process a request generated from a continuation reference, needs the access control information of the superior entry when the user does not have browse and returnDN permission to the subordinates. Without this information, a Service Error (invalid reference) must be returned to the user. With this information, and if the user has discloseOnError rights to the superior entry, an empty set of subordinates may be returned.
The Hierarchical Operational Binding is designed to provide this information, and to keep it up to date, and so with this in place, chaining will not be required. The DSA will be able to process the List operation locally. Without a Hierarchical Operational Binding providing all the information, the DSA will need to either chain the operation to the subordinate DSAs and merge the returned results, or return a continuation reference to the requestor. There are no additional security requirements for chaining, as the subordinate DSAs can each check the user's access rights to the subordinate entries before returning the RDNs.
But what if the user forbade chaining via the chaining prohibited service control, or if the DSA's policy is not to chain? In the former case, a Service Error with problem chaining required may be returned to the user. In the latter case a Continuation Reference will be added to the result. However, if the result consists solely of Continuation References, and does not hold the names of any subordinates, then the user must have DiscloseOnError permission to the parent entry in order to receive them. Otherwise the user receives a Name Error (no such object). This is to stop a user with no permissions at all, from determining that the parent entry exists, which of course they can infer from the returned continuation reference.
For each entry that has been included in the scope of the Search, the next step is to evaluate the filter. This requires permission to use the attributes held in the entry for matching against items in the filter (w/w 8.3). Permission is first required to use the attribute type for filtering (grant FilterMatch for item attributeType). If permission is not given, then the filter item evaluates to undefined. This is exactly the same result as if the attribute were not present in the entry. If permission is given, then filter items using attribute types can be evaluated straight away. Filter items using attribute values also require FilterMatch permission on each attribute value that is to be used in the matching. Values without the grant FilterMatch permission are ignored. Any attribute values with FilterMatch permission, are evaluated against the filter item, and will yield True or False. If no value permissions are granted, a filter item will evaluate to False. After completing the evaluation of the filter, an entry will either be selected for or discarded from inclusion in the Search result.
The next step is to decide which information from each selected entry may be included in the Search result. This process is very similar to that used for selecting information from an entry for inclusion in a Read result. Read permission (grant Read) is needed for each of the attribute types chosen by the user. Without this permission, an attribute is omitted from the result. The only difference between a Read and a Search result, is that the selection of no attributes by the Directory causes an error response to be sent to the Read, whereas with Search an empty entry is returned. If attribute types and values were requested by the user, then processing of this is identical to that of the Read operation. Read permission is required for each attribute type and value returned in the result. An empty set of values will be returned if permission was given to read an attribute type but not to any of its values.
The final step is to determine if the names of the selected entries can be returned to the user. If the user has ReturnDN permission to a selected entry, then its distinguished name will be returned in the result. If the user does not have ReturnDN permission, then clearly the distinguished name cannot be returned. Instead, the DSA may substitute a known alias name for the entry, and return this to the user. The Standard says that it is a local (i.e. implementation) matter how the DSA knows the name of an alias of the entry. If no alias name is known by the DSA, then the selected entry unfortunately has to be discarded from the set of results, since the DSA is unable to return a name for it.
Finally, the user may be given notification that an entry in the result does not contain all the information that they requested (via incomplete entry boolean set to True). This will be given if any of the omitted attribute types or values have permission to disclose their presence if an error has occurred (grant DiscloseOnError). (In this case the error is that the user did not have Read permission to the attribute or value.) Without DiscloseOnError permission, the user will be led to believe that the omitted information was not present in the entry.
The complication arising from entries within the scope of the Search, residing in other DSAs, has also been addressed. Chaining does not pose an additional security risk to the superior DSA, but returning Continuation References to the user does. Therefore, if the result consists solely of Continuation References, the user must have DiscloseOnError permission at the base entry, in order to receive them. Without this, the user will receive a Name Error (no such object) response, exactly as with the List operation.
First of all, the user requires Add permission for the new entry being added (grant Add for item entry). Without this permission, the operation will fail. Using the principle outlined in § 8.5 and Fig. 8.4, that without permission, a user is always told that information is not present in the Directory, the user will receive a Name Error (No Such Object). The matched component of the error will either point to the next superior above the entry to be added, for which the user has grant DiscloseOnError permission, or if there are none, point to the root of the DIT. Note that this error will be returned, even if the entry already exists i.e. if it was previously added by someone else. In this way the unauthorised user cannot glean information from the Directory, by finding out via error diagnostics, what is present. The only exception to the return of the Name Error (No Such Object), is if the user has the minimum permission (grant DiscloseOnError) to the entry to be added. The error (s)he will receive will then depend upon whether or not the
Fig. 8.6 Responses given to a user with and without Add permission for the entry (AddEntry operation).
entry actually exists. If it does, the user will receive Update Error (Entry Already Exists), but if it does not, then they will receive a Security Error (either Insufficient Access Rights or No Information). The responses generated by the Directory are summarised in Fig. 8.6.
Assuming the user has Add permission to the entry, the user then requires Add permission for each attribute type and value that is to be added to the entry (grant Add to all items). If just one item is lacking Add permission, then the operation will fail with the above Security Error.
If the user has Add permission, but the entry is already present in the Directory, then they will be told that the entry already exists.
The only complication with the AddEntry operation, comes from adding an entry across DSA boundaries. Local security policy may forbid this, in which case the superior DSA may return any appropriate error - such as Update Error (Affects Multiple DSAs) - providing that the user has DiscloseOnError permission to the superior entry. If this permission is not available, Name Error (No Such Object) should be returned, as described above.
The user also requires Add permission for each attribute type and value to be added, and Remove permission for each attribute type and value to be removed (w/w 8.2). If any one permission is not granted, then the whole operation fails with an error diagnostic. Deriving the error message that is returned is complex, and is based on the logic of the first guiding principle, though this has to be modified when applying it to adding information to the Directory (but see w/w 8.4). Figs 8.7, 8.8 and 8.9 show the error messages that are returned when: adding attributes, adding attribute values, and removing attributes and values respectively.
When trying to add an attribute type or value, a user is only told that it already exists (Attribute Error (Attribute Or Value Already Exists)), if they have permission to add the information, or failing that, DiscloseOnError permission to the information. Without these permissions, the user who is adding an attribute is returned a Security Error with a problem code of either Insufficient Access Rights or No Information, irrespective of whether or not the attribute exists (Fig. 8.7).
Fig. 8.7 Responses given to a user with and without Add permission for the attribute (ModifyEntry operation).
When adding attribute values, a user without the Add or DiscloseOnError permissions is told that the information does not exist (via the Attribute Error (No Such Attribute Or Value)) irrespective of whether or not the information already exists. (Incidentally, this error is also returned to users who have permission to add an attribute value, when the attribute does not yet exist in the entry. In other words the operation should have been to add an attribute, and not an attribute value.) The only exception to the 'does not exist' deception, is if the user has DiscloseOnError permission to the already existing attribute type, in which case they receive a Security Error (Fig. 8.8).
Fig. 8.8 Responses given to a user with and without Add permission for the attribute value (ModifyEntry operation).
Note that it is not usually possible to give someone permission to modify a single attribute value, since the ModifyEntry operation is based on adding and removing values. Giving someone permission to remove a single value is possible (as in ACI Item VE3 in Fig. 8.12) but not to add a single value, since the value to be added would need to be quoted in the ACI, and it does not exist! (The only time that users can be given permission to modify a single attribute value is with item selfValue on values of attributes whose syntax are distinguished names.)
When trying to remove information, the usual error message in the absence of Remove permission, is that the information is not present in the Directory (Attribute Error (No Such Attribute Or Value)) - this error message is also given to authorised users who specify non existent attributes and/or values. However, if DiscloseOnError permission has been granted, and the attribute or value is present, then a Security Error is returned to the user (Fig. 8.9).
Fig. 8.9 Responses given to a user with and without Remove permission for the attribute type or value (ModifyEntry operation).
If the operation is being used to modify the RDN of an entry, then Rename permission is needed for the entry (grant Rename for item entry). No further permissions are required. Without Rename permission, the user is told that the entry does not exist (Name Error (No Such Object)), unless DiscloseOnError permission has been granted, in which case a Security Error is returned to the user.
If the operation is being used to move an entry (or a subtree) to a new superior in the DIT, then Export and Import permissions are required. The user requires Export permission for the entry being moved (grant Export for item entry). Even if a whole subtree is being moved, as might be the case when an organisation restructures itself, Export permission is only required for the entry at the apex of the subtree. The subordinates tag along behind it to their new home. The user also requires Import permission for the space (entry) in the DIT where the entry is to be placed. This permission can only be given via a PrescriptiveACI, analogous to the AddEntry situation. Without either permission, the user receives the same error as in the ModifyRDN style of use.
If the operation simultaneously moves an entry and changes its RDN (Fig. 5.8), then all of the above permissions are needed.
There are problems though, if referrals instead of chaining takes place. With referrals, the aliased object name may be returned to the user. In order to try and control this, the following permissions are required before the dereferencing DSA will return a Continuation Reference in a referral, or in a List or Search partial result. The user requires Read permission for the alias entry, for the Aliased Object Name attribute and for the attribute's single value. If any of these permissions are missing, then instead of a referral, an Alias Dereferencing Problem is returned (§ 5.18.2), and in the case of a List or Search operation, the continuation reference is omitted from the partial result.
This mechanism is not completely watertight, since a subsequent DSA
in a chain might return a referral, and the aliased object might then be
deducible from this. No solution is currently available for this problem.