Chapter 3 Configuration Details

This chapter describes the configuration details for Communications Express.

• Communications Express Configuration Files

• Configuration Parameter Details

• Supporting Horizontal Scalability of Address Book Server

Communications Express Configuration Files

Communications Express maintains the configuration parameters in the following configuration files:

• The uwcauth.properties file maintains the authentication, user or group access, and single sign-on related parameters. The uwcauth.properties file is located at : uwc-deployed-path/WEB-INF/config/.

• The uwcconfig.properties file maintains the calendar, mail, and address book related configuration parameters. The uwcconfig.properties file is located at:uwc-deployed-path/WEB-INF/config/.

• The db_config.properties file defines the address book store configuration details. By default, Communications Express deploys two types of db_config.properties file.

  • Personal address book store. The personal address book store configuration file resides at uwc-deployed-path /WEB-INF/config/ ldappstore/db_config.properties.

  • Corporate address book store. The Corporate address book store configuration file resides at uwc-deployed-path /WEB-INF/config/corp-dir/db_config.properties.

To Edit the Configuration File

Before You Begin

All configuration files are ASCII text files, with each line defining a parameter and its associated value in the following format:

parameter =value

The parameters are initialized when configuring Communications Express. You can use a text editor to edit the file. Here are some conventions for setting parameters in the configuration files:

• All parameters and their associated one or more values must be separated by an equal sign (=). Spaces or tabs are allowed before or after the equal sign.

  For example:

  uwc-user-attr-sunUCDefaultApplication=calendar

• A comment line begins with an exclamation mark.

  By default some of the configuration parameters are commented out using exclamation mark. To use these parameters, remove the exclamation mark and change the parameter value.

1. Log in as a user having modify permissions.

2. Change to the directory where the .properties file is located.

3. Edit the parameters using a text editor.

4. Restart the web container for the new configuration values to take effect.

Configuration Parameter Details

You can modify calendar, mail, and address book configuration parameters as explained in the following tables.

• Configuring Messenger Express Parameters in the uwcconfig.properties File

• Configuring Directory Server Related Parameters for Sun Java System LDAP Schema V.1 in the uwcauth.properties File

• Configuring Access Manager Parameters in the uwcauth.properties File

• Configuring User Lookup Parameters for User or Group in the uwcauth.properties File

• Configuring Calendar Server Parameters in the uwcconfig.properties File

• Configuring the Address Book Personal Store Parameters in the db_config.properties File

• Configuring Corporate Directory Parameters in the db_config.properties File

• Configuring Secure Socket Layer

Configuring Messenger Express Parameters in the uwcconfig.properties File

Table 3–1 lists all the messenger express related parameters

Configuring Directory Server Related Parameters for Sun Java System LDAP Schema V.1 in the uwcauth.properties File

You edit the parameters mentioned in Table 3–2 when the Authentication LDAP Server is different from the User or Group LDAP.

Configuring Access Manager Parameters in the uwcauth.properties File

Configuring User Lookup Parameters for User or Group in the uwcauth.properties File

Configuring Calendar Server Parameters in the uwcconfig.properties File

Ensure that the Proxy Authentication and Anonymous Access is enabled in Sun Java^TM System Calendar Server.

To enable Proxy Authentication and Anonymous Access, configure the following Calendar Server parameters in the calendar configuration file ics.config:

• service.http.allowadminproxy = ”yes”

• service.wcap.anonymous.allowpubliccalendarwrite = "yes"

• service.http.allowanonymouslogin = "yes"

• service.calendarsearch.ldap = "no”

For more information about enabling Proxy Authentication and instructions on configuring the Calendar Server parameters, refer to Sun Java System Calendar Server 6.3 Administration Guide.

• Ensure that the Calendar Administrator User ID value you have assigned to calendar.wcap.adminid is the same as the service.admin.calmaster.userid value mentioned in the Calendar Server’s ics.conf file.

• Ensure that the corresponding user entry for Calendar Administrator User ID exists on LDAP server.

Configuring the Address Book Personal Store Parameters in the db_config.properties File

Table 3–7 lists the default Address Book personal store configuration parameters in the db_config.properties file.

The file can be accessed from: uwc-deployed-path/WEB-INF/config/ldappstore/

