Solaris ISP Server 2.0 Administration Guide

Chapter 3 Using Directory Services

Solaris ISP Server^TM uses Sun^TM Directory Services to store subscriber data, store component software information, and login information for Sun^TM Internet Administrator^TM and for some services. This information includes standard object classes and newly-defined objects that support Solaris ISP Server functionality.

This chapter describes the Solaris ISP Server information tree structure, explains how to support multiple domains in the directory, and describes the directory access controls. For information on the schema extension itself, see Chapter 6, Solaris ISP Server Directory Schema.

Specific topics in this chapter include:

Sun Directory Services Administration Tools

Sun Directory Services provides the following tools for using and administering the directory:

The Deja tool, a Java-based directory editor, provides add, modify, and delete capability.
The Sun Directory Services administration console offers local and remote administration of the server.
The Web gateway allows browse access from any browser.
A complete set of command-line programs.

The Sun Directory Services books, Sun Directory Services 3.1 Administration Guide and Sun Directory Services 3.1 User's Guide, include complete information on starting and using these tools. They are provided in AnswerBook2 format on the product CD-ROM. The command-line programs are documented in man pages in section 1 (/opt/SUNWconn/man).

Solaris ISP Server Directory Structure

Solaris ISP Server requires a specific structure in the directory information tree (DIT), which is created during installation and configuration. Solaris ISP Server host configuration creates two naming contexts, referred to as the Open Systems Interconnection (OSI) tree and the domain component (DC) tree.

Each naming context is defined according to the data you provide during installation. Initially, two naming contexts are created. The OSI naming context is created directly from the distinguished name you provide (for example, o=sun,c=us). If you entered sun.com as your domain, the DC naming context is defined as dc=com, and an entry is made beneath that for dc=sun. The host configuration process also creates the requisite entries.

Portions of the two trees are parallel. This parallel structure facilitates mapping of domain names from a DNS request through the DC tree to the actual content entries in the OSI tree.

OSI Tree Structure

The OSI tree contains the actual entries for Solaris ISP Server, its component services, administrators of those services, and subscribers to the services. The required structure is shown in Figure 3-1.

Figure 3-1 Solaris ISP Server OSI Tree

In the OSI tree, the domain sun.com is represented by the entry with the distinguished name o=sun,c=us. This entry is called the root entry (sometimes the root domain) of the naming context, and represents the Solaris ISP Server customer's business. You specify the root entry during installation of the directory services.

Beneath the root entry are four required organizationalUnit entries:

Administrators contains entries for Sun^TM Internet Administrator^TM administrators. These entries are created by the product when you create administrators using the GUI.
People contains entries for subscribers to ISP services. You create entries for your customers, whether at the command line or by using the Deja tool.
Groups contains entries that group subscriber entries together for access control purposes. You create group entries according to your needs, whether at the command line or by using the Deja tool.
Services contains entries created for Solaris ISP Server services. You should make entries under this node only when you are integrating a new service.

People, Groups, and Services nodes are required under each domain entry you define. The Administrators node exists only under the root entry.

Figure 3-2 shows a typical set of entries under each organizational unit.

Figure 3-2 OSI Tree Entries

The organizationalUnit entry eng is an example of a domain entry. This might be a corporate customer of the ISP, or anyone who has virtual domain hosting services with the ISP. Domains must have two entries: one here in the OSI tree and another in the DC tree for domain name mapping. See "Creating Domain Entries" for information on creating these two entries properly.

Domains, like the root entry, require certain organizationalUnit entries within them. As shown in Figure 3-3, People, Groups, and Services entries are also required in a domain below the root.

Figure 3-3 Domain Structure in the OSI Tree

When creating a domain entry in the OSI tree, you must also create the entries for People, Groups, and Services. When you configure services for this domain, service entries are made under the Services organizational unit. Subscriber information for this domain forms ispSubscriber entries under the People organization unit.

Note -

Administrator entries exist only under the root entry in this version of Solaris ISP Server. These entries are created by Sun Internet Administrator when you specify them through the GUI.

DC Tree Structure

The DC (domain component) tree maps domain name format (for example, sun.com) to the distinguished name of the corresponding entry in the OSI tree. As shown in Figure 3-4, the DC tree is usually relatively flat and simpler than the OSI tree.

Figure 3-4 Solaris ISP Server DC Tree

In Figure 3-4, the entry dc=sun,dc=com maps to the o=sun,c=us entry in the OSI tree. The eng domain here maps to the domain name system (DNS) form eng.sun.com.

For details on how to make the two domain entries, see "Creating Domain Entries".

Supporting Multiple Independent Domains

The DC tree in "DC Tree Structure" shows an entry for the domain eng.sun.com. Domains that use that same name structure (.com) can be added as siblings to sun. But ISPs may support many independent top-level domains.. Supporting a new independent domain, such as .net, requires adding a new naming context.

To accomplish this, add a new DC tree and make the domain entry under it --in addition to the OSI tree entries and the DNS configuration that are necessary for any domain. To add a new DC tree to the default configuration, follow the steps in "Adding a DC Tree".

Adding a DC Tree

You can add a new independent domain to the directory by adding a new DC tree.

Access the Sun Directory Services administration tool, either by launching it from Sun^TM Internet Administrator^TM or by entering the following:
% su password: # /opt/SUNWconn/sbin/dsadmintool

In the Data Store list, select the data store to which you are adding the naming context.

Note -
In the default Solaris ISP Server configuration, there is only one data store.

Choose Modify Data Store from the Selected menu.

Click More Suffixes.

Note -
More Suffixes is to the right of the Data Store Suffix field. You may have to scroll to see it.

In the Additional Suffix box, enter the distinguished name of the new naming context. For example, if you are adding a context for .net, enter the DN dc=net.

Choose Naming Context from the Create menu.

Select a Type of Subtree.

Select a Mode of Master.

In the Suffix field, enter the distinguished name of the new naming context. For example, if you are adding a context for .net, enter the DN dc=net.

Click OK to save the naming context information. The new naming context is displayed in the Naming Contexts section.

Click OK in the Create Data Store window to save the data store definition.

A dialog appears, asking "Do you really want to apply the modifications?" Click OK. If the dialog does not appear, the changes will not take effect and your new DC tree will not be available.

Click Apply in the main administration tool window.

A dialog appears, asking if you want to restart the directory server and make the new configuration take effect. Click Yes. If the dialog does not appear, the changes have not been saved.

Add the root entry for the naming context, using either Deja or ldapadd(1M). For example, if you specified dc=net, create an entry with that distinguished name. You cannot add any entries to this data store until this root entry exists.

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.

Note -

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.