Differentiating Server and Client Versions

Providing installation and configuration instructions for deploying Secured LDAP clients is a challenging task because Sun supports several different versions of directory servers and clients . This section explains what the differences are, how to identify what version you are using, and which tools to use with each client version. The topics covered are:

• "Directory Server Versions" on page 191

• "LDAP Name Service Client Versions" on page 197

• "Mixing Client and Server Versions" on page 214

Directory Server Versions

Over the years , the name of the directory server and how it is packaged have changed. Most of the name changes have been due to marketing preferences or trademark constraints. No matter what the reason, the name changes have been a source of confusion. The packaging changes are primarily a result of integrating the directory server into the Solaris OE, while at the same time supporting multiple platforms that do not have the same software installation mechanism as the Solaris OE.

The following directory server versions are discussed in this chapter:

• Netscape Directory Server 4.1x software (bonus software)

• iPlanet Directory Server 5.1 software (bundled in Solaris 9 OE, initial release)

• Sun ONE Directory Server 5.1 software (compressed tar file)

• Sun ONE Directory Server 5.2 software (compressed tar file)

• Sun ONE Directory Server 5.2 software (SVR4 packages)

Netscape Directory Server 4.1x (Bonus Software)

The Netscape Directory Server 4.1x version was co-packaged with the Solaris 8 OE in the Bonus Pack CD. No integrated setup scripts like idsconfig were provided in 4.1, but an equivalent script was made available on the www.sun.com/blueprints web site.

The End of Life (EOL) of this product has been announced by Sun, so its deployment is discouraged. Besides the support issue, this version is missing a couple of key features and therefore deployment is undesirable. The missing features are:

• Multi-Master Replication (MMR)

• SASL DIGEST-MD5 Authentication

• SASL GSSAPI

MMR capability is key to deploying a cost effective high-availability architecture. SASL/DIGEST-MD5 authentication allows passwords to be encrypted before they are sent to the server. A complete description of SASL/DIGEST-MD5 and SASL/GSSAPI can be found in Chapter 3 "Defining Directory Service Security Architecture.

The Netscape Directory Server 4.1x software came packaged as a single compressed tar file that you would extract from the Bonus CD or download from the iPlanet web site. A free 200K user license for this version of the directory server is included with the Solaris 8 OE.

iPlanet Directory Server 5.1 (Bundled)

The iPlanet Directory Server 5.1 software shipped as part of the Solaris 9 OE distribution media, and for the first time was available in SVR4 package format. These packages are:

• IPLTadcon Administration Server Console

• IPLTadman Administration Server Documentation

• IPLTadmin Administration Server

• IPLTcons Console Client Base

• IPLTdscon Directory Server Console

• IPLTdsman Directory Server Documentation

• IPLTdsr Directory Server ( root )

• IPLTdsu Directory Server ( usr )

• IPLTjss Network Security Services for Java software

• IPLTnls Nationalization Languages and Localization Support

• IPLTnspr Portable Runtime Interface

• IPLTnss Network Security Services

• IPLTpldap PerLDAP

These packages are installed when the Full Distribution ( SUNWCall ) or Full Distribution+OEM ( SUNWCXall ) package cluster is selected during the installation of Solaris 9 OE. Besides the simplified installation, other enhancements are provided in the initial Solaris 9 OE release, such as the following:

• /usr/bin/directoryserver wrapper script Takes away the path dependencies inherent in previous directory server versions. This allows you to run directory administration commands without having to know where the directory server software is loaded. The directory server setup program was modified to place the software in a fixed location rather than an arbitrary one. It also automatically creates a startup file called /etc/init.d/directory for you.

• idsconfig script Used to make the necessary configuration changes to support LDAP as a name service.

• ldapaddent program Used to populate LDAP entries with data from name service databases in files format. There is no equivalent functionality in the previous version, although the dsimport command that was part of the NIS Extensions software could be tweaked to import LDAP name service data.

Sun ONE Directory Server 5.1 Software (compressed tar file)

This version is almost identical to the iPlanet Directory Server 5.1 bundled version, although the name has changed because the directory server is an integral component of the Sun Open Network Environment (Sun ONE). This software can be downloaded from the sun.com web site and configured with the idsconfig script to support LDAP as a name service. The ldapaddent utility can be used to populate the directory.