Configuring Corporate Directory Parameters in the db_config.properties File

Table 3–8 lists the default corporate directory parameters in the db_config.properties file. By default, all the LDAP related information is set based on the values mentioned for the user or group directory.

The db_config.properties file can be accessed from:WEB-INF/config/corp-dir/

Corporate Directory maintains the following two xlate files in the format xlate-objectclass-name.xml.

• xlate-inetorgperson.xml for contacts

• xlate-groupofuniquemembers.xml for groups

In xlate-objectclass-name .xml, objectclass-name represents the object class identifying a particular LDAP entry type. For example, xlate-inetorgperson.xml is an object class used to identify a contact, and groupofuniquemembers is an object class used to identify a group in Sun Java System Directory Server.

The xlate files contain the field mappings between an LDAP schema and the address book XML schema for a contact or group. The mapping is defined in terms of XML nodes. For example,

ab-xml-schema-keydb:LDAPField /ab-xml-schema-key

In this example:

• ab-xml-schema-field is the value that the address book uses in the code.

• LDAPField is the corresponding field name in LDAP.

You need to provide an appropriate field name for LDAPField. The value assigned to LDAPField should correspond to the value of LDAPField existing in your corporate directory LDAP schema.

Example 3–1 is an example of the xlate-inetorgperson.xml file.

Example 3–1 Default Contents of xlate-inetorgperson.xml

<abperson uid="db:uid">
  <entry entryID="db:uid">
    <displayname>db:cn</displayname>
    <description>db:multilineDescription</description>
    <creationdate>db:createtimestamp</creationdate>
    <lastmodifieddate>db:modifytimestamp</lastmodifieddate>
  </entry>
  <person>
    <givenname>db:givenname</givenname>
    <surname>db:sn</surname>
  </person>
  <organization>
    <company>db:company</company>
    <organizationalunit>db:ou</organizationalunit>
    <location>db:expr: db:iplanetbuildingnum+' '+db:iplanetbuildinglev+' '+db:roomNumber</location>
    <title>db:title</title>
    <manager>db:manager</manager>
    <secretary>db:secretary</secretary>
  </organization>
  <phone priority="1" type="work">db:telephoneNumber</phone>
  <phone priority="2" type="fax">db:facsimileTelephoneNumber</phone>
  <phone priority="3" type="mobile">db:mobile</phone>
  <phone priority="4" type="home">db:homePhone</phone>
  <phone priority="5" type="pager">db:pager</phone>
  <email priority="1" type="work">db:mail</email>
  <im priority="1" service="SunONE">db:uid</im>
  <im priority="2" service="AIM">db:aimscreenname</im>
  <im priority="3" service="ICQ">db:icqnumber</im>
  <postaladdress type="home">
    <street>db:homePostalAddress</street>
  </postaladdress>
  <postaladdress type="work">
    <street>db:postaladdress</street>
  </postaladdress>
  <weburl priority="1">
    <urladdr>db:labeleduri</urladdr>
    <description>URL</description>
  </weburl>
  <weburl priority="2">
    <urladdr>db:homepage</urladdr>
    <description>Home URL</description>
  </weburl>
  <calendar type="calendar">
    <urladdr>db:caluri</urladdr>
  </calendar>
</abperson>

Configuring Secure Socket Layer

You can configure the Web Server or Application Server on which Communications Express is deployed in the SSL mode.

For information about how to configure the Web Server on which Communications Express is deployed in the SSL mode, refer to Sun Java System Web Server 7.0 Administrator’s Configuration File Reference guide.

For information about how to configure the Application Server on which Communications Express is deployed in the SSL mode, refer to Sun Java System Application Server Administration Guide.

To Use Communications Express in SSL Mode

1. Set the following configuration parameters in the uwc-deployed-path /WEB-INF/config/uwcauth.properties file:

   • uwcauth.ssl.enabled=true. If set to true, the entire authentication process and access of the application is done in SSL mode.

   • uwcauth.https.port=SSL-port-number-of -the webcontainer-in which-uwc-is-deployed

   • webmail.ssl.port=SSL port for the Messaging Server

