Go to main content

man pages section 8: System Administration Commands

Exit Print View

Updated: Thursday, June 13, 2019

ldapservercfg (8)


ldapservercfg - prepare a directory server to be populated with data and serve LDAP clients


ldapservercfg [-avq] [-d debug-level] server-type


The ldapservercfg utility is used to configure and populate a directory server to serve LDAP clients.

The ldapservercfg utility uses server-type to specify the type of directory server to be configured. The current supported server types are:


Oracle Unified Directory (version and later)


OpenLDAP (version as shipped with Oracle Solaris)

The directory server is configured to support Oracle Solaris naming services, as defined in /usr/share/lib/ldif/nameservice.ldif, and Kerberos services as defined in kerberos.ldif.

The Directory Information Tree (DIT) structure recommended in RFC2307bis-02 is created.

A default LDAP configuration profile is created to allow automatic configuration of LDAP clients.

Oracle Unified Directory

When the oud option is selected, it is assumed that the Oracle Unified Directory server has been installed and enabled according to the procedures documented in section "Setting Up the Directory Server" in OUD Administration Guide. Ensure the security features such as SSL/TLS, sasl/DIGEST or sasl/GSSAPI are enabled on server side if you want to access the server through corresponding security mechanism.

The tool supplies a default settings for its parameters and allows the user to edit them.


The rights profile OpenLDAP includes the required user, group, authorizations and privileges to properly execute ldapservercfg and to configure and enable the slapd server. It should be started through a profile shell like pfexec.

The tool reads initial parameter values from svc:/network/ldap/server:openldap.

If necessary, the server is converted to use Online Configuration (OLC). The server is configured to accept unencrypted connections on port 389, encrypted connections (with STARTTLS) on port 389, and encrypted connections (using raw TLS) on port 636.

When the server configuration is successful, the configuration properties in svc:/network/ldap/server:openldap are updated.


The following options are supported:

–d debug-level

Specifies the debug-level.


Turns off debugging


Turns on debugging and opens tracing


Function Stacks

–a (OpenLDAP only)

Specifies that the server should be configured with no human interaction by using SMF property values and default values. For more information, see the PARAMETERS section below.

The SMF service svc:/network/ldap/server:openldap uses this option the first time the service is enabled.




Verbose output.

Special Accounts

Four special accounts might be created.

Configuration (OpenLDAP only)
DN: con=config

The configuration account is used to create new databases or load additional schemas. Its password is set the same as the Backend manager password.

Backend (OpenLDAP only)
DN: cn=Manager, <search_base> (default)

The backend account is the manager for the directory. It has complete access to all data in the directory. Its password defaults to the system's root password.

DN: cn=admin, ou=profile, <search_base> (default)

This account is created if shadow update is enabled. Clients use this account to add or modify users.

Users with the solaris.password.assign authorization are able to change other users' passwords only if the client system is configured with an administrator account and password and enableShadowUpdate is set to true by using ldapclient command.

DN: cn=proxyagent, ou=profile, <search_base> (default)

This account is created if proxy access is enabled. Clients will be configured to bind as this account.


For OpenLDAP installations, server configuration parameters can be specified through properties on svc:/network/ldap/server:openldap.

Writing these properties requires the authorization solaris.smf.value.name-service.ldap.server.

Reading the properties in the cred property group requires the authorization solaris.smf.read.name-service.ldap.server.

Base Distinguished Name
Property: profile/default/searchbase
Default: derived from system's DNS domain name

Containers are created relative to this Directory Name (DN).

Clients are instructed to search relative to this DN.

For example, if the domain name is example.com, the default Base Distinguished Name would be dc=example, dc=com.

Directory Manager Account
Property: cred/backend_cn
Default: Manager
Property: cred/backend_passwd
Default: system root password

Name and password hash for the directory manager. Full DN is cn=<name>, <base DN>.

Admin Account
Property: cred/admin_cn
Default: admin
Property: cred/admin_passwd
Default: No default