This version is not integrated with the /usr/sbin/directoryserver wrapper, so you must specify where to install the software. Another key difference is the update delivery mechanism. Updated versions of the unbundled directory server are provided as Service Packs that contain an entire image of the software, while updates to the bundled version are provided as patches.

Note

Service Pack 1 contained changes to the RFC 2307 schema files that caused idsconfig to fail. This problem can be fixed by manually editing the 11rfc2307.ldif schema file. The problem is fixed in Service Pack 2.

Sun ONE Directory Server 5.2 Software (SVR4 packages)

Like the iPlanet Directory Server 5.1 version, the Sun ONE Directory Server 5.2 software is distributed as SVR4 packages. However, the package names have changed and the number of packages has increased. Some of the packages contain updates to packages in the Solaris OE distribution, some are required to run the Directory Server in 64-bit mode, and some are only required with the Solaris 8 OE.

A complete list of all packages in alphabetical order is:

• SUNWasha Sun ONE Administration Server component for Sun Cluster software

• SUNWasvc Sun ONE Administration Console

• SUNWasvcp Sun ONE Administration Server Console Plug-in

• SUNWasvr - Sun ONE Administration Server ( Root )

• SUNWasvu Sun ONE Administration Server ( Usr )

• SUNWdsha Sun One Directory Server Component for Sun Cluster software

• SUNWdsvcp Sun ONE Directory Server Console Plug-in

• SUNWdsvh Sun ONE Directory Server Heap Allocator

• SUNWdsvhx Sun ONE Directory Server Heap Allocator (64-bit)

• SUNWdsvpl Sun ONE Directory Server PerLDAP modules

• SUNWdsvr Sun ONE Directory Server ( Root )

• SUNWdsvu Sun ONE Directory Server ( Usr )

• SUNWdsvx Sun ONE Directory Server (64-bit)

• SUNWicu International Components for Unicode User Files

• SUNWicux International Components for Unicode User Files (64-bit)

• SUNWjss Network Security Services for Java (JSS) software

• SUNWldk LDAP C SDK

• SUNWldkx LDAP C SDK (64-bit)

• SUNWpr Netscape Portable Runtime

• SUNWprx Netscape Portable Runtime (64-bit)

• SUNWsasl Simple Authentication and Security Layer

• SUNWsaslx Simple Authentication and Security Layer (64-bit)

• SUNWtls Network Security Services

• SUNWtlsx Network Security Services (64-bit)

These packages are designed to support both the Solaris 8 and the Solaris 9 OE and both the 32-bit and 64-bit mode of the directory server. Some are not specific to the Directory Server and are used by other applications. The Administration Server and Sun ONE Server Console applications are also included among these packages.

To understand the role each package plays it is helpful to group them in the following way.

Shared Packages, 32-bit

Shared packages are those that are not unique to the Directory Server, Administration Server, or Console. These include:

• SUNWicu

• SUNWtls

• SUNWsasl

• SUNWjss

• SUNWldk

• SUNWpr

Shared Packages, 64-bit

These packages are layered on top of the previous one to enable 64-bit operations of applications. They include:

• SUNWicux

• SUNWtlsx

• SUNWsaslx

• SUNWldkx

• SUNWprx

Sun ONE Server Console Packages

This is contained in a single package, which is:

• SUNWasvc

Sun ONE Administration Server

These include:

• SUNWasvu

• SUNWasvr

• SUNWasvcp

• SUNWdsvcp

Note

There is no 64-bit version of the Administration Server

Directory Server Packages, 32-bit

These include:

• SUNWdsvpl

• SUNWdsvu

• SUNWdsvr

Directory Server Packages, 64-bit

This is contained in a single package, which is:

• SUNWdsvx

Solaris 8 OE Specific Packages

These packages help increase Directory Server performance:

• SUNWdsvh

• SUNWdsvhx

Sun Cluster HA Agents

Separate agents for the Directory and Administration Servers are included as:

• SUNWasha

• SUNWdsha

Sun ONE Directory Server 5.2 Software (compressed tar file)

This is essentially the same release as the SVR4 package version, but the delivery mechanism is quite different. It is distributed as a compressed tar file rather than SVR4 packages and there is no /usr/sbin/directoryserver wrapper program.

