Starting with 6.x, Directory Server includes two major changes to ACI scope.
Ability to specify the scope of an ACI. In Directory Server 5.2, you could not specify the scope of an ACI. ACIs automatically applied to the entry that contained the ACI and all of its subtree. Therefore, it was necessary to use deny ACIs in several cases. Deny ACIs can be difficult to manage, particularly when a deny ACI and an allow ACI apply to a single entry.
Starting with Directory Server 6.x, you can specify the scope of an ACI, that is, you can use allow ACIs to control access. Although, deny-based access control might sometimes be unavoidable or simpler to configure, the use of deny ACIs is generally discouraged. For information about how to specify the scope of an ACI, see Chapter 6, Directory Server Access Control, in Sun Directory Server Enterprise Edition 7.0 Administration Guide.
Root ACIs now apply to the root entry and its entire subtree. In Directory Server 5.2, ACIs located in the root DSE applied to the root entry only and not its children. ACIs placed in any other entry applied to the entry that contained the ACI and all of its subtree. In Directory Server Enterprise Edition ACIs placed in the root entry are treated like ACIs placed anywhere else.
The new root ACIs have an obvious security advantage. Administrators no longer have to bind as the Directory Manager to perform certain operations. Administrators can now be forced to bind by using strong authentication such as SSL. When configuring ACIs that are intended to apply only to the root entry, the scope of the ACI must now specifically be set to base.
The change in ACI scope has implications for migration. If you are migrating to Directory Server 7.0 from a 5.2 version of Directory Server, see Changes to ACIs in Sun Directory Server Enterprise Edition 7.0 Upgrade and Migration Guide.