Sun ONE and Netscape Directory Server Access Control Overview

When LDAP was first developed, it was only a protocol for accessing data in an X500 directory server. Therefore, many specifics of how the server itself was supposed to work were left out. Even when the new standard was written for LDAP version 3 (RFC2251), some important issues were left out simply because the people involved had already picked an implementation, and didn't want a new standard to force them to redesign and reimplement large portions of their servers. Access control was one of those important issues. That is why when discussing access control, it is important to remember that each vendor has a different mechanism, and very little is portable from one server to another.

Access control starts with authentication. There are several mechanisms to accomplish the authentication, but all must eventually resolve to a distinguished name (DN) that exists in the directory. This distinguished name is then used to determine the access that is granted to a user. The process of associating a distinguished name with a user is called binding. A user can bind to a server using the DN and a password, or they can bind anonymously, providing no credentials.

Authentication is accomplished using access control information (ACI) rules. An ACI rule specifies the LDAP object to which the rule applies, whether the rule allows the specified permission or denies it, the users who are permitted or denied access, and what type of permission is being allowed or denied. For information on using the Integration Technologies Administrator to specify ACI rules, see Setting Access Permissions for an Object and Specifying Bind Rules.

The Sun ONE and Netscape mechanism for administering access controls is flexible and powerful, but can also be complex. Some basics may make things clearer.

• By default, no access is allowed to the directory except to the directory manager. The directory manager bypasses all access control checks, and is used to administer the directory. A new directory with no access control information is unreadable by any user except the directory manager. This type of control is different from an explicit deny, which will be discussed later in this document.
• All access control information propagates down from its target to all the children under that target.
• All access control is cumulative.
• You cannot limit the scope of access control information.
• If conflicting access control information exists, deny always overrides allow. In other words, if there are access control lists that allow a user access, and another access control instruction that denies access, the deny will always be preferred.

Sun ONE and Netscape Syntax

(target="ldap:///dn")(targetattr="attrname")
   [(targetfilter="rfc2254-style filter")]
   ( version 3.0; acl "name"; (allow | deny)
   (read, write, search, compare, selfwrite, add, delete )
   (userdn | groupdn)="ldap:///dn";)

Target

The target specifies the entry where ACI rule will be effective. Usually, the target is the same as the entry where the ACI attribute exists. In other words, if the ACI attribute is added to the entry with DN cn=SAS,o=SAS Institute,c=US, then the target will be ldap:///cn=SAS,o=SAS Institute,c=US. The target parameter can point at an entry which is a direct descendant, but that can become hard to manage. The parameter can also cause the server to process access control information that does not apply to the search it is carrying out.

Targetattr

Targetattr specifies one or more attributes that the access control information applies to. Access control rules can apply to specific attributes. This parameter provides more strict access to attributes such as userpassword.

Targetfilter

This is an optional parameter that can be used to apply to specific entries based on a filter. The filter has the same syntax as a filter provided to the ldapsearch command. This type of ACI rule is expensive to process and should be used sparingly.

Permissions

The permissions parameter consists of the version number (currently always 3.0), the ACI name, the operation (either allow or deny), the permissions and the subject to which to apply the rule (typically either a user or a group). Most ACI rules are written to allow permissions, because deny ACI rules can quickly become complex. The following permissions are supported:

Read

Allows data to be returned to the user

Search

Allows user operations to search the data

Compare

The user is allowed to use the data for filter comparisons

Write

The user may write to the data item

Add

The user may add the data item

Delete

The user may delete the data

Selfwrite

The user may write their own DN to the data item

Some of these permission make the most sense when they are applied to an attribute. For example, allowing selfwrite of the member attribute above the area where groups are stored will allow a user to add himself to or remove himself from a group.