2. Set the local.webmail.sso.uwcsslport Messenger Express parameter value to the SSL port-number of the Web Server in which Communications Express is deployed.

   This parameter is required to instruct Messenger Server to get Communications Express integration services. For example, if this parameter is set, then time out event of webmail will take the user to Communications Express' login page.

   For example, local.webmail.sso.uwcsslport=SSL port-number of the webserver in which communications express is deployed

3. Set the webmail.ssl.port parameter for Messaging Server.

   Set the parameter to the SSL port that Messaging Server listens to.

To Configure Communications Express for SSLAuthentication Only

Communications Express can be configured for SSL authentication only, which implies that authentication can be performed over SSL, but access of the application thereafter is over non-SSL mode.

1. Set uwcauth.ssl.enabled to false in the uwcauth.properties file.

2. Set uwcauth.https.port to the SSL port number of the Web Server in which Communications Express is deployed.

3. Set uwcauth.ssl.authonly to true.

   ---

   Note –

   The two parameters, uwcauth.ssl.authonly and uwcauth.ssl.enabled in the uwcauth.properties file are mutually exclusive .

   ---

Supporting Horizontal Scalability of Address Book Server

In the previous release of the Sun Java System Communications Express, the Personal Address Book entries for a particular domain was stored in a single LDAP location that was represented by the defaultserver instance defined in the db_config.properties file. The db_config.propertiesfile existed in the directory pointed by the personalstore.properties file for the domain. For example, uwc-install/WEB-INF/config/ldappstore.

This setup was unable to scale to support large number of users and contacts per Personal Address Book. To overcome this limitation, the psRoot attribute in Communications Express 6.3 enables the administrator to provision users so that PAB data for different users is spread across different LDAP locations.

For example, ldap://mydir.com:389/piPStoreOwner=jsmith,o=siroe.com,o=PiServerDb

Figure 3–1 provides a high level overview of the architecture used to scale the Address Book Server horizontally.

The following are the key components of the Address Book Horizontal Scalability architecture:

• Personal Store

• DB

• DBMap

A Personal Store maintains the address book information of a user. It contains the definition of all the address books a user has created along with all the entries in those address books. Personal Stores are expressed as URLs, which describe the directory instance in which they are located and the DN within that particular directory instance.

A DB (DataBase) contains a collection of Personal Stores and as shown in Figure 3–1. . The address book can access any number of DBs. Every DB is defined by a DB-ID that defines the connection parameters for that DB. A DB of different type points to different DB locations.

A DBMap is a collection of DBs of the same type. Each DBMap has an ID which refers to the configuration information for that DBMap.

Figure 3–1 Horizontal Scalability of Address Book

The psRoot is an attribute in the user’s LDAP that specifies the host, port of the directory instance and the DN where the Address Book entries for the user is stored. psRoot is in the form: ldap://ldap_host:ldap_port/DN.

The value of psRoot attribute determines the DB type and DB location.

In the following psRoot example, ldap://mydir.com:389/piPStoreOwner=jsmith,o=siroe.com,o=PiServerDb

ldap:// indicates that the Address Book Personal Store for the user is accessed through the LDAP DB plug-in.

mydir.com:389 specifies the LDAP Host and Port.

piPStoreOwner=jsmith,o=siroe.com,o=PiServerDb specifies the DN of the Personal Store.

The Address Book Server does not provide any utility to distribute psRoot values for users, according to any scalability policy. Administrators need to set a specific policy suited best for the organization and use custom scripts to set the psRoot value for that policy.

The psRoot attribute can be turned on or off using the db.UserPsRoot parameter present in the domain specific personalstore.properties file. Set the parameter to “false” to use the defaultserver parameters in the db_config.properties file. Set the parameter to “true” to use the user’s psRoot value. The Personal Store parameters listed in Configuring the Address Book Personal Store Parameters in the db_config.properties File must be provided for each unique directory server instance used in psRoot. At runtime, the value of psRoot attribute is resolved to a directory instance using db-key.ldaphost and db-key.ldapport, where db-key is an arbitrary string that distinguishes one instance from the other. When no match is found for the db-key.ldaphost and db-key.ldapport, the defaultserver instance is used.

Additional Configuration Required for Horizontal Scalability Support

The psRootattribute in the user’s LDAP entry is an Address Book Server compliant URL that defines the LDAP location from which the user’s Personal Address book entries are stored and retrieved. The psRoot attribute enables the administrator to provision users so that PAB data for all users is spread across multiple directory locations.

