Directory Services Access Control

Solaris ISP Server sets access control for the directory services, to ensure proper access by parts of the software that need it while assuring security by preventing access by others. The general principal of these access controls is that most entities have read access while write access is restricted. It is very important that you do not change existing access controls, or you may introduce security risks or cause Solaris ISP Server to fail.

Remember that the access control rules are order sensitive. When Sun Directory Services checks for access, the first rule that applies to the request is used. Any remaining rules are ignored. Therefore, do not change the order of the rules in the file. When creating a new rule, be careful that it does not accidentally apply to existing Solaris ISP Server information and invalidate some access control rule already in place.

Access control checking is switched off if you bind to the directory as its administrator.

Generally, the information special to Solaris ISP Server is stored in entries supporting object classes defined in the Solaris ISP Server schema extension. Each of these classes is named beginning with the string "isp." Any rule in the access configuration file that contains such an object class (or attribute) is likely a Solaris ISP Server rule and, as such, sensitive to any changes. The access control rules are defined in /etc/opt/SUNWconn/ldap/current/dsserv.acl.conf.

For complete information on Sun Directory Services access controls, see Chapter 1, "Introduction to Directory Concepts," and Chapter 4, "Configuring a Directory Server," of the Sun Directory Services 3.1 Administration Guide.

The sections that follow describe the general behavior ensured by the Solaris ISP Server access controls. The phrase "has access" indicates that binding to the directory with that entry's DN and password will give the indicated form of access.

Rules Enabling Sun Internet Administrator Functionality

Sun Internet Administrator needs the following kinds of access to do its work:

• It needs to create and delete administrator information. Therefore, Sun Internet Administrator has write access to the portion of the DIT defined by the Administrators organizational unit entry.

• It must be able to change certain administrator attributes (notably the userPassword and ispAuthorizedService attributes).

• It must be able to control the creation of managed service entries (ispManagedService). Therefore, Sun Internet Administrator owns its own portion of the tree, below the top-level SUNWixamc entry (for example, ispVersion=1.0,ou=SUNWixamc,ou=Services,o=sun,c=us).

• It needs to create the top-level service entries for services it registers and manages. Therefore, Sun Internet Administrator has the access and information it needs to write to that portion of the DIT (for example, ou=Services,o=sun,c=us).

• It also needs to set the value of the protected ispPrivateData attribute on ispService entries. Therefore, Sun Internet Administrator has read/write access to that attribute of existing service entries. (In fact, no other entity has any access to the ispPrivateData attribute.)

Rules Enabling Service Functionality

The various Solaris ISP Server services need to record and access configuration information stored under their service entries (those located under the Services node in subdomains and virtual domains). Therefore, each has the access and information it needs to create and modify entries in that portion of the DIT, including its own service entry.

Rules Enabling Proper User Access

Users (subscribers and administrators) have write access to their password attribute, but cannot change other parts of their entry. However, any administrator with management access to Sun Internet Administrator has global access and can change anything.