The unbundled version of the directory server does have some features that might interest system administrators. These include:

• Can be installed by a non-root user.

• More than one installation can be performed on the same system. This can be useful for separating test and production versions of the software.

• Consistency with other operating environments. For example, there aren't any SVR4 packages for Linux and Windows.

• More flexibility on where to install the software.

• Combines installation and configuration.

LDAP Name Service Client Versions

There are two distinctly different Solaris OE LDAP naming service clients available, commonly referred to as:

• Native Solaris OE LDAP Client

• Secured LDAP Client

Sometimes they are referred to as the Phase 1 and Phase 2 implementation respectively. The Secured LDAP Client was introduced in the Solaris 9 OE and later backported to the Solaris 8 OE. It is a superset of the Phase 1 implementation, and available on the same platforms, so there are no compelling reasons to deploy Phase 1.

For completeness, and for the benefits of those who are familiar with Phase 1, both are discussed in the following sections so that feature and implementation differences can be highlighted.

Phase 1 - Native Solaris OE LDAP

From a deployment view, the key differences between the Phase 1 and Phase 2 implementation are the structure of the client profiles and the tools used to manage them. The client profile that supports Phase 1 is easily identified by its version number of 1.0 and its object class of SolarisNamingProfile . The tool used to generate this profile is the ldap_gen_profile utility.

The following sections describe the attributes defined for the SolarisNamingProfile object class and how they are created using the ldap_gen_profile utility.

Version 1 Client Profile

The schema definition of the Version 1.0 profile is contained in the user99.ldif file under the server root for your directory server instance. The location of the schema files is dependent on the version of the directory server you are using. This client profile can be used by the Secured LDAP Client (Phase 2), but would not support the new features described in the Phase 2 section.

Not all of the attributes defined by the SolarisNamingProfile object class are used. For example, the SolarisCertificatePath and SolarisCertificatePassword attributes were never used, and have been replaced in the Version 2.0 client profile. Also, although the SolarisTransportSecurity attribute can be set to SSL, this feature was never implemented.

The following code box shows the schema definition for the SolarisNamingProfile . Note the readable format used to represent the schema

 objectclass SolarisNamingProfile    oid       1.3.6.1.4.1.42.2.27.5.2.7    superior       top    requires       objectclass,       cn,       SolarisLDAPServers,       SolarisSearchBaseDN    allows       SolarisAuthMethod,       SolarisBindDN,       SolarisBindPassword,       SolarisCacheTTL       SolarisCertificatePassword,       SolarisCertificatePath,       SolarisDataSearchDN,       SolarisPreferredServer,       SolarisPreferredServerOnly,       SolarisSearchReferral,       SolarisSearchScope,       SolarisSearchTimeLimit,       SolarisTransportSecurity 

definition. The actual format Sun ONE Directory Server 5.2 software uses can be found in the 99user.ldif file in the schema directory.

Version 1.0 client profile templates should always be initially generated by the Solaris OE ldap_gen_profile utility. This assures that only the supported attributes are used and the appropriate values are entered. Once a template is created, you can change the attribute values for different profiles.

Note

The ldap_gen_profile utility is not available in the Solaris 9 OE release. Therefore, to generate Version 1.0 profiles you need to run the ldap_gen_profile utility on a system running the Solaris 8 OE. If the Solaris OE 8 Enhanced LDAP Naming Services feature patch is installed, there may be an issue with the generation of Version 1.0 profiles. Check sunsolve .sun.com for the latest status on this issue.

The following shows a Version 1.0 profile in LDAP Data Interchange Format (LDIF) representation.

 dn: cn=416default,ou=profile,dc=example,dc=com SolarisBindDN: cn=proxyagent,ou=profile,dc=example,dc=com SolarisBindPassword: {NS1}4a3788e8c053424f SolarisLDAPServers: 129.148.181.130 SolarisSearchBaseDN: dc=example,dc=com SolarisAuthMethod: NS_LDAP_AUTH_SIMPLE SolarisTransportSecurity: NS_LDAP_SEC_NONE SolarisSearchReferral: NS_LDAP_FOLLOWREF SolarisSearchScope: NS_LDAP_SCOPE_ONELEVEL SolarisSearchTimeLimit: 30 SolarisCacheTTL: 43200 cn: v1default objectClass: top objectClass: SolarisNamingProfile 

