Chapter 8

Controlling access to the Directory information

8.1 INTRODUCTION

The Access Control scheme described in the Standard is based on access control lists, rather than capabilities.
Note. Capability schemes rely on users presenting tokens (or capabilities) to the system. The possession of a token gives the user a certain right to access the information held on the system. Different tokens give different access rights, such as read or update. Capabilities can be passed from one user to another. Capability schemes have the benefit that users do not need to be authenticated by the system, the mere possession of a token is sufficient to guarantee access. In this way, capabilities are like keys to locks; possession of a key allows you to unlock the door. However, capability schemes experience difficulties in managing the tokens, and in revoking lost or stolen capabilities.
The access control scheme stores lists of users' names against the information that they can access and the type of access that they are being given. This is similar to many filestore access control schemes in use today, although the Directory scheme has rather more bells and whistles that can optionally be used. The scheme is very simple in concept, although the detailed technicalities, which will be described later, are quite complex. Most of these details should be hidden from the user/administrator by the interface provided by an implementation. The challenge really is to the implementors of the scheme to provide clean, simple, easy to use access control interfaces that allow the system administrators to easily configure in understandable representations of their local security policies (§ 8.7). Since ease of understanding is not a strong point of the access control scheme as described in the Standard, this chapter should go some way towards helping the implementor. The initial sections of this chapter should also be of use to administrators and users, since they provide a general overview of the scheme.

8.1.1 The Guiding Principles of the Access Control Scheme

There are several guiding principles that drove the development of the access control scheme, and these need to be understood by users, administrators and implementors.

