Sun Java System Delegated Administrator 6.4 Administration Guide

Post-Configuration Tasks

After you run the Delegated Administrator configuration program, you should perform the following tasks:

Perform the following task only if you are using an LDAP directory in Schema 2 compatibility mode:

Add Mail and Calendar Services to the Default Domain

The config-commda program creates a default domain.

If you want to create users with mail service or calendar service in the default domain, you first must add mail service and calendar service to the domain.

To perform this task, use the commadmin domain modify command with the -S mail and -S cal options.

The following example shows how you can use commadmin domain modify to add mail and calendar services to the default domain:

commadmin domain modify -D chris -w bolton -n sesta.com -d siroe.com
 -S mail,cal -H test.siroe.com

For commadmin command syntax and details, see Chapter 5, Command Line Utilities.

Enforce Unique Values for Mail Attributes

Messaging Server uses the following mail attributes to identify a user's email address and alternate email addresses:

Each user's mail attributes should be unique across the directory.

The following procedure shows how to modify a Directory Server ldif file to enforce the uniqueness of these attributes. Whenever Delegated Administrator (or any LDAP tool) adds an entry or modifies a mail attribute, the ldif plug-in checks that the mail attribute values are unique. If an operation would cause two entries to have the same mail-attribute values, it is terminated.

For definitions of the mail attributes, see Chapter 3, Messaging Server and Calendar Server Attributes, in Sun Java Communications Suite 5 Schema Reference.

ProcedureTo enforce the uniqueness of mail attributes

Before You Begin

Note –

If you are running Directory Server 5.2.5 (Java ES Release 4) or later, follow the procedures described below.

If you are running Directory Server 5.2.4 (Java ES Release 4), you need to apply patch 5.2_Patch_4_6313027 before you begin the following procedure.

If you are running an earlier version of Directory Server, you need to upgrade to Directory Server 5.2.5 or later before you begin.

To access Directory Server patches, go to http://sunsolve.sun.com.


  1. Create a text file with the following lines. Replace the parameters shown in the file with values specific to your installation:


    dn: cn=Uniqueness in Attribute Set,cn=plugins,cn=config
    objectClass: top
    objectClass: nsSlapdPlugin
    objectClass: ds-signedPlugin
    objectClass: extensibleObject
    cn: Uniqueness in Attribute Set
    nssldap-pluginPath: server_root/lif/uid-plugin.so
    nsslapd-pluginInitfunc: NSUniqueAttrSet_Init
    nsslapd-pluginType: preoperation
    nsslapd-pluginEnabled: on
    nsslapd-pluginarg0: attributeset=mail,mailalternateaddress,mailequivalentaddress
    nsslapd-pluginarg1: ugldapbasedn
    nsslapd-plugin-depends-on-type: database
    nsslapd-pluginId: NSUniqueAttrSet
    nsslapd-pluginVersion: 5.2
    nsslapd-pluginVendor: Sun Microsystems, Inc.
    nsslapd-pluginDescription: Enforce unique values among an attribute set

    Change the following parameters:

    Replace server_root with the directory underneath which your Directory Server is installed. For example: /var/opt/mps/serverroot

    Replace ugldapbasednwith your root suffix. Uniqueness checking is performed on all entries underneath this suffix.

  2. Stop Directory Server.

  3. Add your modified text file to the Directory Server dse.ldif file.

    Location of the dse.ldif File:

    The dse.ldif file is located in the following directory:

    server_root/slapd-machine_name/config

    where

    server_root is the directory underneath which Directory Server is installed. For example: /var/opt/mps/serverroot

    machine_name is the name of the host machine where Directory Server is installed.

    Where to Add Your Text File:

    Add your text file after the uid uniqueness section of the dse.ldif file. The first line of this section (the dn) is as follows:

    dn: cn=uid uniquenss,cn=plugins,cn=config

  4. Restart Directory Server.

    When Directory Server starts, it installs the modified dse.ldif file in the directory.

Troubleshooting

If Directory Server does not start because the dse.ldif file has generated an error, check the values you used to replace the parameters in the sample text file. Your LDAP root suffix and the Directory Server installation path and host machine must be correct for your installation.

If Directory Server still does not start, you can, as a last resort, remove the text file from the dse.ldif file and restart Directory Server.

Create Service Packages