The ldap_gen_profile Utility

To generate LDIF that can be imported into your directory server, use the ldap_gen_profile command. There are two versions of this command:

• The original version that shipped with the Solaris 8 OE

• The updated version that is installed with the enhanced naming services feature patch (108993-18)

The command syntax for the first version is shown below and described in TABLE 4-1. Refer to the patch documentation for the syntax of the second version.

  /usr/sbin/ldap_gen_profile -P   profile_name  [  -O  ] [  -a none   simple   cram_md5  ] [  -b   baseDN  ] [  -B   alternate_search_dn  ] [  -d   domainname  ] [  -D   Bind_DN  ] [  -e   client_TTL  ] [  -o   timeout_value  ] [  -p   server_preference  ] [  -r   follow_referrals  ] [  -w   client_password  ]  LDAP_server_addr  

Table 4-1. ldap_gen_profile Utility Options

Options	Description
-a none simple cram_md5	Specifies the authentication method. Multiple values can be specified, separated by commas. the default value is none . If simple or cram_md5 is specified, a password must be provided.
	Note: The cram_md5 authentication method is not supported by the Sun ONE Directory Server 5.1 or 5.2 software versions.
-b baseDN	Specifies the search baseDN (for example dc= example , dc=com .) The default is the root naming context on the first server specified.
-B alternate_search_dn	Overrides the baseDN for LDAP searches for any of the databases defined in the /etc/nsswitch.conf file.
-d domainname	Specifies the domain name (which becomes the default domain for the machine). The default is the current domain name.
-D Bind_DN	Specify the Bind Distinguished Name (for example, cn= proxyagent , ou=profile , dc=example , dc=com ).
-e client_TTL	Specifies the TTL value for the client information. This is only relevant if the machine was initialized with a client profile. Set client_TTL to (zero) if you do not wish for ldap_cachemgr to attempt an automatic refresh from the servers. The times are specified with either a (zero, for no expiration) or a positive integer and either d for days, h for hours, m for minutes or s for seconds. The default is 12h .
-o timeout_value	Specifies LDAP operation timeout value. The default is three minutes.
-O	Informs the client to contact only the servers on the preferred list. The default is FALSE .
-p server_preference	Specifies the server preference list (for example, 129.123.123.1:8080, 129.123.123.2:386 ) The preferred servers can be defined either by the server specific address or by the subnet on which the server resides. To remove the server preference, specify "" for the -p option. The default preference is the local subnet.
-P profile_name	Specifies a profile that is downloaded from the server and sets all the entries automatically. This option also sets an expiration time that ldap_cachemgr can use to automatically update the file if needed. The default profile_name is default and is stored in the ou=profile container.
-r follow_referrals	The default is to follow referrals. Enter a value of noref to override the default.
-v	Specifies verbose mode. Recommended for troubleshooting.
-w client_password	Specifies client password for SIMPLE and cram_md5 authentication modes. This option is not required if authentication mode is none .

ldap_gen_profile example:

  ldap_gen_profile -P eng -a simple -d eng.example.com -w test123 \   -b dc=eng, dc=example, dc=com -B ou=people, dc=lab, dc=eng, dc=\   example, dc=com -D cn=proxyagent, ou=profile, cd=eng, dc=example, dc=\   com -r noref -e 1h -O -p 129.123.123.1 -o 30s 129.123.200.7 \   129.123.00.1 129.123.5.6 > myprofile.ldif  

Adding the SolarisBindLimit Attribute

When the ldap_gen_profile command is run to create a client profile, the attribute SolarisBindTimeLimit is specified in the resulting LDIF with a value of 30 . This attribute was created to fix a problem in the Phase 1 native implementation that prevented LDAP server failover to work properly. By specifying the attribute and a value in seconds, you can direct the LDAP client to try a secondary server after a defined period of time. The SolarisNamingProfile schema was not updated in the Sun ONE Directory Server 5.1 release, so you needed to add it manually.

Note

The failover mechanism was fixed in Phase 2, so this is no longer an issue.

How Parameter Values are Stored

After the Phase 1 client is initialized, the parameter values specified in the client profile are placed in two files:

