Solaris ISP Server 2.0 Administration Guide

Adding More Top-level Domains

The DC tree is configured with dc=com as the naming context, making .com the (only) top-level domain. You may need to add other naming contexts to support virtual hosts that are not in the .com domain.

The following procedure documents how to use the Sun Directory Services dsadmintool administration console to create an additional DC tree for the .net domain. The same procedure, of course, applies to any top-level domain.

The Sun Directory Services software supports up to four naming contexts in a data store, or three DC tree naming contexts and the OSI tree. If your ISP requires more than three top-level domain naming contexts, see the procedure "To Create an Additional Data Store" below.

To Add a DC Tree for Another Domain

Run /opt/SUNWconn/sbin/dsadmintool.

dsadmintool is an X application. Make sure your DISPLAY environment variable is properly set if you are not at the console.

Click Data Store in the Sections list to display the Data Store section.

Click the Datastore folder in the Data Store section to select it.

Choose Modify Data Store from the Selected menu.

The Modify Data Store dialog is displayed.

Click the More Suffixes button.

A new Additional Suffix text field displays at the end of the list.

Type "dc=" and the name of the top-level domain you want into the Additional Suffix field.

For example, to add a DC tree for the .net domain, enter dc=net.

Click OK to apply the change and close the Modify Data Store dialog.

In the Sun Directory Services administration console window, click Apply to save the changes to the Data Store and restart the server.

A dialog will prompt you to ask if you want to restart the server. The new naming context will not be available until the server has been restarted. The remaining steps assume that you have restarted the server so that an entry can be added to the new naming context.

Create an ldif file with a domain entry for the root of the new naming context.

For example:
```
dn: dc=net
objectClass: domain
objectClass: top
dc: net
```

Run ldapadd to add the entry to the directory.

For example:

% cd /opt/SUNWconn/bin
% ./ldapadd -D cn=admin,o=MyISP,c=US -w secret -f /tmp/net.ldif

To Create an Additional Data Store

Use this procedure if you require more than three top-level domains. This procedure shows you how to create an additional data store so that you can have more than four naming contexts. The new data store is created in the same database directory as the original store, but you are not required to keep them in the same location.

Additional data stores will use a different rootdn entity. When you bind to the directory you will need to bind as the rootdn appropriate to the data store. To avoid this and have a single identity that can be used to bind and make changes in any data store, create a record in the directory representing an administrative user and give that user permission to make changes in any data store. The next procedure, "To Create a Directory Administrator" explains how to create this user and configure permissions.

Refer to Sun Directory Services 3.1 Administration Guide for complete details on creating data stores.

Run /opt/SUNWconn/sbin/dsadmintool.

dsadmintool is an X application. Make sure your DISPLAY environment variable is properly set if you are not at the console.

Click Data Store in the Create menu to display the Create Data Store dialog.

Enter a suffix for at least one naming context in this data store in the Datastore Suffix field.

For example, dc=uk.

If you want to add more that one suffix, click the More Suffixes button.

Enter a path where the data will be stored in the DB Directory field.

The original data store is located in /var/opt/SUNWconn/ldap/dbm by default. You may also want to store additional data stores in /var/opt/SUNWconn/ldap.

You may want to change some of the other settings.

The following are the default settings for the original Solaris ISP Server data store:

Read-only Datastore

off

Last-modification attributes

on

Cache size (entries)

5000

Cache size (bytes)

100000

Congestion Limits: critical

200

Congestion Limits: congested

500

Congestion Limits: back to normal

1000

Click OK to save your changes and create the data store.

The data store should now appear in the Data Store list in the dsadmintool Properties page.

Click Apply in the dsadmintool console window to apply your changes to the configuration.

Stop and restart the LDAP service using dsadmintool or /etc/init.d/dsserv.

Now add a record representing the root node in the naming context of the new data store.

The following example ldif record could be used with ldapadd to create a record for dc=uk:
```
dn: dc=uk
objectClass: domain
objectClass: top
dc: uk
```
To add this record to the new data store, you will have to bind as the rootdn of the new data store. The new rootdn uses the original rootdn common name, but with the new naming context. For example, if the cn of the original rootdn is admin, then to add the above record to our new data store with the dc=uk naming context:
# cd /opt/SUNWconn/bin # ./ldapadd -D cn=admin,dc=uk -w secret -f /tmp/net.ldif
You should create a single administrator record that can be used to bind to all of your data stores to avoid having to bind with different credentials to each data store. See the next procedure, "To Create a Directory Administrator" for more information.

Note -
Even if you create an administrative user entry, the first record in any new data store must be created by the rootdn defined for that data store. So you must add the root record for the data store's naming context by binding as the data store rootdn. Subsequent records may be added by any dn with appropriate write privileges.

To Create a Directory Administrator

This procedure explains how to create a record representing an administrator that can bind to any data store an make modifications. You will create a record in the original data store, then add permissions to the access control list (ACL) file to grant this user permission to modify all entries.

This procedure uses an example of creating a record with the distinguished name "cn=admin,o=myISP,c=US" and a password of "secret." Note that the common name and distinguished name you choose can be identical to the common name and distinguished name of the actual rootdn in your data store.

Create an entry in one of your naming contexts for the user that will act as the administrator.

You should place the entry in your original OSI tree; for example, a user whose distinguished name is cn=admin,o=myISP,c=US.

The object class can be any object class that accommodates a password attribute. Using the top and person object classes is sufficient, but you may want to use other object classes (such as organizationalPerson) if you want to store more information in the record's attributes.

The following ldif file is sufficient to create an administrative user:
```
dn: cn=admin,o=myISP,c=US
objectClass: top
objectClass: person
cn: admin
sn: admin
userpassword: secret
description: rootdn record
```
You can create the record using ldapadd or the Deja tool.

Edit the access control lists (ACLs) for the directory service using either dsadmintool or by editing the dsserv.acl.conf file.

The configuration file is located in /etc/opt/SUNWconn/ldap/current by default.

Add an ACL to allow only the administrative user to modify its own record.

For entries that match the dn of the administrative user that you just created, allow "self" write access and everyone (*) no access.

In the dsserv.acl.conf file, the following entry would allow only the user we created above to modify its own record:
```
access to dn="cn=admin,o=myISP,c=us" 
     by self write
     by * none
```
The ACLs are applied in the order in which they appear in the file, so make this the first entry in the file.

Add an ACL that allows the administrative user to modify all records in all naming contexts.

This ACL should use a dn pattern to match any distinguished name and explicitly allow write access to the administrative user. Use ".*=.*" as the dn pattern to match any dn. Be sure to place this entry at or near the top of the ACLs list so that it is matched before any other entries that might block access.

In the dsserv.acl.conf file, the following entry would grant the user we created above permission to modify any record:
```
access to dn=".*=.*" 
     by dn="cn=admin,o=myISP,c=us" write
```

Stop and restart the LDAP service using dsadmintool or /etc/init.d/dsserv.