Sun Java System Communications Services 6 2005Q4 Delegated Administrator 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.

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.

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 four parameterized templates, one 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 four COS definitions :
#   standardUserMail
#   standardUserCalendar
#   standardUserMailCalendar
#   standardGroupMail
#
# 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>
#
# 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,<rootSuffix>
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: <service package name>
mailMsgMaxBlocks: <mailMsgMaxBlocksValue>
mailQuota: <ma:ilQuotaValue>
mailMsgQuota: <mailMsgQuotaValue>
mailAllowedServiceAccess: <mailAllowedServiceAccessValue>
#
#
############################################################
#
#	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

ProcedureTo create your own service packages

Steps
  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 System Communications Services 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

Steps
  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/config 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 (formerly called Identity Server) 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.