Each user and group provisioned in the LDAP directory with Delegated Administrator should have a service package. A user or group can have more than one service package.

Predefined Class-of-Service Templates

When you run the Delegated Administrator configuration program (config-commda), you can choose to have the config-commda program install sample Class-of-Service templates in the directory.

For information about the sample Class-of-Service templates and the available mail attributes in a service package, see Service Packages in Chapter 1, Delegated Administrator Overview.

You can use the sample Class-of-Service templates to create and assign service packages. However, the sample templates are meant to be examples.

Creating Your Own Service Packages

Most likely you will want to create your own service packages based on customized Class-of-Service templates with attribute values appropriate for the users and groups in your installation.

To create your own service packages, use the Class-of-Service templates stored in the da.cos.skeleton.ldif file, located in the following directory:

da-base/lib/config-templates

This file was created specifically for use as a template for writing customized Class-of-Service templates. It is not installed in the LDAP directory when Delegated Administrator is configured.

The da.cos.skeleton.ldif file contains a parameterized template for each Class-of-Service definition provided by Delegated Administrator:

You can create your own Class-of-Service templates by using one or more of the parameterized templates in the da.cos.skeleton.ldif file.

The Class-of-Service templates in the da.cos.skeleton.ldif file are as follows:


# Templates for creating COS templates for service packages.
#
# There are six COS definitions :
#   standardUserMail
#   standardUserCalendar
#   standardUserMailCalendar
#   standardGroupMail
#   standardGroupCalendar
#   standardGroupMailCalendar
#
# Each definition can have zero or more COS templates which
# define specific values for the attributes listed in the 
# COS definition.
#
# Each COS definition points to a corresponding subdirectory
# in which COS templates for that definition (and no other
# definition) are found.  The templates directory structure
# is as follows:
# standardUserMail	      => o=mailuser,o=costemplates,<ugldapbasedn>
# standardUserCalendar      => o=calendaruser,o=costemplates,
#                               <ugldapbasedn>
# standardUserMailCalendar  => o=mailcalendaruser,o=costemplates,
#                               <ugldapbasedn>
# standardGroupMail	      => o=mailgroup,o=costemplates,
#                               <ugldapbasedn>
# standardGroupCalendar	  => o=calendargroup,o=costemplates,
#                               <ugldapbasedn>
# standardGroupMailCalendar => o=mailcalendargroup,o=costemplates,
#                               <ugldapbasedn>
#
# Thus, all COS templates for the user mail service are found in the
# o=mailuser,o=costemplates,<ugldapbasedn> directory, etc.
#
# It is not necessary to have any templates for a given definition. 
# In that case default values are assumed for those attributes defined
# in the COS definition.
#
# If a template is created for a definition there should be at least
# one attribute with a defined value.
#
# Consult documentation for values for the attributes.  
# Documentation includes units and default values.
#
# The finished COS derived from this skeleton is added to the 
# directory with the following command:
# 
# ldapmodify -D <directory manager> -w <password> 
# -f <cos.finished.template.ldif>
#
#
############################################################
#
#	standardMailUser COS template
#
############################################################
# There must be a least one of the following attributes:
# - mailMsgMaxBlocks
# - mailQuota
# - mailMsgQuota
# - mailAllowedServiceAccess
#
dn: cn=<service package name>,o=mailuser,o=cosTemplates,
    <ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: <service package name>
mailMsgMaxBlocks: <mailMsgMaxBlocksValue>
mailQuota: <ma:ilQuotaValue>
mailMsgQuota: <mailMsgQuotaValue>
mailAllowedServiceAccess: <mailAllowedServiceAccessValue>
daServiceType: mail user#
#
############################################################
#
#	standardCalendarUser COS template
#
############################################################
# There must be a least one of the following attributes:
# - icsPreferredHost
# - icsDWPHost
# - icsFirstDay
#
dn: cn=<service package name>,o=calendaruser,o=cosTemplates,
    <ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: <service package name>
icsPreferredHost: <preferredHostValue>
icsDWPHost: <dwpHostValue>
icsFirstDay: <firstDayValue>
daServiceType: calendar user
#
#
############################################################
#
#	standardMailCalendarUser COS template
#
############################################################
# There must be a least one of the following attributes:
# - mailMsgMaxBlocks
# - mailQuota
# - mailMsgQuota
# - mailAllowedServiceAccess
#
dn: cn=<service package name>,o=mailcalendaruser,o=cosTemplates,
    <ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: <service package name>