• /var/ldap/ldap_client_file

• /var/ldap/ldap_client_cred

The parameters are stored as NS_LDAP_* values instead of the attribute names. This allows different attributes to be used to provide the same information. For example, the version 2.0 profile schema defines different attribute names, but the NS_LDAP_* parameters names are the same.

The following example shows a sample ldap_client_file file.

[View full width]

 
 [View full width] 
 # more ldap_client_file # # Do not edit this file manually; your changes will be lost.Please use ldapclient (1M)  instead. # NS_LDAP_FILE_VERSION= 1.0 NS_LDAP_SERVERS= 128.100.100.1 NS_LDAP_SEARCH_BASEDN= dc=example, dc=com NS_LDAP_AUTH= NS_LDAP_AUTH_SIMPLE NS_LDAP_SEARCH_REF= NS_LDAP_FOLLOWREF NS_LDAP_SEARCH_SCOPE= NS_LDAP_SCOPE_ONELEVEL NS_LDAP_SEARCH_TIME= 30 NS_LDAP_PROFILE= default 

The following example shows a sample ldap_client_cred file.

 # more ldap_client_cred # # Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead. # NS_LDAP_BINDDN= cn=proxyagent, ou=profile, dc=example, dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f 

Note

The ldap_cachemgr daemon in Phase 1 updated both of these files which is considered a security hole. In Phase 2, only the information contained in ldap_client_file is updated.

Phase 2 - Secured LDAP Client

The Phase 2 implementation emphasis is on security, so Phase 2 has been dubbed Secured LDAP Client . The distinguishing features of this client are:

• Runs on Solaris 8 and 9 OE (Solaris 8 OE requires a patch).

• Works with both Version 1.0 and Version 2.0 profiles

• Runs over the TLS/SSL secure transport.

• Supports SASL/DIGEST-MD5 authentication.

• Supports sophisticated searches though the Service Search Descriptor (SSD) mechanism.

• Allows for a flexible DIT with object class and attribute mapping.

• Stores proxy credentials locally.

• Password management through shadow database parameters (requires patch).

• Supports the new automount object class.

To take advantage of these enhancements, you need to create and deploy Version 2.0 client profiles. The ldap_gen_profile command has been replaced in Solaris 9 OE with an enhanced version of ldapclient . The following sections provide details on both the content and generation of Version 2.0 profiles.

Version 2 Client Profile

The Version 2.0 is easily identified by the defining object class of DUAConfigProfile . A new set of attributes has been defined for use with this object class, although some serve the same purpose. Notice that the Solaris prefix has been removed from both the object class and its attributes. This is because the client profile has been adopted for platforms other than those running the Solaris OE.

Below is the schema for the Version 2 client profile.

 objectclass DUAConfigProfile    oid       1.3.6.1.4.1.11.1.3.1.2.4    superior       top    requires       cn    allows       attributeMap,       authenticationMethod,       bindTimeLimit,       credentialLevel,       defaultSearchBase,       defaultSearchScope,       defaultServerList,       defaultSearchScope,       followReferrals,       objectclassMap,       preferredServerList,       profileTTL,       searchTimeLimit,       serviceAuthenticationMethod,       serviceCredentialLevel,       serviceSearchDescriptor 

TABLE 4-2 provides an alphabetical listing of the attributes with descriptions.

Table 4-2. Version 2 Profile Attributes