Name and password hash for an account that clients can use to create and modify users. Full DN is cn=<name>, <base DN>.

This account is created and shadow update is enabled if a password is supplied.

Proxy Account
Property: cred/proxy_cn
Default: proxyagent
Property: cred/proxy_passwd
Default: No default

Name and password hash for an account that clients can use to bind to the directory for read-only routine queries. Full DN is cn=<name>,<base DN>.

This account is created and use of a the proxy account is enabled if a password is supplied.

Directory Layout
Client Authentication
Property: profile/default/authentication_method
Default: tls:simple

This property controls what authentication method the generated LDAP client profile directs client systems to use.

Credential Level
Property: profile/default/cred_level
Default: proxy
Default Server List
Property: profiles/default/default_server_list
Default: server's host name(s), port 636

This property supplies a list of host names that the client should use to access the server.

Schema and DIT Structure

The following schema elements are added to the server if they are not already installed:

Object classes:


Attribute types:


Access control lists are set so that:

| Options         | Results                                           |
|                 | Non-Sensitive           | Sensitive               |
| Proxy? | Admin? | Anon? | Proxy? | Admin? | Anon? | Proxy? | Admin? |
| No[1]  | No     | Read  | -      | -      | No    | -      | -      |
| No     | Yes    | Read  | -      | Write  | No    | -      | Write  |
| Yes    | No     | No    | Read   | -      | No    | Read   | -      |
| Yes    | Yes    | No    | Read   | Write  | No    | Read   | Write  |

Default Configuration

Non-sensitive attributes are:

  • uid

  • uidNumber

  • gidNumber

  • cn

  • objectClass

  • memberUid

  • memberGid

  • loginShell

  • homeDirectory

  • gecos

  • description

  • nisDomain

  • automountMapName

  • SolarisAttrKeyValue

  • SolarisAttrShortDesc

  • SolarisAttrLongDesc

  • SolarisKernelSecurityPolicy

  • SolarisProfileType

  • SolarisProfileId

  • SolarisUserQualifier

  • SolarisProjectId

  • SolarisProjectName

  • SolarisProjectAttr

  • SolarisUserAttrEntry

  • SolarisUserType

  • SolarisAttrReserved1

  • SolarisAttrReserved2

Security-critical attributes are:

  • userPassword

  • shadowLastChange

  • shadowMin

  • shadowMax

  • shadowWarning

  • shadowInactive

  • shadowExpire

  • shadowFlag

In addition, userPassword is writable by the particular user.

As recommended by RFC2307bis-02, the DIT tree under the base DN is laid out with containers for each type of object stored:

     ou=people                      posixAccount
     ou=group                       posixGroup
     ou=services                    ipService
     ou=protocols                   ipProtocol
     ou=rpc                         oncRpc
     ou=hosts                       ipHost
     ou=ethers                      ieee802Device
     ou=networks                    ipNetwork
     ou=netgroup                    nisNetgroup
     nisMapName=...                 nisObject
     automountMapName=...           automountMap

An RFC 4876 profile is created at cn=default, ou=profile, <base DN>.

Exit Status

The following exit values are returned:


Successful completion.


An error occurred.


Example 1 Prompting the User for Input

In the following example, the user is prompted for information to set up OUD.

example# ldapservercfg oud



/etc/openldap/certs/server.pem (OpenLDAP)
/etc/openldap/certs/server.key (OpenLDAP)

A self-signed certificate and private key are generated. They can be replaced as desired.


Contains a list of root certificates that the server trusts. This list should include the certificates used to sign the server's certificate, if a CA-signed certificate is used.


See attributes(7) for descriptions of the following attributes:

Interface Stability

See Also

ldaplist(1), ldap_cachemgr(8), ldapaddent(8), ldapclient(8), resolv.conf(5), attributes(7), ldap(7), idsconfig(8)

RFC 4876: A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents

RFC 2307: An Approach for Using LDAP as a Network Information Service

Oracle Solaris Schema: https://docs.oracle.com/cd/E36784_01/html/E38254/appendixa-5.html