mailMsgMaxBlocks: <mailMsgMaxBlocksValue>
mailquota: <mailQuotaValue>
mailmsgquota: <mailMsgQuotaValue>
mailAllowedServiceAccess: <mailAllowedServiceAccessValue>
daServiceType: calendar user
daServiceType: mail user
#
#
############################################################
#
#	standardMailGroup COS template
#
############################################################
# There must be a least one of the following attributes:
# - mailMsgMaxBlocks
#
#
dn: cn=<service package name>,o=mailgroup,o=cosTemplates,
    <ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: <service package name>
mailMsgMaxBlocks: <mailMsgMaxBlocksValue>
daServiceType: mail group
#
#
############################################################
#
#	standardCalendarGroup COS template
#
############################################################
# There must be a least one of the following attributes:
# - icsdoublebooking
# - icsautoaccept
#
#
dn: cn=<service package name>,o=calendargroup,o=cosTemplates,
    <ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: <service package name>
icsdoublebooking: <doubleBookingValue>
icsautoaccept: <autoAcceptValue>
daServiceType: calendar group
#
#
############################################################
#
#	standardMailCalendarGroup COS template
#
############################################################
# There must be a least one of the following attributes:
# - icsdoublebooking
# - icsautoaccept
# - mailMsgMaxBlocks
#
#
dn: cn=<service package name>,o=mailcalendargroup,o=cosTemplates,
    <ugldapbasedn>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: <service package name>
mailmsgmaxblocks: <mailMsgMaxBlocksValue>
icsdoublebooking: <doubleBookingValue>
icsautoaccept: <autoAcceptValue>
daServiceType: calendar group
daServiceType: mail group

ProcedureTo create your own service packages

  1. Copy and rename one of the parameterized templates in the da.cos.skeleton.ldif file.

    When you install Delegated Administrator, the da.cos.skeleton.ldif file is installed in the following directory:

    da-base/lib/config-templates

    Choose one of these templates in the da.cos.skeleton.ldif file to copy and rename:


    standardUserMail
    standardUserCalendar
    standardUserMailCalendar
    standardGroupMail
  2. Edit the following parameters in your copy of the template:

    • <ugldapbasedn>

      Change the root suffix parameter,<rootSuffix>, to your root suffix (such as o=usergroup).

      The <ugldapbasedn> parameter appears in the DN.

    • <service package name>

      Change the <service package name> parameter to your own service package name.

      The <service package name> parameter appears in the DN and the cn.

    • Mail attribute values:


      <mailMsgMaxBlocksValue> 
      <mailQuotaValue> 
      <mailMsgQuotaValue> 
      <mailAllowedServiceAccessValue>

      Edit these values to your specifications.

      For example, you could enter the following values for the mail attributes:


      mailMsgMaxBlocks: 400 
      mailQuota: 400000000 
      mailMsgQuota: 5000 
      mailAllowedServiceAccess: imap:ALL$+pop:ALL$+smtp:ALL$+http:ALL
    • Calendar attribute values:


      <preferredHostValue>
      <dwpHostValue>
      <firstDayValue>

      These parameters represent values for the icsPreferredHost, icsDWPHost, and icsFirstDay LDAP attributes.

      Edit these values to your specifications.

    For definitions and descriptions of these attributes, see “Chapter 3: Messaging Server and Calendar Server Attributes” in the Sun Java Communications Suite Schema Reference.

    You must use at least one attribute in a customized Class-of-Service template. You do not have to use all four mail attributes in a custom template. You can delete one or more attributes from the service package.

  3. Use the LDAP directory tool ldapmodify to install the service package in the directory.

    For example, you could run the following command:

    ldapmodify -D <directory manager> -w <password> -f <cos.finished.template.ldif>

    where

    <directory manager> is the name of the Directory Server administrator.

    <password> is the password of the Directory Service administrator.

    <cos.finished.template.ldif> is the name of the edited ldif file to be installed as a service package in the directory.

Add ACIs for Schema 2 Compatibility Mode

If you are using an LDAP directory in Schema 2 compatibility mode, you must manually add ACIs to the directory to enable Delegated Administrator to provision in your directory. Take the following steps:

ProcedureTo add ACIs for Schema 2 compatibility mode

  1. Add the following two ACIs to the OSI root. You can find the following two ACIs in the usergroup.ldif file, located in the /opt/SUNWcomm/config directory.

    Be sure to replace ugldapbasedn with your usergroup suffix. Add the edited usergroup.ldif into the LDAP directory.


    #
    # acis to limit Org Admin Role
    #
    ########################################
    # dn: <local.ugldapbasedn>
    ########################################
    dn: <ugldapbasedn>
    changetype: modify
    add: aci
    aci: (target="ldap:///($dn),<ugldapbasedn>")(targetattr="*")
    (version 3.0; acl "Organization Admin Role access deny to org node";
    deny (write,add,delete) roledn = "ldap:///cn=Organization Admin 
    Role,($dn),<ugldapbasedn>";)

    dn: <ugldapbasedn>
    changetype: modify
    add: aci
    aci: (target="ldap:///($dn),<ugldapbasedn>")(targetattr="*")
    (version 3.0; acl "Organization Admin Role access allow read 
    to org node";
    allow (read,search) roledn = "ldap:///cn=Organization Admin 
    Role,($dn),<ugldapbasedn>";)
  2. Add the following two ACIs to the DC Tree root suffix. You can find the following two ACIs in the dctree.ldif file, located in the /opt/SUNWcomm/lib/config-templates directory.

    Be sure to replace dctreebasedn with your DC Tree root suffix and ugldapbasedn with your usergroup suffix. Add the edited dctree.ldif into the LDAP directory.


    #
    # acis to limit Org Admin Role
    #
    ########################################
    # dn: <dctreebasedn>
    ########################################
    dn: <dctreebasedn>
    changetype: modify
    add: aci
    aci: (target="ldap:///($dn),<dctreebasedn>")(targetattr="*")
    (version 3.0; acl "Organization Admin Role access deny to dc node"; 
    deny (write,add,delete) roledn = "ldap:///cn=Organization Admin 
    Role,($dn),<ugldapbasedn>";)

    dn: <dctreebasedn>
    changetype: modify
    add: aci
    aci: (target="ldap:///($dn),<dctreebasedn>")(targetattr="*")
    (version 3.0; acl "Organization Admin Role access allow read to dc 
    node"; allow (read,search) roledn = "ldap:///cn=Organization Admin 
    Role,($dn),<ugldapbasedn>";)
  3. Add the following additional ACIs to the DC Tree root suffix. (These ACIs are not in the dctree.ldif file.)


    dn:<dctreebasedn> 
    changetype:modify
    add:aci
    aci: (target="ldap:///<dctreebasedn>")(targetattr="*")
    (version 3.0; acl "S1IS Proxy user rights"; allow (proxy)
    userdn = "ldap:///cn=puser,ou=DSAME Users,<ugldapbasedn>";)

    dn:<dctreebasedn>
    changetype:modify
    add:aci
    aci: (target="ldap:///<dctreebasedn>")(targetattr="*")
    (version 3.0; acl "S1IS special dsame user rights for all under the 
    root suffix"; allow (all) userdn ="ldap:///cn=dsameuser,ou=DSAME 
    Users,<ugldapbasedn>";)

    dn:<dctreebasedn>
    changetype:modify
    add:aci
    aci: (target="ldap:///<dctreebasedn>")(targetattr="*")
    (version 3.0; acl "S1IS Top-level admin rights"; 
    allow (all) roledn = "ldap:///cn=Top-level Admin 
    Role,<ugldapbasedn>";)
  4. Set the com.iplanet.am.domaincomponent property in the AMConfig.properties file to your DC Tree root suffix.

    For example, modify the following lines in the <AM_base_directory>/lib/AMConfig.properties file:

    from

    com.iplanet.am.domaincomponent=o=isp

    to

    com.iplanet.am.domaincomponent=o=internet

  5. Enable Access Manager to use compatibility mode.

    In the Access Manager Console, in the Administration Console Service page, check (enable) the Domain Component Tree Enabled check box.

  6. Add the inetdomain object class to all the DC Tree nodes (such as dc=com,o=internet), as in following example:


    /var/mps/serverroot/shared/bin 298% ./ldapmodify 
    -D "cn=Directory Manager" -w password
    dn: dc=com,o=internet
    changetype: modify
    add: objectclass
    objectclass: inetdomain
  7. Restart the Web container.