Attribute	Default Value	Description
attributeMap	none	Specifies a mapping from an attribute defined by a service to an attribute in an alternative schema. This can be used to change the default schema used for a given service. The syntax of attributeMap is defined in the profile IETF draft. This option can be specified multiple times. Example: attributeMap: passwd:uid=NTuserName In this example, the LDAP client uses the LDAP attribute NTuserName rather than the default uid for the passwd service.
authenticationMethod	none	Specifies the default authentication method used by all services unless overridden by the serviceAuthenticationMethod attribute. Multiple values can be specified using a comma-separated list. The following methods are available: SIMPLE, SASL/DIGEST-MD5, TLS:SIMPLE, and TLS:SASL/DIGEST-MD5 If credentialLevel is set to anonymous , this attribute is ignored. However, services such as pam_ldap may use this attribute, even if credentialLevel is anonymous .
bindTimeLimit	30	Specifies the maximum time in seconds that a client should spend performing a bind operation. Set this to a positive integer.
certificatePath	/var/ldap	Specifies the certificate path for the location of the certificate database. The value is the path where security database files reside. This is used for TLS support, which is specified in the authenticationMethod and serviceAuthenticationMethod attributes. This is a local attribute.
credentialLevel	No default value	Specifies the credential level the client should use to contact the directory. The credential levels supported are either anonymous or proxy . If a proxy credential level is specified, then the authenticationMethod attribute must be specified to determine the authentication mechanism. Further, if the credential level is proxy and at least one of the authentication methods require a bind DN, the proxyDN and proxyPassword attribute values must be set.
defaultSearchBase	No default value	Specifies the default search base DN. The serviceSearchDescriptor attribute can be used to override the defaultSearchBase for given services. There is no default.
defaultServerList	No default value	Specifies the default list of directory servers to search. Uses same semantics as the preferredServerList attribute.
defaultSearchScope=one sub	one	Specifies the default search scope for the client's search operations. This default can be overridden for a given service by specifying a serviceSearchDescriptor .
domainName	current_ domainname	Specifies the DNS domain name. This becomes the default domain for the machine. This attribute is only used during client initialization and is only local.
followReferrals=true false	true	Specifies the referral setting. A setting of true implies that referrals will be automatically followed, and false results in referrals not being followed.
objectclassMap	none	Specifies a mapping from an object class defined by a service to an object class in an alternative schema. This can be used to change the default schema used for a given service. The syntax of objectclassMap is defined in the profile IETF draft. Example: objectclassMap: passwd:posixAccount=unixAccount In this example, the LDAP client uses the LDAP object class of unixAccount rather than the posixAccount for the passwd service. This is a multi-valued attribute.
preferredServerList	No default value	Specifies a space-separated list of preferred server IP addresses to be contacted before servers specified by the defaultServerList attribute. The port number is optional. If not specified, the default LDAP server port number 389 is used, except when TLS is specified in the authentication method. In this case, the default LDAP server port number is 636 . Fully qualified host names might also be used. If fully qualified host names are used, you must configure nsswitch.conf to use files or DNS , not ldap , to resolve host lookups. If you fail to configure nsswitch.conf properly, then your system or certain processes might hang if they use a hostname value.
profileName	default	Specifies a profile name. For ldapclient init , this attribute is the name of an existing profile which might be downloaded periodically depending on the value of the profileTTL attribute. For ldapclient genprofile , this is the name of the profile to be generated.
profileTTL	43200	Specifies the TTL value in seconds for the client information. This is only relevant if the machine was initialized with a client profile. If you do not want ldap_cachemgr(1M) to attempt to refresh the LDAP client configuration from the LDAP server, set profileTTL to (zero). Valid values are either (zero, for no expiration) or a positive integer in seconds. The default value of 43200 seconds results in 12 hours.
proxyDN	No default value	Specifies the Bind Distinguished Name ( bindDN ) for the proxy identity. This option is required if the credential level is proxy , and at least one of the authentication methods requires a bindDN . This is a local attribute. There is no default value.
proxyPassword	No default value	Specifies the client proxy password. This option is required if the credential level is proxy , and at least one of the authentication methods requires a bindDN . This is a local attribute. There is no default.
searchTimeLimit	30	Specifies the maximum number of seconds allowed for an LDAP search operation. Note: The server might have its own search time limit.
serviceAuthenticationMethod	No default value	Specifies the authentication methods used by a service. Multiple values can be specified by a comma-separated list. The default value is no service authentication methods, in which case, each service would default to the authenticationMethod value. The supported authentications are listed under the AuthenticationMethod attribute. Three services support this feature: passwd-cmd used to define the authentication method used by passwd(1) to change the user's password and other attributes. keyserv used to identify the authentication method used by the chkey(1) and newkey(1M) utilities. pam_ldap defines the authentication method to be used for authenticating users when pam_ldap(5) is configured. If the serviceAuthenticationMethod attribute is not set for any of these services, the authenticationMethod attribute is used to define the authentication method. This is a multi-valued attribute.
serviceCredentialLevel	None	Specifies the credential level used by a service. Multiple values can be specified in a space-separated list. The supported credential levels are anonymous or proxy . At present, no service uses this attribute. This is a multi-valued attribute.
serviceSearchDescriptor	None	Overrides the default base DN for LDAP searches for a given service. The format of the descriptors also allows overriding the default search scope and search filter for each service. The syntax of serviceSearchDescriptor is defined in the profile IETF draft. This is a multi-valued attribute. Example: serviceSearchDescriptor: passwd:ou= people, dc=a1, dc=example, dc=com?one In this example, the LDAP client performs a onelevel search in ou=people , dc=a1 , dc=example , dc=com rather than ou= people , defaultSearchBase for the passwd service.