For existing Messenger Express users, if PAB Migration is enabled, the psRoot attribute is constructed using the existing pabURI attribute and a mapping table is defined in uwc-deploy-dir/ WEB-INF/config/migrate.properties .

The lookup table in the migrate.properties file consists of the pabhost and pabport entries in the following format:

pabhost.pabport.abhostport = abldaphost:abldapport

where pabhost.pabport refers to the source directory instance and abldaphost and abldaport is the target directory instance to which the PAB data should be migrated.

For example, if you want to migrate the PAB data from the directory running at pab.example.com:389 to the address book directory running at abs.example.com:389, the should exist in the migrate.properties as:

pab.example.com.389.abhostport = abs.example.com:389

You may have as many lookups as found necessary in the migrate.properties file. If the pabURI attribute for a user uses pabhost and pabport, the psRoot constructed using the default psRoot pattern will be in the format:

ldap://abldaphost: abldapport/piPStoreOwner=%U,o=%D,o=PiServerDb

If the lookup is not defined for a pabURI value, that is, no entry is provided in the mapping table that matches the pabURI, the pabhost and pabport values are used as the default values for abldaphost and abport. Implying that in the absence of a mapping table, the PAB entries from Messaging Server is migrated to another root in the same directory instance as per the Address Book Schema. In this scenario, the target directory instance will be the same as the source directory instance.

The lookup table is not defined by the patch installer. You need to define the lookup table after a patch install, and restart the web server.

Ensure that abldaphost:abldapport directory Server instance is defined in the db_config.properties file pointed to by the personalstore.properties of that domain.

Setting the psRoot Value Automatically

When a new user logs in, default values are set for the psRoot attribute in the user’s entry.

For new users, a psRoot value is constructed by using the psRoot pattern defined in the personalstore.properties file, and the defaultserverhost and defaultserverPort values in the db_config.properties file. For example, when you use the default psRoot pattern, the default psRoot value is in the format:

ldap://default-server-host :default-server-port/piPStoreOwner=%U,o=%D,o=PiServerDb

where:

%U = login ID of the user. For example, jsmith.

%D = domain of the user. For example siroe.com.

Creating Additional Remote Address Books

You can configure Communications Express to add more than one remote address books. For example, you can have more than one corporate directories for users in different domains.

To Add a Remote Address Book

For remote address books a corresponding instance should exist in the personalstore.properties file. The value of db.xxx.urlmatch in the personalstore.properties file should be assigned the value of bookremoteurl attribute present in the defaultps.xml file.

To add a new remote address book, you need to add the following items:

1. Add a new book node in the defaultps.xml file.

   This file contains the default definitions for personal and corporate address books that are created in the LDAP store when a user logs in for the first time. that contain the definitions of Personal Address Book and a Corporate Address Book. Following are examples of the XML sections in the defaultps.xml that contain the definitions for multiple remote address books:

   <book booktype="abook" bookremoteurl="ldap://corpdirectory/o=org1,o=isp";> <bookoc>piRemoteBook</bookoc> <entry entryID="corpdir1"> <displayname>_Corporate Directory 1</displayname> <description>This is Corporate Directory 1</description> </entry> </book> <book booktype="abook" bookremoteurl="ldap://corpdirectory/o=org2,o=isp";> <bookoc>piRemoteBook</bookoc> <entry entryID="corpdir2"> <displayname>_Corporate Directory 2</displayname> <description>This is Corporate Directory 2</description> </entry> </book>

2. Add a new instance in the personalstore.properties file.

   The following is a sample entry in the personalstore.properties file configured for two remote address books.

   db.idir.class = com.iplanet.iabs.ldapplug.iLDAP db.idir.urlmatch = ldap://corpdirectory/o=org1,o=isp db.idir.configpath = ../config/corp-dir db.idir.wildcardsearch = 0 db.idir.randompaging = false db.idir.corporatedir = true db.idir2.class = com.iplanet.iabs.ldapplug.iLDAP db.idir2.urlmatch = ldap://corpdirectory/o=org2,o=isp db.idir2.configpath = ../config/corp-dir db.idir2.wildcardsearch = 0 db.idir2.randompaging = false db.idir2.corporatedir = true