The subject specification will normally be made using the userdn or groupdn keyword. The value will be an ldap URL with the distinguished name of the user or group. Wildcard characters can be used in the DN to specify more than one user. Also, there are two special strings: ldap:///all specifies all bound users, and ldap:///anyone specifies any users, including anonymous users. If the groupdn keyword is used, the DN points to a groupOfUniqueNames. If the DN of the bound user exists in the group as a uniqueMember attribute, the rule is applied.

There are two other subject specifications that are sometimes used: userdnattr and groupdnattr. These specify that an attribute on the entry will contain a DN, and if the DN matches the bound user, it will apply the rule.

ACI Rule Considerations

Since ACI rules are cumulative, it is important to be careful granting access at a node that has a deep tree under it. For example, if read access is granted to all users at the node cn=SAS,o=SAS Institute, c=US, then it becomes difficult to restrict that access further down, such as at the container where logins are stored. Therefore, it is important to look at the whole directory tree before deciding on an access policy.

From an efficiency point of view, the fewer access control instructions the better, as long as the data is secured in a meaningful way. Using groups is a good way to accomplish this, and make access control easier to manage at the same time. It is a lot easier to add or remove a user from a group than try to find all of the ACI rules that reference that user's DN, or figure out all of the different kinds of access a user requires.

Access Control Examples

ACI: (target="ldap:///o=SAS Institute,c=US")
  (targetattr=*)( version 3.0; acl
  " allow portal user"; allow (all)
  userdn="ldap:///cn=Portal User,ou=People,
  o=SAS Institute,c=US";)

This example allows the user with a DN of cn=Portal User,ou=People,o=SAS Institute,c=US all access to everything in the directory. This level of access is unusual, but acceptable for this example because the Portal User identity is used by an application that performs very specific operations in the directory.

ACI: (target="ldap:///o=SAS Institute,c=US")
   (targetattr=*)(targetfilter="(| (objectclass=sascontainer)
   (objectclass=sascomponentcontainer)) ")(version 3.0; acl
   "see sascontainers"; allow (compare, read, search)
   userdn="ldap:///all";)

This example is somewhat unusual, but it has a specific purpose. It allows all non-anonymous users to see sascontainers and sascomponentcontainers in order to facilitate browsing.