Generating Version 2 Profiles

The ldapclient command in Solaris 9 OE and ldap_gen_profile command in the Solaris 8 OE naming services patch were enhanced to accept additional command-line arguments. If the genprofile argument is specified, version 2.0 profiles are generated in LDIF format. The ldap_gen_profile command was removed in Solaris 9 OE, with the new ldapclient command taking its place.

Use the following syntax of ldapclient to generate profiles.

  /usr/sbin/ldapclient  [-v  -q]  genprofile -a profileName=   profileName  [  -a attrName=   attrVal  ] 

Example:

  ldapclient genprofile -a profileName=eng \   -a credentialLevel=proxy -a authenticationMethod=sasl/DIGEST-MD5 \   -a bindTimeLimit=20 \   -a defaultSearchBase=dc=eng, dc=example, dc=com \   -a "serviceSearchDescriptor=passwd:ou=people, dc=a1, dc=example, dc=com?one" \   -a serviceAuthenticationMethod=pam_ldap:tls:simple \   -a defaultSearchScope=sub \   -a attributeMap=passwd:uid=employeeNumber \   -a objectclassMap=passwd:posixAccount=unixAccount \   -a followReferrals=false \   -a profileTTL=6000 \   -a preferredServerList=129.100.100.30 \   -a searchTimeLimit=30 \   -a "defaultServerList=128.100.200.1 129.100.100.1 204.34.5.6" > eng.ldif  

The following LDIF is produced by the previous example.

 dn: cn=profileName, ou=profile, dc=eng, dc=example, dc=com ObjectClass: top ObjectClass: DUAConfigProfile defaultServerList: 29.100.200.1 129.100.100.1 204.34.5.6 defaultSearchBase: dc=eng, dc=example, dc=com authenticationMethod: sasl/DIGEST-MD5 followReferrals: FALSE defaultSearchScope: sub searchTimeLimit: 30 preferredServerList: 129.100.100.30 profileTTL: 6000 cn: profileName credentialLevel: proxy serviceSearchDescriptor: passwd:ou=people, dc=a1, dc=example, dccom?one bindTimeLimit: 20 attributeMap: passwd:uid=employeeNumber objectClassMap: passwd:posixAccount=unixAccount serviceAuthenticationMethod: pam_ldap:tls:simple 

The following is a sample ldap_client_file generated from a Version 2.0 profile.

 #  cd /var/ldap  #  more ldap_client_file  # # Do not edit this file manually; your changes will be lost.Please use ldapclient(1M) instead. # NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 129.100.181.98 NS_LDAP_SEARCH_BASEDN= dc=example, dc=com NS_LDAP_AUTH= tls:simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= one NS_LDAP_SEARCH_TIME= 30 NS_LDAP_CACHETTL= 43200 NS_LDAP_PROFILE= ssl NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_BIND_TIME= 10 

The version can be easily identified from the value of NS_LDAP_FILE_VERSION . As with the Phase 1 implementation, the parameters listed in the file contain the NS (name service) prefix. Although some of the parameter names might be the same, the actual attribute in the profile is different. A mapping of parameter names to attributes is shown in TABLE 4-3 .

When you run the idsconfig command, the ldapclient genprofile command runs to create a profile. See Chapter 7 "Performing Administrative Tasks" for procedures on creating additional profiles.

The following code box shows an example of the ldap_client_cred file generated by ldapclient init .

 #  cd /var/ldap  #  more ldap_client_cred  # # Do not edit this file manually; your changes will be lost. Please use ldapclient (1M) instead. # NS_LDAP_BINDDN= cn=proxyagent, ou=profile, dc=example, dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_HOST_CERTPATH= /certs/ldap 