The first principle is that information in the Directory is not present (from a user's perspective) unless a user has permission to access it. This means that before anyone is able to access anything i.e. perform any Directory operation, they must first be given access rights to the information via the appropriate access control items. This is discussed in more detail in § 8.5.

The second principle is one of precedence. There may be several access control items in a list that apply to a particular user trying to access the Directory. Each access control item is given a precedence when it is first created, and high precedence items overrule low precedence items. Thus if one access control item, having a precedence of 50, states that everyone is denied read access to a particular attribute, and another access control item with a precedence of 75, says that Bill can read this particular attribute, then the second item will take precedence over the first item, and Bill will be granted read access to the attribute. Coupled to this principle, is one that states that a denied access overrules a granted access, if both have the same precedence and specificity.

The next principle is one of specificity, and this states that specific access control items overrule less specific access control items of the same precedence. Thus if one access control item, of precedence 50, says that Bill is denied read access to all attributes, but another item, of precedence 50, says that Bill can read the telephone number attribute, then Bill will have read access to the telephone number attribute.

The precise details of how the access rights of a user are determined from the complete set of access control items that are stored in the Directory, are described in § 8.9.

8.1.2 Overview of the Access Control Scheme

The Access Control scheme described in the Standard is quite a complex one. This is because there were so many conflicting viewpoints, that a compromise had to be reached that every country could ratify (w/w 8.1). The scheme that was eventually standardised is rich enough to allow most, if not all, security policies to be configured in by system administrators, although it is also possible to adapt the scheme to be very simple indeed, by ignoring many of the bells and whistles. Indeed, there is a standardised simplified scheme, and this is described in § 8.10.

The Access Control scheme consists of a number of different components. Firstly we have the application of the administrative model of the DIT to the provision of security within the separate administrative areas. This allows an administrator to apply different access controls to different parts of their administrative area. For example, an administration might impose a policy that states that everyone from the external XYZ Corporation is allowed to read the telephone numbers of all the organisational people within the local administrative area. Another part of the policy might be that people from the Pharmaceuticals division can read all the attributes of the organisational people in the Plastics division. Access control policies are stored as access control lists in the subentries of an administrative area. It will be a function of the administrator interface to map these easily understood policies into the actual operational attributes that are stored in the Directory. The administrative model was first introduced in Chapter 2, and its application to access controls will be reviewed again in § 8.2.

An access control list essentially defines the pieces of information that are being protected (the protected items), and whom they are being protected against (the user classes). A list also contains the types of user access, or permissions, that the information is being protected against. So for example, we could have an access control list that states that Bill, Fred and Hanna have Read, Modify and Browse permissions to a particular entry and all of its attributes. Access control items in a list may be given a precedence, and it is also possible to indicate the type of authentication (authentication level) that users must have undergone, in order for an access control list to grant them or not deny them access (§ 8.1.3). A detailed description of access control lists is presented in § 8.4.

Because a user can appear in several different access control lists, and in the same list several different times, an algorithm needs to be defined to say how the different occurrences are combined together. This is the Access Control Decision Function described in § 8.9.

Finally, because each Directory operation potentially involves accessing lots of different data items, the complete set of permissions that a user must have, in order to successfully perform a given Directory operation, needs to be described (§ 8.5). And if the user is missing one or more of these permissions, what result or error diagnostic should be returned to him? This is described in some detail in § 8.5.1 onwards.

8.1.3 Authenticating the User

The access control scheme requires Directory users to be identified (or authenticated) before access can be granted to them. The previous chapter described the authentication scheme defined by the Standard. Once the name of a user has been authenticated, there needs to be a mapping from the authenticated name into the equivalent name appearing in the access control lists. This mapping is not standardised, and is left up to implementors and system administrators. The most common mapping is likely to be one of equality, i.e. authenticated names are the same as names used in the access control lists. An example of when the mapping may be different, is when an authenticated user is mapped into a system administrator or super-user name held in the access control lists.

In addition, each access control list holds an indication of the type or level of authentication that the user must have undergone if an access control item is to give him or not deny him permission to access some information. If the access control item grants some permission to the user, then the user must have been authenticated to at least the level specified in order to be granted the permission. For example, suppose an access control item grants Fred permission to modify an entry if he has been strongly authenticated. Now if Fred Binds to the Directory and only quotes his password (i.e. simple authentication) he will not have been granted permission to update the entry. If an access control item denies a user some permission, then all users will have to have been authenticated to at least the level specified, if the access control item is not to deny them access. For example, suppose an access control item denies Fred permission to modify an entry, and it requires strong authentication. Now if Mary Binds to the Directory and quotes her password, she will also be denied permission to modify the entry because she did not authenticate herself sufficiently to prove that she was not Fred.

However, what happens when the home DSA authenticating the user is not the DSA evaluating the operation? In this case the evaluating DSA would still like to know what type of authentication was performed by the home DSA. A field in the Chaining Arguments (authentication level - see § 9.13.13) allows the home DSA to inform the evaluating DSA to what level the user was authenticated. Of course, the evaluating DSA will need to trust the home DSA and all intermediate DSAs in the chain, if it is to believe the home DSA (§ 7.4.4). The exact syntax of the 'authentication level' parameter is described in § 8.4.

8.2 APPLICATION OF THE ADMINISTRATIVE MODEL TO ACCESS CONTROLS

The basic administrative model was described in Chapter 2. It is flexible enough to allow an administrator to be able to control access to a complete autonomous administrative area (AAA), or to only a fraction of it. When an administrative area is viewed for the purposes of administering the security of the information in the DIT, it is termed an Access Control Specific Administrative Area (this is abbreviated to ACSA in the Standard). An autonomous administrative area (AAA) may be partitioned into one or more non-overlapping Access Control Specific Administrative Areas. Partitioning would typically be performed when units of an organisation are each solely responsible for their own security policies. Each ACSA is autonomous from a security perspective, so that no access control information specified in one area will have jurisdiction in another area. As an example, a large conglomerate company may form one AAA, keeping complete control over company wide naming and schema administration, but allowing corporate headquarters and each operating division to be an ACSA. Each division would then have full security control over access to its own information, as shown in Fig. 8.1. This means that access control lists created in one division will have no effect over users accessing the Directory data of another division. However, the divisions would not control the administration of the schema, as the AAA has not been partitioned into separate subschema administrative areas (this is similar to that depicted in Fig. 2.7). Alternatively, each operating division could be designated a full AAA, and each would then have complete control over all the administrative functions of the DIT - access controls, schema and collective attributes. In this case the situation would resemble that depicted in Fig. 2.5.

Fig. 8.1 An Autonomous Administrative Area divided into several Access Control Specific Areas.

Fig. 8.2 An Access Control Specific Area containing several Access Control Inner Areas.

An access control specific administrative area, or ACSA, may have nested areas within it, to which partial security administration is delegated. A nested area is termed an Access Control Inner Administrative Area (ACIA). ACIAs may themselves contain other nested ACIAs. The access controls that apply within an ACIA are a combination of those specified within the inner area itself, and those specified in the enclosing specific area and other enclosing inner areas (if any). Referring back to the conglomerate company, if head office wished to retain overall control of access to the information in the operating divisions, it could make each division an ACIA, as shown in Fig. 8.2, rather than an ACSA. Each operating division would then only partially control access to its information, as delegated by head office. A division could also delegate partial security control to units within itself. For example, in Fig. 8.2, the R&D unit has been delegated this privilege. The degree of security administration delegated to the inner areas would be a local matter, to be resolved between head office and the operating divisions, and between an operating division and its units. Typically, head office might specify default access control policies, whilst the operating divisions might specify further restrictions to some of the attributes and entries. For example, head office might define an access control policy (stored in a subentry below the O=Chemical Conglomerate Inc AAP) which specifies that everyone (i.e. the public) can have read access to common names, telephone numbers, and

Email addresses of all entries in the AAA, and that employees can have read access to all attributes in all entries. The Plastics division might further limit this by its own policy (stored in a subentry below the OU=Plastics IAP) which states that everyone is denied read access to the Email address attribute within its division. Further, the R&D unit might, as a matter of policy, deny everyone read access to all entries in the R&D unit. Joe Public would then only be able to read the Email addresses of people in the Pharmaceuticals and Agri divisions, and would not be able to read anything from the R&D unit. On the other hand (assuming each policy had the same precedence) Mr Employee would still have access to everything, due to the principle of specificity (employees are more specific than everyone - see § 8.9).

8.2.1 Directory Access Control Domains (DACDs)

In many cases administrators will want access control policies to apply throughout a whole administrative area. As stated in Chapter 2, the extent of an autonomous administrative area is implicitly defined, since it starts at the administrative point, and proceeds downwards in the DIT until another autonomous administrative point (AAP) or leaf entry is encountered. ACSAs and ACIAs are similarly implicitly defined, in that they start at their respective points, and extend downwards until a leaf entry or another access control specific point or AAP is encountered. (Note that the start of an ACIA does not define the end of the previous or enclosing access control area.) Thus by default, access control policies control access to all the entries in an administrative area.

However, it is recognised that within any given access control area (ACIA or ACSA), the application of an access control policy will not always want to be uniform, i.e. all the entries in the access control area have the same access control list applied to them. Therefore an access control area can be split up into arbitrary overlapping collections of entries, called Directory Access Control Domains (DACD), to which a uniform application of an access control policy can be applied. For example, an access control domain could be made for each of the following groups of entries : all employees, some middle managers, all OSI applications, network management applications etc., and different access control policies can be applied to each of them.

Directory access control domains are specified using the familiar subtree specification technique (§ 2.12.1). Directory Access Control Domain is therefore just another term for a DIT subtree or subtree refinement! Below a given access control administrative entry (specific or inner), there can be any number of subentries, each describing the same or different collections of entries within the access control area. Each subentry describes just one DACD, since it only contains one subtree specification attribute. The subtree specification is explicit, in that it specifies where the domain starts within the access control area, and where it ends. It also specifies which class of entry within the defined area is to be included in the domain (via the specification filter).

An access control domain can never stray outside the bounds of its enclosing access control area. For example, in Fig. 8.3 there is one access control specific area containing one access control inner area, and DACD2 is entirely within the bounds of its access control inner area, and DACD1 and DACD3 are entirely within the bounds of their access control specific area. An access control domain can, however, include entries that are within the boundaries of a subordinate inner area, e.g. in Fig. 8.3, DACD1 includes entries from the contained (subordinate) inner area.
Note. Whilst it would be syntactically possible to include part of another access control area in an access control  domain, for example, where an ACSA has another ACSA below it in the DIT, but the access control domain specification in the higher ACSA omitted to include a chop specification that cut off the lower ACSA; in practice it would have no effect since the retrieval of the access control lists in the lower ACSA would never locate the access control lists held in the DACD of the higher ACSA (§ 8.2.2).

Of course, a given access control domain can often be defined in more than one way, since it may be defined by different administrators. Take for example DACD2 in Fig. 8.3. In the diagram this has been defined in a subentry below an access control inner administrative point, and so may have been defined by the administrator of that organisational unit. DACD2 could also have been defined in a subentry below the access control specific administrative point (as a sister to the DACD1 and DACD3 subentries), and in this case it might have been defined by the administrator of the organisation. In both cases the access control policy would apply to the same set of entries, it would just have been a different administrator who created the policy. Technically the difference between the two definitions would be in the base component of the subtree specification, since the base component always references the start of the DACD in relative terms from its immediately superior administrative point.

Access control policies that govern all the entries in an access control domain, are stored along with the subtree specification in the subentry. They are stored as PrescriptiveACI operational attributes (§ 8.3). In this way it is possible to have blanket access controls that apply to large portions of the DIT, in accordance with the local security policy.

Fig. 8.3 Directory Access Control Domains.

8.2.2 Determining which Access Control Lists Apply to an Entry

The access control lists that actually apply to an entry are derived from the access control lists that are stored within the entry (as EntryACI attributes, see below), plus the PrescriptiveACI attributes from all the enclosing access control domains. In order to locate the latter, the DSA software must logically traverse up the DIT from the entry towards the root, searching for inner and specific administrative points which have an 'administrative role' attribute value of 'access control inner area' or 'access control specific area' respectively, and stopping when the first specific administrative point is encountered. Each access control subentry below these administrative points is then checked to see if the entry is included within scope of the subtree specification. So by reference to Fig. 8.3, it can be seen that the access control lists which govern the striped entry, will be the entry's ACI, plus the PrescriptiveACI from domains DACD1 and DACD2.

8.3 THE ACCESS CONTROL ATTRIBUTES

Access control lists are held in Directory operational attributes. There are in fact three types of access control attribute defined in the Standard. EntryACI Directory operational attributes are access control attributes that control access to the single entries in which they are held. Any type of entry can hold an EntryACI attribute e.g. alias, subentry, administrative entry. EntryACI attributes are used to protect the attributes in the entry. They protect both user and operational attributes that are stored in the entry. They can thus be used to protect themselves (although this is not recommended) and this is described more fully in § 8.8. When held in an entry, an EntryACI attribute can even be used to allow or to stop people accessing collective attributes that appear to be held in the entry (even though the collective attributes are actually held in a subentry of the enclosing collective attribute administrative area). When EntryACI are held in subentries, they control access to the other attributes held in the subentry, such as collective attributes, PrescriptiveACI and subtree specifications.

PrescriptiveACI attributes are Directory operational attributes that can only be held in subentries. They control access to the entries (and their attributes) that are within the scope of the subtree specification of the subentry i.e. the access control domain. They thus hold the access control policies that apply to the domain. PrescriptiveACI do not protect the attributes held in the subentry itself. EntryACI or SubentryACI have to be used for this. (Protecting the PrescriptiveACI attributes is described more fully in § 8.8.)

PrescriptiveACI attributes are administered in just the same way that collective attributes are administered (§ 2.11.1). When a subentry is both a collective attribute and an access control subentry, i.e. the subentry contains both collective attributes and PrescriptiveACI, then the PrescriptiveACI attribute can be used to govern read type accesses to the collective attributes throughout the entire area defined by the subtree specification.

SubentryACI attributes are Directory operational attributes that can only be held in administrative entries. They control access to the subentries immediately below the administrative entry in which they reside. (They actually control access to the subentries and to the operational and user attributes held in the subentries.) SubentryACI can thus be used to protect PrescriptiveACI, and this is described more fully in § 8.8. They can also be used to protect collective attributes from being modified, since collective attributes are only actually held in subentries. (Note that they cannot protect collective attributes from being read in the entries that are within the scope of the subtree specification. EntryACI or PrescriptiveACI have to be used for this.)

8.4 THE SPECIFICATION OF THE ACCESS CONTROL LISTS

The access control lists are held in the three types of operational attribute, as described above. All of the attributes are multi-valued, and each attribute value is a simple access control list. A simple access control list basically comprises a list of information to be protected, a set of users and a set of permissions that are to be given to the users. There are thus several different ways of specifying the same set of access controls. Consider for example, an access control list that references a set of attributes in an entry, and which gives a list of users the same set of access rights to these attributes, e.g. Bill, Fred and Hanna have Read, Modify and Browse permissions to the telephone number, fax number and common name attributes. This can be stored in an EntryACI attribute in three different ways, either as: Formally, the standard calls the operational attributes access control information operational attributes, or ACI operational attributes for short, and the attribute values, ACI items instead of access control lists.

An ACI item is syntactically quite complex and consists of:

The ability to group ACI items by user, or by data item, is purely for the convenience of the administrator, and neither mechanism is favoured. However, it must be remembered that the administrator will only actually have access to the grouping mechanism provided by the implementation's user interface and so it is the implementor who must ultimately decide.

8.4.1 The Protected Items

The scheme allows all the information stored in the Directory to be protected against unauthorised use. The scheme therefore covers information from the smallest granularity to the largest. The scheme has as its model the object oriented concept of encapsulation i.e. an entry encapsulates its attributes, and an attribute encapsulates its values. Therefore, in order to access an attribute value, you must first gain access to the entry, then to the attribute (type) and finally to the specific value. However, this approach has led to strange consequences and an inconsistency (w/w 8.2). It will be a function of the access control interface to shield the user/administrator from this anomaly. The protected items have been specified with this model in mind, and the complete list, as specified in the Standard, is shown in Table 8.1. Typical Directory operations access many protected items, and so several protected items will usually need to be included in an ACI item, in order for one Directory operation to succeed for a given user. (Table 8.4 lists which protected items are accessed for each Directory operation.)

Table 8.1 The Protected Items
Protected Item How it is specified in ASN.1 
Attribute Value  As a list of attribute values 
Self Value As a list of attribute types 
All Attribute Values  As a list of attribute types 
Attribute Type  As a list of attribute types 
All User Attribute Types NULL 
All User Attribute Types and Values NULL 
Entry NULL
In the text below, the bold item in parentheses is the ASN.1 value reference for the protected item as it appears in the Standard.

The smallest component of information held in the Directory is an attribute value, and users can be allowed or forbidden to access one or more particular attribute values (attributeValue). Taken to the extreme, each attribute value in the Directory could be protected against different types of access by different users. However, the degree of control will normally want to be much broader than this, and so protected items may be grouped together as described below.

Some multi-valued attributes, such as those which hold mailing lists (i.e. the member attribute type), have values which are distinguished names. In order to let members of the group update their own values in the list, the protected item self value (selfValue) is defined. Self value allows a user to access only that attribute value which matches her (authenticated) distinguished name. In this way, an Add permission for a self value item, would allow users to add their names to a mailing list, and a Remove permission would allow users to remove their names from the mailing list.

Attribute values can be grouped together for protection purposes so that a user can be given permission to access all the values (allAttributeValues) in one or more attributes. With this protected item it is not necessary to enumerate the values. If it was wished to allow a user to read all the values of an attribute except one, then the access controls would need to be set up to grant the user read access to all attribute values, and to deny read access to the one specific attribute value. (One of the guiding principles is that specific grants or denials override generic ones at the same precedence level; see § 8.1.1 and § 8.9.)

Next we have the attribute type (attributeType) protected item. Attribute types, excluding any of their values, are access controllable. If access is not allowed to an attribute type, then the attribute values are usually also not accessible to that user. If access is allowed to an attribute type, then the user may be allowed access to the (enclosed) values. The exception to this is the Remove permission, where remove access to the values is not needed in order to be able to remove the attribute type (and all its values). Conversely, Remove permission to the attribute type is not needed in order to be able to remove a single value.

At the next level of granularity are all the user attributes in an entry (allUserAttributeTypes and allUserAttributeTypesAndValues). User attributes may be collectively grouped together as one item, for protection purposes, because as a general rule it is only user attributes that are visible to users of the Directory. Access may be offered to just the types, or to the types and their values. Operational attributes are not grouped together, or grouped with user attributes, because generally these will only be accessed by special users of the Directory, such as administrators. Operational attributes must all be individually granted access by explicitly naming them, either by type or value or both.

Finally, entries may be protected as a whole (entry). For most operations, a user must have access to the entry before he can gain access to its attributes. Without permission to access the entry, operation evaluation cannot usually proceed. (The only exceptions to this are the List and Search operations, since the entry whose subordinates are to be listed or searched, need not itself be accessed.)

Inclusion of any of the above protected items in an EntryACI attribute, will protect the items in that entry only. They will not affect any other entry in the DIT.

Groups of entries are not protected explicitly as a protected item. In order to protect a collection of entries, an access control domain is created as described in § 8.2.1. If a PrescriptiveACI attribute value is added to the subentry, with a protected item of entry, this will grant or deny permission to access all of the entries in the domain. Another PrescriptiveACI attribute value with a protected item of, say, attribute type will protect all the attributes of that type in all the entries of the domain.

Finally, we need to consider protecting the distinguished names of the entries in the DIT, since users can be forbidden access to these. This latter mechanism protects unauthorised users from seeing the structure of the DIT. Protection of distinguished names is mechanistically dealt with in a different manner from protection of the other information in the Directory, and so is not directly listed as a protected item. See § 8.6 for more details.

8.4.2 The User Classes

A comprehensive scheme for identifying the users to whom access is being given or denied, is provided in the Standard. Table 8.2 lists the user classes defined in the Standard.

Table 8.2 The User Classes
User Class Meaning 
Name  The distinguished name of a user 
This Entry The user whose name matches that of the entry being accessed 
User Group The distinguished name of a 'Group of Names' entry 
Subtree  The distinguished name of a (non-leaf) node in the DIT plus optionally a Chop specification 
All Users Public access
In the text below, the bold item in parentheses is the ASN.1 value reference for the user class, as it appears in the Standard.

The most obvious use of an access control list is to specify a single user, via his distinguished name (name). In this way individual users of the Directory, be they people or applications, can be given or denied specific access rights to specific protected items. A fine degree of control can then be exercised.

However, in many cases, such fine tuning is not really necessary. A coarser granularity of control can be exercised via the mechanisms defined in the Standard for specifying sets of users. One way is to specify a non-leaf node in the DIT (subtree), and to allow all names that start with this prefix to be controlled by this access control item. This would be particularly useful for say, allowing all the employees of an organisation, or of a department, to have access to some protected item. In this case, the distinguished name of the organisation, or of the organisational unit, respectively, would be quoted as the subtree. The subtree user class is actually more complex than this, in that it allows any subtree of the DIT to be specified, so that only a subset of the names below a non-leaf node are included. This is achieved by having a chop specification (§ 2.12.1) built into the subtree definition, the purpose of which is to chop off (exclude) identifiable subtrees below the one in question. Names residing in the chopped portion of the subtree are then excluded from the set of names. This would be useful for say, including all the employees of an organisation, but excluding the sales and marketing staff. In this case, the distinguished name of the organisation would be given as the subtree, with the sales and marketing organisational unit being included in the chop specification.

An alternative way of specifying a group of users (userGroup), is by quoting the distinguished name of an entry in the DIT, which contains a list of distinguished names e.g. a mailing list entry. The entry has to be an instance of the GroupOfNames (or similar) object class, and the list of distinguished names is held in the member attribute of the entry. An example of this would be a mailing list (but not unfortunately a MHS distribution list, since this does not have a member attribute - see w/w 10.3). The distinguished names contained in the member attribute are usually unrelated to each other with respect to the DIT, and are unrelated to the name of the entry. Thus it is not possible to know if a user's name is present in a GroupOfNames entry, without having full access to the entry. The Standard thus cautions against the use of the userGroup user class if the DSA doesn't have local access to the GroupOfNames entry. Without local access to the entry, a DSA has to assume, when evaluating the access rights of a user, that he is not present in the group, if access is being granted to the group, and that he is present in the group, if access is being denied to the group. Of course, a DSA may always be implemented to either shadow a remote GroupOfNames entry, and thus keep a local copy of it, or to invoke a Compare operation to check on the presence of a user in a remote group. But beware, there are implications in terms of currency of information or of performance with either of these solutions.

The widest group of users that may be given access to the Directory is the set of all users (allUsers). This is used in granting or denying public access to pieces of information. This user class may often be used with such attributes as the telephone number of the organisation.

Finally, we have an access control user class that is used to give the owner of an entry access to some or all of it (thisEntry). The semantics of this user class is that the authenticated name of the user (after any local mapping) must be the same as the distinguished name of the entry that she is trying to access. This user class is particularly useful when specified in a PrescriptiveACI that covers a portion of the DIT. It allows all the users within an access control domain to access their own entry only.

Re-use of Distinguished Names

The user classes above were described in terms of distinguished names. But what happens if an employee leaves an organisation, and sometime later another employee, who has the same name as the previous one, starts to work for the organisation? They could both have been given the same distinguished name, although there would have been an intervening time when the distinguished name was not in use. However, there might be some access control information in the Directory that is still present from the time of the previous employee, that would now be inherited by the new employee. Clearly the new employee was not the intended beneficiary of the old access controls. The work on access controls has recognised that distinguished names might be re-used by Directory administrators, that old ACI items may not be purged immediately, and that this is a potential security loophole. Consequently, in most places where distinguished name can occur in an access control list, this has been supplemented with an optional additional component, UniqueIdentifier. This allows distinguished names to be uniquely tagged, so that if re-used, different tags can be allocated each time. In this way, a re-use of a distinguished name will not inherit access controls left over from a previous use of the name.

The unique identifier is allocated by the home DSA when the user's entry is first created. When the user subsequently Binds to the home DSA, the DSA looks up the unique identifier and attaches it to the distinguished name, so that the user supposedly doesn't need to know about it. It is not known at the time of writing whether implementors or administrators will use this feature or not. If they do the full implications of using unique identifiers will have to be developed, probably by the functional standards groups, by supplementing the information available in the '93 Standard.

8.4.3 The Permissions

The access rights given or denied to a user for a specific piece of information are called the permissions, and the permissions may be granted or denied. In the absence of any permissions relating to a specific user's access to some Directory information, access is always denied. The access control scheme thus operates on the principle of least privilege i.e. a user has to be explicitly granted permission in order for an access to succeed. This helps to ensure that users do not obtain information from the Directory, due to an oversight or an omission by an administrator.

Table 8.3 The permissions, and the Items that they can protect
Permissions for Entry Protected Items only  Permissions for all Protected Items except Entry  Permissions for all Protected Items 
Browse  Compare Add 
Export  FilterMatch  DiscloseOnError
Import  Read 
Modify  Remove 
Rename
ReturnDN
There are a large number of permissions defined in the Standard, and these all relate in one way or another to the operations that a user can perform on the Directory. However, it should be remembered that, in order for the Directory to successfully perform an operation on behalf of a user, the user will normally need a number of these permissions, each permission allowing the Directory to access just some of the information needed to perform a part of the overall operation. If a permission is absent or denied at any stage during this processing, the operation is likely to either fail in some way, or omit some of the available information from the reply sent to the user. It will therefore be a significant feature of the administrator interface to ensure that necessary permissions are not accidentally omitted by the administrator. For example, the interface could operate at the Directory Operations level and automatically set all of the permissions that are needed for each operation (Read, List, etc.).

The set of permissions needed to perform each Directory operation is given in Table 8.4. The complete set of permissions are listed in Table 8.3, together with the protected items to which they can be applied e.g. Export permission cannot be granted to an attribute type, only to an entry. A full description of the actual permissions required for each operation will be dealt with operation by operation in § 8.5.

Table 8.4 The permissions that are needed for each Directory operation
Directory Operation Permissions Required for 'Entry' Protected Item  Permissions Required for Attribute Type and Attribute Value Protected Items 
Compare Read  Compare for attribute type 

Compare for each attribute value being compared 
Read Read 

 ReturnDN (only if an alias name is not available) 

 Read for each attribute type returned 

 Read for each attribute value returned 
List Browse and ReturnDN for each subordinate  None
Search  Browse for each entry in scope of Search 

ReturnDN for each entry (only if an alias name is not available) 

 FilterMatch for each attribute type and value used to evaluate the filter 

 Read for each attribute type returned 

 Read for each attribute value returned 
AddEntry Add  Add for each attribute type 

 Add for each attribute value 
RemoveEntry Remove  None 
ModifyEntry Modify  Add for all attribute types added 

Add for all attribute values added 

Remove for all attribute types removed 

Remove for all attribute values removed 
ModifyDN  Rename if operation only modifies RDN else 

Export at old name and Import at new name 

 None
The meanings of most of the permissions are intuitive. Read, Compare, Add, Remove, Rename, and Modify have their usual English meanings. Export and Import are needed to move an entry, via the ModifyDN operation. Browse is needed for List and Search, when browsing through the DIT. ReturnDN permission is needed if an interrogation operation is to return the distinguished name of the entry. FilterMatch is needed for attributes that occur in the filter argument of a Search operation, and DiscloseOnError will tell the user that the protected item exists, even if she does not have the right to access it.

Fig. 8.4 The Guiding Principle for responses given by the Directory to a user with and without permission to access some information.