ACI: (target="ldap:///cn=sassubscribers,
   sascomponent=saspublishsubscribe,cn=sas,o=sas institute,
   c=us")(targetattr="*")(version 3.0; acl "owner has all
   rights"; allow (all) userdnattr = "saspersondn";)

This example is also unusual, because it uses the userdnattr specifier. This ACI rule grants all permissions to a user whose bind DN is found in the saspersondn attribute of an entry below cn=sassubscribers,sascomponent=saspublishsubscribe,cn=sas,o=sas institute,c=US. This is important to allow users to update their own subscriber entries.

ACI: (target="ldap:///saschannelcn=Orders for Manufacturing
    Materials,cn=saschannels,sascomponent=sasPublishSubscribe,
    cn=SAS,o=SAS Institute,c=us")(targetattr="*")(version 3.0;
    acl "allow valid users"; allow (compare,add,read,search)
    groupdn = "ldap:///cn=IDBGroup,ou=Groups,o=SAS Institute,
    c=US||ldap:///cn=Sales,ou=Groups,o=SAS Institute,c=US"; )

This example allows access to two groups: cn=IDBGroup,ou=Groups,o=SAS Institute,c=US and cn=Sales,ou=Groups,o=SAS Institute,c=US. The permissions allow read, search, compare, and add. The add permission is important because it allows members of these groups to create archive entries under the channel Orders for Manufacturing Materials. If the administrator wished, the add permission could have been moved down to the archivepath entry. This would have restricted who could publish archives to be stored under the channel.

SAS application requirements

There are several places in the SAS hierarchy that do not require any special access control. There are other places, however, that require careful thought when applying the ACI rule. The following are the places in the hierarchy that require special attention.

Cn=SAS

This is the top of the SAS application tree. If some accommodation for browsing is desired, a filtered ACI rule that allows reading sascontainer and sascomponentcontainer by all bound users can be placed here.

Cn=sasSubscribers,sascomponent=sasPublishSubscribe

No sensitive data is contained in this part of the tree, but an ACI rule that allows a user to update their own subscriber information is useful. Using the userdnattr on saspersondn allows this function.

Cn=saschannels,sascomponent=sasPublishSubscribe

The level of control you implement here depends on how you want to secure channels, archive paths and archives. The way publishing works, if a user can read a channel entry, they can publish TO_SUBSCRIBERS, which sends email to all of the users subscribed to a channel. This is allowed even if the publishing user is not subscribed to the channel and therefore cannot write to the channel. This situation can be covered by only allowing read access to specific groups. The other consideration is how archive paths are secured. Allowing add access to an archive path means a user can create archives under that path (assuming they have permission on the physical path). An ACI rule needs to be created to allow users to manage the archives they create, based on the saspublisher attribute. An ACI rule with a userdnattr=saspublisher that allows all is recommended.

Cn=sasArchivePaths,sascomponent=Archiving

This area has the same considerations as the channels. To define the ACI rule, you must decide how you want to protect the global archive paths.

Cn=saslogins,sascomponent=sasserver

This requires careful consideration, because the saslogins below this container contain user names and passwords. The sasreferencedn and sasallowedclientdn attributes contain the distinguished names of the user represented by this login, as well as the DNs of clients who are allowed to use the login. ACI rules should be written to allow read and write access based on these attributes. Using the userdnattr and groupdnattr is appropriate in this case. The groupdnattr is necessary because the sasreferencedn can refer to a group (for a group login).

Cn=sasStoredProcessPaths,sascomponent=sasApplications

It is likely that each storedprocesspath entry will have its own ACI rule set. This is because the stored processes will generate information that will be intended for a certain audience. The stored processes should be grouped under a sasstoredprocesspath according to the group that needs access to them.

Sascomponent=sasPortal

The SAS Information Delivery Portal Installation Guide contains guidelines for setting the access controls on portal entries.

Sascomponent=sasDataSources

This is another location that requires careful consideration. Libraries, tables, infomarts and other data sources may all have individual security requirements. The most important thing to remember is to not place access controls at the container level unless you want that access to apply to all of the entries below it.

Other locations

Other areas can be opened for read by any bound user, but you must make sure you do not put the ACI rule too far up in the tree. For instance, the container cn=sasservers,sascomponent=sasServer can be opened for read by all, but granting that access at sascomponent=sasServer gives access to logins.

Deny ACI Rules

Using deny ACI rules is a useful tool in certain situations, but it can be dangerous. If you want to limit access to a segment of the tree, when higher-level ACI rules have allowed access, you can use deny to accomplish that. Remember, though, that a deny cannot be undone. In other words, if you deny access at a directory entry to all users who are not in a specified group, you cannot then allow a user who is not in that group to access the directory at a lower level in the tree.

You must also remember that an explicit deny is not the same as an implicit allow. If you deny everyone except one group, it does not necessarily mean that everyone in that group is allowed. If no explicit allow was ever specified, the users in that group still do not have access. Deny ACI rules are usually most useful when used with a != operator on the subject, for example:

ACI: (target="ldap:///sasUniqueName=Security Group A -
     A000000E.WHSECGRP.A00001X7,cn=sasContentObjects,
     sasmetadatacn=A0000001.WHDW.A000000E,cn=sasMetadata
     Repositories,sascomponent=sasMetadataRepository,
     cn=sas,o=sas institute,c=us") (targetattr="*")
     (version 3.0; acl "Security Policy"; deny (all)
     groupdn != "ldap:///cn=Distributed Technologies,
	 ou=groups,o=SAS Institute,c=US||ldap:///cn=IDBGroup,
	 ou=groups,o=SAS Institute,c=US" ;)

This rule denies access to everything below this entry to everyone that is not a member of the IDBGroup group. The rule to remember is this: do not use deny unless there is no other way to accomplish what you need to do.