The contents of this file look similar to the Phase 1 file except for the optional NS_LDAP_HOST_CERTPATH parameter. This parameter is used to specify an alternative to the /var/ldap directory for storing the client's certificate database. However, unlike Phase 1, the information contained here is not kept in the client profile. To change it, use the ldapclient mod command.

Example:

 #  ldapclient mod -a certificatePath=/newpath  

More information on updating the local configuration files is contained in Chapter 7 "Performing Administrative Tasks."

Table 4-3. File Parameter Mappings

Parameter	Phase 2 Attribute	Phase 1 Attribute
NS_LDAP_FILE_VERSION	none	none
NS_LDAP_SERVERS	defaultserverlist	solarisldapservers
NS_LDAP_SEARCH_BASEDN	defautlsearchbase	solarissearchbasedn
NS_LDAP_AUTH	authenticationmethod	solarisauthmethod
NS_LDAP_SEARCH_REF	followreferrals	solarissearchreferral
NS_LDAP_SEARCH_SCOPE	defaultsearchscope	solarissearchscope
NS_LDAP_SEARCH_TIME	searchtimelimit	solarissearchtimelimit
NS_LDAP_CACHETTL	profilettl	solariscacheTTL
NS_LDAP_PROFILE	cn	cn
NS_LDAP_CREDENTIAL_LEVEL	credentiallevel	none
NS_LDAP_BIND_TIME	bindTimeLimit	solarisbindtimelimit
NS_LDAP_BINDDN	none	solarisbinddn
NS_LDAP_BINDPASSWD	none	solarisbindpassword
NS_LDAP_HOST_CERTPATH	none	solariscertificatepath

Note

The NS_LDAP_BIND_TIME , NS_LDAP_BINDDN , NS_LDAP_BINDPASSWD , and NS_LDAP_HOST_CERTPATH parameters are stored in local files and not in a client profile.

Defining Authentication Methods

The Phase 2 implementation provides several ways to set up authentication for both the proxy account and for users. These options are:

• none

• SIMPLE

• SASL/DIGEST-MD5

• TLS:SIMPLE

• TLS:SASL/DIGEST-MD5

These options are covered in Chapter 3 "Defining Directory Service Security Architecture" in detail. Before you configure the directory server as a name server, you need to decide what level of authentication is appropriate for your environment. Available levels include:

• Proxy authentication This is recommended for most configurations. With this method, accesses to the naming server are made as a proxy user. A password is required.

• "Proxy anonymous" authentication If clients do not have proxy credentials, they can still gain access as anonymous users. To implement this, set up ACIs that allow anonymous access for certain data. For example, the hosts container could be public while the passwd container requires proxy credentials.

You must also decide on the type of user authentication you want to support. The options here are:

• pam_unix

• pam_ldap

As described in Chapter 4 "Deploying Solaris OE LDAP Naming Services," the type of authentication you choose will dictate the format in which passwords are stored.

Note

You can mix and match the proxy access authentication by setting the serviceAuthenticationMethod attribute.

Mixing Client and Server Versions

In general, you can set up a directory server that supports Phase 1 and Phase 2 clients on either the Solaris 8 or 9 OE. The main difference is the way the software is packaged. In the Solaris 9 OE, the Sun ONE Directory Server software is part of the SUNWCall and SUNWCXall package clusters, so will automatically get loaded when you choose to install everything. To load the Sun ONE Directory Server 5.2 software on Solaris 8 OE, you must download the applicable software from the www.sun.com web site.

Besides installing the directory server software on the Solaris 8 OE, you need the updated ldapclient , ldapaddent , and ldap_gen_profile commands to create Version 2 client profiles and to populate the directory server with naming service data. These utilities are available with the 108993-18 and later versions of the patch.

A single DIT can be configured to support both Phase 1 and Phase 2 clients. However, to share automaps, the old schema definition that defines automaps must be used, and the Phase 2 client needs to map the new schema definition into the old one. More information on this topic can be found in Chapter 5 "Migrating Legacy Data to LDAP." Because there is no technical reasons to maintain Phase 1 clients, it is advisable to upgrade your Phase 1 clients to Phase 2, rather than supporting both.