Part V LDAP Naming Service Setup and Administration

This part provides an overview of the LDAP naming service. Additionally, it covers the setup, configuration, administration and troubleshooting of LDAP naming service in the Solaris operating environment, with a focus on the use of iPlanet Directory Server 5.1.

Chapter 12 Introduction to the LDAP Naming Service (Overview/Reference)

The LDAP chapters describe how to set up a Solaris naming client to work with the iPlanet Directory Server 5.1. A brief discussion of generic directory server requirements is in Chapter 18, General Reference.

Though a directory server is not necessarily an LDAP server, in the context of these chapters, the term, “directory server”, is considered synonymous with “LDAP server”.

Audience Assumptions

The LDAP Naming Service chapters are written for system administrators who already have a working knowledge of LDAP. The following is a partial list of concepts with which you must be very familiar prior to deploying a Solaris-based LDAP naming service using this guide.

• LDAP Information Model (entries, objectclasses, attributes, type, values)

• LDAP Naming Model (Directory Information Tree (DIT) structure)

• LDAP Functional Model (search parameters: base object (DN), scope, size limit, time limit, filters (Browsing Indexes for the iPlanet Directory Server), attribute list)

• LDAP Security Model (authentication methods, access control models)

• Overall planning and design of an LDAP directory service, including how to plan the data, design the DIT, design the topology, design the replication, and how to design the security.

Suggested Background Reading

If you need to learn more about any of the aforementioned concepts or would like to study LDAP and the deployment of directory services in general, the following are useful titles.

• Understanding and Deploying LDAP Directory Services by Timothy A. Howes, Ph.D and Mark C. Smith

  In addition to providing a thorough treatment of LDAP directory services, this book includes useful case studies on deploying LDAP at a large university, a large multinational enterprise, and an enterprise with an extranet.

• iPlanet Directory Server 5.1 Deployment Guide, which is included in the documentation CD.

  This guide provides a foundation for planning your directory, including directory design, including schema design, the directory tree, topology, replication, and security. The last chapter provides sample deployment scenarios to help you plan simple deployments as well as complex deployments designed to support millions of users distributed worldwide.

• iPlanet Directory Server 5.1 Administrator's Guide, which is included in the documentation CD.

Additional Prerequisites

If you are transitioning from using NIS+ to using LDAP, refer to the Appendix entitled, “Transitioning from NIS+ to LDAP” in System Administration Guide: Naming and Directory Services (FNS and NIS+) and complete the transition before proceeding with these chapters.

If you need to Install the iPlanet Directory Server 5.1, refer to the iPlanet Directory Server 5.1 Installation Guide.

LDAP Naming Service Versus Other Naming Services

Below is a quick comparison between FNS, DNS, NIS, NIS+ and LDAP naming services.

Using Fully Qualified Domain Names

One significant difference between an LDAP client and a NIS or NIS+ client is that an LDAP client always returns a Fully Qualified Domain Name (FQDN) for a host name, similar to those returned by DNS. For example, if your domain name is

west.example.net

both gethostbyname() and getipnodebyname() return the FQDN version when looking up the hostname server.

server.west.example.net

Also if you use interface specific aliases like server-#, a long list of fully qualified host names is returned. If you are using host names to share file systems or have other such checks you need to account for it. This is especially true if you assume non-FQDN for local hosts and FQDN only for remote DNS resolved hosts. If you setup LDAP with a different domain name from DNS you might be surprised when the same host has two different FQDNs, depending on the lookup source.

Advantages of LDAP Naming Service

• LDAP gives you the ability to consolidate information by replacing application-specific databases; reduces the number of distinct databases to be managed

• LDAP allows for more frequent data synchronization between masters and replicas

• LDAP is multi-platform and multi-vendor compatible

Disadvantages of LDAP Naming Service

The following are some disadvantages to using LDAP instead of other naming services.

• There is no support for pre-Solaris 8 clients

• An LDAP server cannot be its own client

• Setting up and managing an LDAP naming service is more complex and requires careful planning

A directory server (an LDAP server) cannot be its own client. In other words, you cannot configure the machine that is running the directory server software to become an LDAP naming service client.

New LDAP Naming Service Features for Solaris 9

• Simplified configuration of LDAP directory server setup using idsconfig

• A more robust security model, which supports strong authentication, TLS encrypted sessions. A client's proxy credentials are NO LONGER stored in a client's profile on the directory server

• The ldapaddent command allows you to populate and dump data onto the server

• Service Search Descriptors and Attribute Mapping

• New profile schema

Transitioning from NIS+ to LDAP

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment.

For more information, visit http://www.sun.com/directory/nisplus/transition.html.

For information on transitioning from NIS+ to LDAP, see the Appendix, “Transitioning From NIS+ to LDAP” in System Administration Guide: Naming and Directory Services (FNS and NIS+).

LDAP Naming Service Setup (Task Map)

Chapter 13 Basic Components and Concepts (Overview)

This chapter covers the following topics.

• Default Schema

• Default Directory Information Tree (DIT)

• Service Search Descriptors (SSDs) and Schema Mapping

• Client Profiles

• ldap_cachemgr Daemon

• LDAP Naming Service Security Model

Default Directory Information Tree (DIT)

By default, Solaris LDAP clients access the information assuming that the DIT has a given structure. For each domain supported by the LDAP server, there is an assumed subtree with an assumed structure. This default structure, however, can be overridden by specifying Service Search Descriptors (SSDs). For a given domain, the default DIT will have a base container that holds a number of subtrees containing entries for a specific information type. See the following table for the names of these subtrees.

Default Schema

Schemas are definitions describing what types of information can be stored as entries in an LDAP directory. To support Solaris 9 LDAP naming clients, the directory server's schema might need to be extended. Detailed information about IETF and Solaris specific schemas is included in Chapter 18, General Reference. The various RFCs can also be accessed on the IETF web site http://www.ietf.org.

Service Search Descriptors (SSDs) and Schema Mapping

If you use schema mapping, you must do so in a very careful and consistent manner.

As discussed above, the Solaris LDAP naming service expects, by default, the DIT to be structured in a certain way. If you wish, you can instruct the Solaris LDAP naming service to search in other locations than the default locations in the DIT. Additionally, you can specify that different attributes and object classes be used in place of those specified by the default schema. For a list of default filters see Default Filters Used By Naming Services.

SSDs

The serviceSearchDescriptor attribute defines how and where an LDAP naming service client should search for information for a particular service. The serviceSearchDescriptor contains a service name, followed by one or more semicolon-separated base-scope-filter triples. These base-scope-filter triples are used to define searches only for the specific service and are searched in order. If multiple base-scope-filters are specified for a given service, then when that service looks for a particular entry, it will search in each base with the specified scope and filter.

Note that the default location is not searched for a service (database) with a SSD unless it is included in the SSD. Unpredictable behavior will result if multiple SSDs are given to a service.

In the following example, the Solaris LDAP naming service client performs a one level search in ou=west,dc=example,dc=com followed by a one level search in ou=east,dc=example,dc=com for the passwd service. To lookup the passwd data for a user's username, the default LDAP filter (&(objectClass=posixAccount)(uid=username)) is used for each BaseDN.

serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east,
dc=example,dc=com 

In the following example, the Solaris LDAP naming service client would perform a subtree search in ou=west,dc=example,dc=com for the passwd service. To lookup the passwd data for user username, the subtree ou=west,dc=example,dc=com would be searched with the LDAP filter (&(fulltimeEmployee=TRUE)(uid=username)).

serviceSearchDescriptor: passwd:ou=west,dc=example,
dc=com?sub?fulltimeEmployee=TRUE

It is also possible to associate multiple container with a particular service type.

For example, the service search descriptor

defaultSearchBase: dc=example,dc=com
serviceSearchDescriptor: \
passwd:ou=myuser;ou=newuser,ou=extuser,dc=example,dc=com

specifies that the three containers, ou=myuser,dc=example,dc=com, ou=newuser,dc=example,dc=com, and ou=extuser,dc=example,dc=com are searched for the password entries. Note that a trailing ',' implies that the defaultSearchBase is appended to the relative base in the SSD.

Attribute Map

The Solaris LDAP naming service allows one or more attribute names to be remapped for any of its services. (The Solaris LDAP client uses the well-known attributes documented in Chapter 18, General Reference.) If you map an attribute, you must be sure that the attribute has the same meaning and syntax as the original attribute. Note that mapping the userPassword attribute may cause problems.

There are a couple of reasons you might want to use schema mappings.

• You want to map attributes in an existing directory server

• If you have user names that differ only in case, you must map the uid attribute, which ignores case, to an attribute that does not ignore case

The format is service:attribute-name=mapped-attribute-name.

If you wish to map more than one attribute for a given service, you can define multiple attributeMap attributes.

In the following example, the employeeName and home attributes would be used whenever the uid and homeDirectory attributes would be for the passwd service.

attributeMap: passwd:uid=employeeName
attributeMap: passwd:homeDirectory=home

There exists one special case where you can map the passwd service's gecos attribute to several attributes. The following is an example.

attributemap: gecos=cn sn title

The above maps the gecos values to a space-separated list of the cn, sn and title attribute values.

objectClass Map

The Solaris LDAP naming service allows object classes to be remapped for any of its services. If you wish to map more than one object class for a given service, you can define multiple objectclassMap attributes. In the following example, the myUnixAccount object class is used whenever the posixAccount object class is used.

objectclassMap: passwd:posixAccount=myUnixAccount

Client Profiles

To simplify Solaris client setup, and avoid having to reenter the same information for each and every client, create a single client profile on the directory server. This way, a single profile defines the configuration for all clients configured to use it. Any subsequent change to the profile attributes is propagated to the clients at a rate defined by the refresh interval.

These client profiles should be stored in a well-known location on the LDAP server. The root DN for the given domain must have an object class of nisDomainObject and a nisDomain attribute containing the client's domain. All profiles are located in the ou=profile container relative to this container. These profiles should be readable anonymously.

Client Profile Attributes

The following lists the Solaris LDAP client's profile attributes, which can be set automatically when you run idsconfig. See Initializing a Client Manually for information on how to set a client profile manually.

Local Client Attributes

The following table lists the client attributes that can be set locally using ldapclient.

If the BaseDN in an SSD contains a trailing comma, it is treated as a relative value of the defaultSearchBase. The values of the defaultSearchBase is appended to the BaseDN before a search is performed.

ldap_cachemgr Daemon

ldap_cachemgr(1M) is a daemon that runs on LDAP client machines. It performs the following key functions.

• It gains access to the configuration files, running as root

• It refreshes the client configuration information stored in the profiles on the server and pulls this data from the clients

• It maintains a sorted list of active LDAP servers to use

• It improves lookup efficiency by caching some common look-up requests submitted by various clients

• It improves the efficiency of host lookups

The ldap_cachemgr must be running at all times in order for LDAP naming services to work.

Refer to ldap_cachemgr(1M) for detailed information.

LDAP Naming Service Security Model

Introduction

The Solaris LDAP naming service uses the LDAP repository as a source of both a naming service and as an authentication service. This section discusses the concepts of client identity, authentication methods, pam_ldap and pam_unix modules, and password management.

To access the information stored in the LDAP repository, clients can first establish identity with the directory server. This identity can be either anonymous or as an object recognized by the LDAP server. Based on the client's identity and the server's Access Control Information (ACI), the LDAP server will allow the client to read or write directory information. For more information on ACIs, consult the iPlanet Directory Server 5.1 Administrator's Guide.

If the client is connecting as anything other than anonymous for any given request, the client must prove its identity to the server using an authentication method supported by both the client and server. Once the client has established its identity, it can then make the various LDAP requests.

Keep in mind that there is a distinction between how the naming service and the authentication service (pam_ldap) authenticate to the directory. The naming service will read various entries and their attributes from the directory based on predefined identity. The authentication service (pam_ldap) which establishes whether the user has entered the correct password by using that user's name and password to authenticate to the LDAP server.

Transport Layer Security (TLS)

TLS can be used to secure communication between an LDAP client and the directory server, providing both privacy and data integrity. The TLS protocol is a super set of the Secure Sockets Layer (SSL) protocol. The Solaris LDAP naming service supports TLS connections. Be aware that using SSL will add load to the directory server and the client.

You will need to setup your directory server for SSL. See the iPlanet Directory Server 5.1 Administrator's Guide for more information on setting up the iPlanet Directory Server 5.1 for SSL. You will also need to setup your LDAP client for SSL.

In order to use TLS for the Solaris LDAP naming service, the directory server must use the default ports, 389 and 636, for LDAP and SSL, respectively. If your directory server does not use these ports, you cannot use TLS at this time.

See TLS Security Setup for more information.

Assigning Client Credential Levels

LDAP naming service clients authenticate to the LDAP server according to a credential level. LDAP clients can be assigned three possible credential levels with which to authenticate to a directory server.

• anonymous

• proxy

• proxy anonymous

Anonymous

If you use anonymous access, you only have access to data that is available to everyone. Also, you should consider the security implications. Allowing anonymous access for certain parts of the directory implies that anyone with access to the directory will be able to perform those operations. If you are using an anonymous credential level, you will need to allow read access to all the LDAP naming entries and attributes.

Allowing anonymous write to a directory should never be done, as anyone could change information in the DIT to which they have write access, including another user's password, or their own identity.

The iPlanet Directory Server 5.1 allows you to restrict access based on IP addresses, DNS name, authentication method and time-of-day. You might want to limit access with further restrictions. See “Managing Access Control” in the iPlanet Directory Server 5.1 Administrator's Guide for more information.

Proxy

The client authenticates or binds to the directory using a proxy account. This proxy account can be any entry that is allowed to bind to the directory. This proxy account needs sufficient access to perform the naming service functions on the LDAP server. You will need to configure the proxyDN and proxyPassword on every client using the proxy credential level. The encrypted proxyPassword will be stored locally on the client. You can setup different proxies for different groups of clients. For example, you can configure a proxy for all the sales clients to access both the company-wide-accessible and sales directories and directories, while preventing sales clients from accessing human resource directories with payroll information. Or, in the most extreme cases, you can either assign different proxies to each client or assign just one proxy to all clients. A typical LDAP deployment would probably lie between the two extremes. Consider the choices carefully. Too few proxy agents might limit the your ability to control user access to resources. However, having too many proxies complicates the setup and maintenance of the system. You need to grant the appropriate rights to the proxy user. This will vary depending on your environment. See the following section for information on how to determine which authentication method makes the most sense for your configuration.

If the password changes for a proxy user, you will need to update it on every client that uses that proxy user. If you use password aging on LDAP accounts, be sure to turn it off for proxy users.

Be aware that the proxy credential level applies to all users and processes on any given machine. If two users need to use different naming policies, they must use different machines.

In addition, if clients are using a proxy credential to authenticate, the proxyDN must have the same proxyPassword on all of the servers.

proxy anonymous

proxy anonymous is a multi-valued entry, in that more than one credential level is defined. A client assigned the proxy anonymous level will first attempt to authenticate with its proxy identity. If the client is unable to authenticate as the proxy user for whatever reason (user lock out, password expired, for example), then the client will use anonymous access. This might lead to a different level of service, depending on how the directory is configured.

Credential Storage

If you configure a client to use a proxy identity, the client saves its proxyDN and proxyPassword in /var/ldap/ldap_client_cred. For the sake of increased security, this file is restricted to root-access only and the value of proxyPassword is encrypted. While past LDAP implementations have stored proxy credentials in a client's profile, the Solaris 9 LDAP does not. Any proxy credentials set using ldapclient during initialization are stored locally. This results in improved security surrounding a proxy's DN and password information. See Chapter 16, Client Setup (Task) for more information on setting up client profiles.

Choosing Authentication Methods

When you assign the proxy or proxy-anonymous credential level to a client, you also need to select a method by which the proxy authenticates to the directory server. By default, the authentication method is none which implies anonymous access. The authentication method may also have a transport security option associated with it.

The authentication method, like the credential level, may be multi-valued. For example, in the client profile you could specify that the client first tries to bind using the simple method secured by TLS. If unsuccessful, the client would try to bind with the sasl/digest-MD5 method. The authenticationMethod would then be tls:simple;sasl/digest-MD5.

The LDAP naming service supports some Simple Authentication and Security Layer (SASL) mechanisms. These mechanisms allow for a secure password exchange without requiring TLS. However, these mechanisms do not provide data integrity or privacy. See RFC 2222 for information on SASL.

The following authentication mechanisms are supported.

• none

  The client does not authenticate to the directory. This is equivalent to the anonymous credential level.

• simple

  If the client machine uses the simple authentication method, it binds to the server by sending the user's password in the clear. The password is thus subject to snooping. The primary advantage of using the simple authentication method is that all directory servers support it and that it is easy to set up.

• sasl/digest-MD5

  The client's password is protected during authentication, but the session is not encrypted. Some directory servers, including the iPlanet Directory Server 5.1, also support the sasl/digest-MD5 authentication method. The primary advantage of digest-MD5 is that the password does not go over the wire in the clear during authentication and therefore is more secure than the simple authentication method. See RFC 2831 for information on digest-MD5. digest-MD5 is considered an improvement over cram-MD5 for its improved security.

  When using sasl/digest-MD5, the authentication is secure, but the session is not protected.

• sasl/cram-MD5

  In this case, the LDAP session is not encrypted, but the client's password is protected during authentication, as authentication is performed using sasl/cram-MD5.

  See RFC 2195 for information on the cram-MD5 authentication method, which is supported by some, but not all directory servers. For instance, the iPlanet Directory Server 5.1 does not supportcram-MD5.

• tls:simple

  The client binds using simple method and the session is encrypted. The password is protected.

• tls: sasl/cram-MD5

  The LDAP session is encrypted and the client authenticates to the directory server using sasl/cram-MD5.

• tls:sasl/digest-MD5

  The LDAP session is encrypted and the client authenticates to the directory server using sasl/digest-MD5.

iPlanet Directory Server 5.1 requires passwords to be stored in the clear in order to use digest-MD5. If the authentication method is set to sasl/digest-MD5 or tls:sasl/digest-MD5, then the passwords for the proxy user will need to be stored in the clear. Be careful that the userPassword attribute has the proper ACIs if it is stored in the clear, so that it is not readable.

Authentication and Services

The authentication method can be specified for a given service in the serviceAuthenticationMethod attribute. The following services currently support this.

• passwd-cmd

  This service is used by passwd(1) to change the login password and password attributes.

• keyserv

  This service is used by the chkey(1) and newkey(1M) utilities to create and change a user's Diffie-Hellman key pair.

• pam_ldap

  This service is used for authenticating users with pam_ldap.

If the service does not have a serviceAuthenticationMethod set, it will default to the value of the authenticationMethod attribute.

The following example shows a section of a client profile in which the users will use sasl/digest-MD5 to authenticate to the directory server, but will use an SSL session to change their password.

serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5
serviceAuthenticationMethod=passwd-cmd:tls:simple

Pluggable Authentication Methods

By using the PAM framework, you can choose among several authentication services. You can use either pam_unix or pam_ldap in conjunction with LDAP.

Because of its increased flexibility and support of stronger authentication methods, the use of pam_ldap is recommended.

pam_unix

If you have not changed the pam.conf(4) file, pam_unix is enabled by default. pam_unix follows the traditional model of UNIX authentication, which means that

1. The client retrieves the user's encrypted password from the name service.

2. The user is prompted for his password.

3. The user's password is encrypted.

4. The client compares the two encrypted passwords to determine if the user should be authenticated or not.

• The password must be stored in UNIX crypt format and not in any other encryption methods, including clear.

• The userPassword attribute must be readable by the name service.

  For example, if you set the credential level to anonymous, then anyone must be able to read the userPassword attribute. Similarly, If you set the credential level to proxy, then the proxy user must be able to read the userPassword attribute.

pam_unix is not compatible with sasl authentication method digest-MD5, since the iPlanet Directory Server 5.1 requires passwords to be stored in the clear in order to use digest-MD5, but pam_unix requires the password be stored in crypt format.

pam_ldap

When using pam_ldap, the user binds to the LDAP server. The authentication method is defined in pam_ldap's serviceAuthenticationMethod parameter if one exists. Otherwise, the authenticationMethod is used by default.

If pam_ldap is able to bind to the server with the user's identity and supplied password, it authenticates the user.

pam_ldap does not read the userPassword attribute. Therefore, there is no need to grant access to read the userPassword attribute unless there are other clients using pam_unix. pam_ldap does not support the none authentication method. Thus, you must define the serviceAuthenticationMethod or the authenticationMethod attributes in order for clients to use pam_ldap.

If the simple authentication method is used, the userPassword attribute can be read on the wire by third parties.

See An example pam.conf file for pam_ldap.

PAM and Changing Passwords

Use the passwd(1) to change a password. In order to change the password, the userPassword attribute must be writeable by the user. Remember that the serviceAuthenticationMethod for passwd-cmd will override the authenticationMethod for this operation. Depending on the authentication used, the current password might be un-encrypted on the wire.

In the case of pam_unix the new userPassword attribute is encrypted using UNIX crypt and tagged before being written to LDAP. Therefore, the new password is encrypted on the wire, regardless of the authentication method used to bind to the server.

For pam_ldap, when a password is changed, the new password is un-encrypted. Therefore, to insure privacy, you need to use TLS. If TLS is not used, the new userPassword will be subject to snooping.

When setting the password with pam_ldap with the iPlanet Directory Server 5.1, the password is encrypted using the serverStrorageScheme (as it is untagged). See “User Account Management” in the iPlanet Directory Server 5.1 Administrator's Guide for additional information about the passwordStorageScheme attribute.

You need to consider the following when setting the passwordStorageScheme attribute. If a NIS, NIS+, or another client using pam_unix is using LDAP as a repository, then passwordStorageScheme needs to be crypt. Also, if using pam_ldap with sasl/digest-MD5 with the iPlanet Directory Server 5.1, passwrodStorageScheme must be set to clear.

Password Management

Solaris LDAP naming services does not currently support the password management features in iPlanet Directory Server 5.1.

Chapter 14 Planning for the LDAP Naming Service

This chapter discusses the high-level planning you should do before beginning the server and client setup and installation process.

This chapter covers the following topics.

• Overview

• Planning the Network Model

• Planning the Directory Information Tree (DIT)

• Replica Servers

• Planning the Security Model

• Planning Client Profiles and Default Attribute Values

• Planning the Data Population

Overview

The LDAP client profile is a collection of configuration information an LDAP client uses to access the LDAP naming service information on the supporting LDAP server to provide LDAP naming services. In this chapter, we will use this center piece of the LDAP configuration to discuss the planning of the various aspects of the LDAP naming services. These include the network model, the Directory Information Tree, the security model, the default values of the various profile attributes, and finally, the preparation for data population.

Planning the Network Model

For availability and performance considerations, it would be best if each subnet of the company wide network has its own LDAP server to service all the LDAP clients in the subnet. Only one of them needs to be a master LDAP server. The rest could all be replicas of the master server.

To plan for the network configuration, consider how many servers are available, how would a client be able to get to the servers, and in what order should the servers be accessed. If there is one per subnet, we could use the defaultServerList attribute to list all the servers and have the LDAP client sort and manipulate the access order. If the servers need to be accessed in certain order due to speed or data management reasons, then we should use the preferredServerList attribute to define the fixed order of accessing the servers. Note that you might not want to put the master server on either of these lists to reduce the load on the master server.

In addition, you may find three more attributes worth consideration when planning for the server and network configuration. The bindTimeLimit attribute can be used to set the time-out value for a TCP connect request, the searchTimeLimit attribute can be used to set the time-out value for an LDAP search operation, and the profileTTL attribute is for controlling how often the LDAP client should download its profile from the servers. For a slow or unstable network, the bindTimeLimit and searchTimeLimit attribute may need a larger value than the defaults. For early stage testing of the deployment, you may want to reduce the value of the profileTTL attribute to have the clients pick up the frequent changes made to the profile stored in the LDAP servers.

Planning the Directory Information Tree (DIT)

As mentioned in the previous chapter, the LDAP naming services has a default Directory Information Tree (DIT) and the associated default schema. For example, the ou=people container contains the user account, password, and shadow information. The ou=hosts container contains information about systems in the network. Each entry in the ou=people container would be of objectclass posixAccount and shadowAccount. The default DIT is a well designed directory structure and is based on open standards. It should be sufficient for most of the naming service needs, and is recommended to be used without changes. If you choose to use the default DIT, the only thing you need to decide is from which node (base DN) on in the directory tree the naming service information will be searched for a given domain. This node is specified with the defaultSearchBase attribute. Additionally, you might want to set the defaultSearchScope attribute to tell the clients the scope of search a naming service lookup should perform. Is it just searching one level under the DN (one), or the entire subtree under the DN (sub)?

There are times, however, that more flexibility is needed for the LDAP naming service to either work with an existing DIT or handle a more complicated DIT with naming service data scattered around the directory tree. For example, user account entries may exist in different part of the tree. The serviceSearchDescriptor, attributeMap, and objectclassMap attributes in the client profile are designed to handle these situations.

A service search descriptor can be used to override the default search base, search scope, and search filter for a particular service. See Service Search Descriptors (SSDs) and Schema Mapping.

AttributeMap and ObjectclassMap attributes provide a way for schema mapping. They make it possible for the LDAP naming services to work with an existing DIT. You can map the posixAccount objectclass to an existing objectclass, myAccount, for example and attributes in the posixAccount objectclass to attributes in the myAccount objectclass.

Multiple Directory Servers

Multiple LDAP servers can serve one DIT. For example, some subtrees of the DIT reside on other LDAP servers. In this case, an LDAP server may refer the LDAP client to a different server for the naming data it knows about but is not in its own database. If you plan such a DIT configuration, you should set the clients' profile attribute followReferrals to indicate to the LDAP naming service to follow server referrals to continue naming service lookups. However, it is best to have all naming data for a given domain reside on a single directory server, if at all possible.

Referrals can be useful if you want to have clients access read-only replicas most of the time and follow referrals to a read/write master server only when necessary. In this way, the master server does not get overloaded with requests that could be handled by replicas.

Data Sharing With Other Applications

To make best use of LDAP, you should have a single LDAP entry for each logical entry. For example, for a user you can have not only company white page information, but also Solaris account information, and possibly application specific data. Since the posixAccount and shadowAccount are auxiliary object classes, they can be added to any entry in the directory. This will require careful planning, setup and administration.

Choosing the Directory Suffix

See the iPlanet Directory Server 5.1 Configuration chapter for information on how to chose an appropriate directory suffix.

Replica Servers

There are three different strategies to employ when setting up your replica servers.

• Single-master replication

• Floating-master replication

• Multi-master replication

Single-master

With single-master replication, only one master server for any given partition or non-partitioned network holds writable copies of directory entries. Any replica servers have read-only copies of the directory entries. While both replicas and masters can perform searches, compares and bind operations, only the master server can perform write operations.

The potential disadvantage to the single-master replication strategy is that master server is a single point of failure. If the master server goes down, none of the replicas can process write operations.

Floating-master

The floating master strategy is similar to the single master strategy in that there is only one master server with write capabilities at any given time for a given partition or non-partitioned network. However, when implementing the floating-master strategy, when the master server goes down, a replica is automatically transformed into a master server by way of an algorithm.

One potential disadvantage to the floating-master replication strategy is that if your network becomes partitioned and replicas on either side of the partition become masters, the process of reconciling the new masters can be very complicated if the network is rejoined.

Multi-master

With multi-master replication, there are multiple master servers with their own read-write copies of the directory entry data. While the multi-master strategy eliminates the problem of having a single point of failure, update conflicts can occur between servers. In other words, if an entry's attribute is modified around the same time on two masters, an update conflict resolution policy, such as “last writer wins” must be in place.

Refer to the iPlanet Directory Server 5.1 Administrator's Guide for information on how to set up replica servers.

Planning the Security Model

To plan for the security model, you should first consider what identity the LDAP client should be using to talk to the LDAP server, and if you want strong authentication to protect the user password flow across the wire, and/or if it is needed to encrypt the session between the LDAP client and the LDAP server to protect the LDAP data transmitted.

The credentialLevel and authenticationMethod attributes in the profile are used for this. There are three possible credential levels for credentialLevel: anonymous, proxy, and proxy anonymous. See LDAP Naming Service Security Model for a detailed discussion of LDAP naming service security concepts.

The main decisions you need to make when planning your security model are the following.

• What credential level and authentication methods will LDAP clients use?

• Will you use TLS?

• Do you need to be backwards compatible with NIS or NIS+? In other words, will clients use pam_unix or pam_ldap?

• What will the servers' passwordStorageScheme attribute settings be?

• How will you set up the Access Control Information? For more information on ACIs, consult the iPlanet Directory Server 5.1 Administrator's Guide.

Planning Client Profiles and Default Attribute Values

By going through the previous planning steps (network model, DIT, and security model), you should have some ideas of what the values for the following profile attributes.

• cn

• defaultServerList

• preferredServerList

• bindTimeLimit

• searchTimeLimit

• profileTTL

• defaultSearchBase

• defaultSearchScope

• serviceSearchDescriptor

• attributeMap

• objectclassMap

• followReferrals

• credentialLevel

• authenticationMethod

• serviceCredentialLevel

• serviceAuthenticationMethod

Out of the above attributes, only the cn, the defaultServerList and defaultSearchBase are required attributes. They have no default values. The rest are optional, and some have default values.

See Chapter 16, Client Setup (Task) for more information on setting up LDAP clients.

Planning the Data Population

To populate the LDAP server with the LDAP naming service data, after the LDAP server has been configured with the proper DIT and schema, it is best to use the new ldapaddent tool. This tool will create entries in LDAP containers from their corresponding /etc files. It can be used to populate data into the containers for the following type of data: aliases, auto_*, bootparams, ethers, group, hosts (including IPv6 addresses), netgroup, netmasks, networks, passwd, shadow, protocols, publickey, rpc, and services.

By default, ldapaddent reads from the standard input and adds this data to the LDAP container associated with the database specified on the command line. But an input file from which data should be read can be specified using the -f option.

The entries are stored in the directory based on the client's configuration, thus the client must be configured to use the LDAP naming service.

For better performance, the recommended order in which the databases should be loaded is as follows.

1. passwd database followed by shadow database

2. networks database followed by netmasks database

3. bootparams database followed by ethers database

Note that when adding automounter entries, the database name is in the form of auto_* (for example, auto_home).

If you have /etc files from different hosts to be added to the LDAP server, you can either merge all of them into the same /etc file and then use ldapaddent on one host to add, or perform ldapaddent on the different hosts one by one, with the expectation that all these hosts are already configured as a LDAP client.

If your naming service data is already in a NIS server, and you want to move the data to the LDAP server for LDAP naming services, use the ypcat (or niscat) command to dump the NIS map into files and run ldapaddent against these files to add the data to the LDAP server.

For example, to add hosts information to the LDAP server do the following.

Example 14–1 How to add NIS information to an LDAP server

1. Become superuser.

2. Run ldapaddent.

   # ldapaddent -h ldap_server_name -D directory manager -f hosts.data \ hosts

In the above example, the directory_manager password would be stored in the clear when using simple authentication.

You can also populate your directory server with NIS+ data using the proper settings in rpc.nisd. See the Appendix, “Transitioning from NIS+ to LDAP” in System Administration Guide: Naming and Directory Services (FNS and NIS+).

Chapter 15 iPlanet Directory Server 5.1 Setup (Tasks)

This chapter describes how to configure the iPlanet Directory Server 5.1 to support a network of Solaris LDAP naming service clients. The information is specific to the iPlanet Directory Server 5.1.

You must have already performed all the procedures described in Chapter 11 before you can configure the iPlanet Directory Server 5.1 to work with Solaris LDAP clients.

A directory server (an LDAP server) cannot be its own client.

This chapter covers the following topics.

• Configuring iPlanet Directory Server 5.1 Using idsconfig

• Using Service Search Descriptors to Modify Client Access to Various Services

• Running idsconfig

• Populating the Directory Server Using ldapaddent

• Managing Printer Entries

• Populating the Server with Additional Profiles

Configuring iPlanet Directory Server 5.1 Using idsconfig

Creating a Checklist Based on Your Server Installation

During the server installation process, you will have defined crucial variables, with which you should create a checklist similar to the one below before launching idsconfig. You can use the blank checklist provided in Blank Checklists.

The information included below will serve as the basis for all examples that follow in the LDAP related chapters. The example domain is of an widget company, Example, Inc. with stores nationwide. The examples will deal with the West Coast Division, with the domain west.example.com

If you are using hostnames in defining defaultServerList or preferredServerList, you MUST ensure LDAP is not used for hosts lookup. This means ldap must not be in /etc/nsswitch.conf hosts line.

Client profiles are defined per domain. At least one profile must be defined for a given domain.

Attribute Indices

idsconfig indexes the following list of attributes for improved performance.

Schema Definitions

idsconfig(1M) automatically adds the necessary schema definitions. Unless you are very experienced in LDAP administration, do not manually modify the server schema. See Chapter 18, General Reference for an extended list of schemas used by the LDAP naming service.

Using Browsing Indices

The browsing index functionality of the iPlanet Directory Server, otherwise known as the virtual list view, provides a way in which a client can view a select group or number of entries from very long list, thus making the search process less time consuming for each client. Browsing Indexes provide optimized, predefined search parameters with which the Solaris LDAP naming client can access specific information from the various services more quickly. Keep in mind that if you do not create browsing indexes, the clients may not get all the entries of a given type because the server limits for search time or number of entries might not be enforced.

Indexes are configured on the directory server and the proxy user has read access to these indexes.

Refer to the iPlanet Directory Server Administrators Guide 5.1 for information on configuring indexes on the iPlanet Directory Server as well as the performance cost associated with using them.

In the following example, note that the -n option denotes the name of the database with the entries to be indexed and and the -s option denotes the instance of the directory server.

idsconfig creates all the default VLV indices.

directoryserver -s ipdserver vlvindex -n userRoot -T getgrent
directoryserver -s ipdserver vlvindex -n userRoot -T gethostent
directoryserver -s ipdserver vlvindex -n userRoot -T getnetent
directoryserver -s ipdserver vlvindex -n userRoot -T getpwent
directoryserver -s ipdserver vlvindex -n userRoot -T getrpcent
directoryserver -s ipdserver vlvindex -n userRoot -T getspent

Using Service Search Descriptors to Modify Client Access to Various Services

A service search descriptor (SSD) changes the default search request for a given operation in LDAP to a search you define. SSDs are particularly useful if, for example, you have been using LDAP with customized container definitions or another operating system and are now transitioning to Solaris 9. Using SSDs, you can configure Solaris 9 LDAP naming services without having to change your existing LDAP database and data.

Setting Up SSDs Using idsconfig

Assume your predecessor at Example, Inc. had configured LDAP, storing users in ou=Users container. You are now upgrading to Solaris 9. By definition, Solaris 9 LDAP assumes that user entries are stored in ou=People container. Thus, when it comes to searching the passwd service, LDAP will search the ou=people level of the DIT and not find the correct values.

One rather laborious solution to the above problem would be to completely overwrite Example, Inc.'s existing DIT and to rewrite all the exiting applications on Example, Inc.'s network so that they are compatible with the new LDAP naming service. A second, far preferable solution would be to use an SSD that would tell LDAP to look for user info in an ou=Users container instead the default ou=people container.

You would define the necessary SSD during the configuration of the iPlanet Directory Server 5.1 using idsconfig. The prompt line appears as follows.

Do you wish to setup Service Search Descriptors (y/n/h? y
 A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] a
Enter the service id: passwd
Enter the base: service ou=user,dc=west,dc=example,dc=com
Enter the scope: one[default]
  A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] p

Current Service Search Descriptors:
==================================
Passwd:ou=Users,ou=west,ou=example,ou=com?

Hit return to continue.

  A  Add a Service Search Descriptor
  D  Delete a SSD
  M  Modify a SSD
  P  Display all SSD's
  H  Help
  X  Clear all SSD's

  Q  Exit menu
Enter menu choice: [Quit] q

Running idsconfig

You do not need special rights to run idsconfig, nor do you need to be an LDAP naming client. Remember to create a checklist as mentioned in Creating a Checklist Based on Your Server Installation in preparation for running idsconfig. You don not have to run idsconfig from a server or an LDAP naming service client machine. You can run idsconfig from any Solaris machine on the network.

idsconfig sends the Directory Manager's password in the clear. If you do not want this to happen, you must run idsconfig on the directory server itself, not on a client.

How to Configure the iPlanet Directory Server Using idsconfig

1. Make sure the target iPlanet Directory Server 5.1 is up and running.

2. Run idsconfig.

   # /usr/lib/ldap/idsconfig

3. Answer the questions prompted. Note that 'no' [n] is the default user input. If you need clarification on any given question, type

   h

   and a brief help paragraph will appear.

Refer to the following example run of idsconfig using the definitions listed in the server and client checklists at the beginning of this chapter in Creating a Checklist Based on Your Server Installation. It is an example of a simple setup, without modifying many of the defaults. The most complicated method of modifying client profiles is by creating SSDs. Refer to Using Service Search Descriptors to Modify Client Access to Various Services for a detailed discussion.

A carriage return sign after the prompt means that you are accepting the [default] by hitting enter.

Example 15–1 Running idsconfig for the Example, Inc. Network

(sysadmin@test) [3:10pm] ns_ldap [31] % sh idsconfig.sh

It is strongly recommended that you BACKUP the directory server
before running idsconfig.sh.

Hit Ctrl-C at any time before the final confirmation to exit.

Do you wish to continue with server setup (y/n/h)? [n] Y

Enter the iPlanet Directory Server's (iPlanet Directory Server) 
hostname to setup: IPDSERVER

Enter the port number for iPlanet Directory Server (h=help): [389] 
Enter the directory manager DN: [cn=Directory Manager] 
Enter passwd for cn=Directory Manager : 
Enter the domainname to be served (h=help): [west.example.com] 
Enter LDAP Base DN (h=help): [dc=west,dc=example,dc=com] 
Enter the profile name (h=help): [default] 
Default server list (h=help): [192.168.0.0] 
Preferred server list (h=help): 
Choose desired search scope (one, sub, h=help):  [one] 
The following are the supported credential levels:
  1  anonymous
  2  proxy
  3  proxy anonymous
Choose Credential level [h=help]: [1] 2

The following are the supported Authentication Methods:
  1  none
  2  simple
  3  sasl/DIGEST-MD5
  4  tls:simple
  5  tls:sasl/DIGEST-MD5
Choose Authentication Method (h=help): [1] 2

Current authenticationMethod: simple

Do you want to add another Authentication Method? N

Do you want the clients to follow referrals (y/n/h)? [n] Y

Do you want to modify the server timelimit value (y/n/h)? [n] Y

Enter the time limit for iPlanet Directory Server (current=3600): [-1]

Do you want to modify the server sizelimit value (y/n/h)? [n] Y

Enter the size limit for iPlanet Directory Server (current=2000): [-1]

Do you want to store passwords in "crypt" format (y/n/h)? [n] Y

Do you want to setup a Service Authentication Methods (y/n/h)? [n]
Client search time limit in seconds (h=help): [30] 
Profile Time To Live in seconds (h=help): [43200] 

Bind time limit in seconds (h=help): [10] 2

Do you wish to setup Service Search Descriptors (y/n/h)? [n] 
 
              Summary of Configuration

  1  Domain to serve               : west.example.com
  2  Base DN to setup              : dc=west,dc=example,dc=com
  3  Profile name to create        : default
  4  Default Server List           : 192.168.0.0
  5  Preferred Server List         : 
  6  Default Search Scope          : one
  7  Credential Level              : proxy
  8  Authentication Method         : simple
  9  Enable Follow Referrals       : TRUE
 10  iPlanet Directory Server Time Limit                : -1
 11  iPlanet Directory Server Size Limit                : -1
 12  Enable crypt password storage : TRUE
 13  Service Auth Method pam_ldap  : 
 14  Service Auth Method keyserv   : 
 15  Service Auth Method passwd-cmd: 
 16  Search Time Limit             : 30
 17  Profile Time to Live          : 43200
 18  Bind Limit                    : 2
 19  Service Search Descriptors Menu

Enter config value to change: (1-19 0=commit changes) [0] 
Enter DN for proxy agent:[cn=proxyagent,ou=profile,dc=west,dc=example,dc=com]
Enter passwd for proxyagent: 
Re-enter passwd: 
 

WARNING: About to start committing changes. (y=continue, n=EXIT) Y

1. Changed timelimit to -1 in cn=config.
  2. Changed sizelimit to -1 in cn=config.
  3. Changed passwordstoragescheme to "crypt" in cn=config.
  4. Schema attributes have been updated.
  5. Schema objectclass definitions have been added.
  6. Created DN component dc=west.
  7. NisDomainObject added to dc=west,dc=example,dc=com.
  8. Top level "ou" containers complete.
  9. Nis maps: auto_home auto_direct auto_master auto_shared processed.
  10. ACI for dc=west,dc=example,dc=com modified to disable self modify.
  11. Add of VLV Access Control Information (ACI).
  12. Proxy Agent cn=proxyagent,ou=profile,dc=west,dc=example,dc=com added.
  13. Give cn=proxyagent,ou=profile,dc=west,dc=example,dc=com read permission for 
password.
  14. Generated client profile and loaded on server.
  15. Processing eq,pres indexes:
      ipHostNumber (eq,pres)   Finished indexing.                  
      uidNumber (eq,pres)   Finished indexing.                  
      ipNetworkNumber (eq,pres)   Finished indexing.                  
      gidnumber (eq,pres)   Finished indexing.                  
      oncrpcnumber (eq,pres)   Finished indexing.                  
  16. Processing eq,pres,sub indexes:
      membernisnetgroup (eq,pres,sub)   Finished indexing.                  
      nisnetgrouptriple (eq,pres,sub)   Finished indexing.                  
  17. Processing VLV indexes:
      getgrent vlv_index   Entry created
      gethostent vlv_index   Entry created
      getnetent vlv_index   Entry created
      getpwent vlv_index   Entry created
      getrpcent vlv_index   Entry created
      getspent vlv_index   Entry created

idsconfig.sh: Setup of iPlanet Directory Server server ipdserver is complete.


Note: idsconfig has created entries for VLV indexes.  Use the 
      directoryserver(1m) script on ipdserver to stop
      the server and then enter the following vlvindex
      sub-commands to create the actual VLV indexes:

  directoryserver -s ipdserver vlvindex -n userRoot -T getgrent
  directoryserver -s ipdserver vlvindex -n userRoot -T gethostent
  directoryserver -s ipdserver vlvindex -n userRoot -T getnetent
  directoryserver -s ipdserver vlvindex -n userRoot -T getpwent
  directoryserver -s ipdserver vlvindex -n userRoot -T getrpcent
  directoryserver -s ipdserver vlvindex -n userRoot -T getspent

After idsconfig has completed the setup of the directory, you need to run the specified commands on the server before the server setup is complete and the server is ready to serve clients.

Populating the Directory Server Using ldapaddent

Before populating the directory server with data, you must configure the server to store passwords in Unix Crypt format if you are using pam_unix. If you are using pam_ldap, you can store passwords in any format. For more information on setting the password in UNIX crypt format, see the iPlanet Directory Server documents.

ldapaddent(1M)can only run on a client which is already configured for the LDAP naming service.

ldapaddent reads from the standard input (that being an /etc/filename like passwd) and places this data to the container associated with the service. Client configuration determines how the data will be written by default.

The following is an example of populating the server with data using ldapaddent.

Example 15–2 How to populate the iPlanet Directory Server 5.1 with user password data using ldapaddent

1. Use the ldapaddent command to add /etc/passwd entires to the server.

   # ldapaddent -D "cn=directory manager" -f /etc/passwd passwd

See ldapaddent(1M). See Chapter 13, Basic Components and Concepts (Overview) for information regarding LDAP security and write-access to the Directory Server.

Managing Printer Entries

Adding Printers

To add printer entries into the LDAP directory use either the printmgr configuration tool or the lpset -n ldap command-line utility See lpset(1M). Note that the printer objects added to the directory only define the connection parameter, required by print system clients, of printers. Local print server configuration data is still held in files. A typical printer entry would look like the following.

printer-uri=myprinter,ou=printers,dc=mkg,dc=example,dc=com
objectclass=top
objectclass=printerService
objectclass=printerAbstract
objectclass=sunPrinter
printer-name=myprinter
sun-printer-bsdaddr=printsvr.example.com,myprinter,Solaris
sun-printer-kvp=description=HP LaserJet (PS)
printer-uri=myprinter

Using lpget

lpget(1M) can be used to list all printer entries known by the LDAP client's LDAP directory. If the LDAP client's LDAP server is a replica server, then printers listed may or may not be the same as that in the master LDAP server depending on the update replication agreement. See lpget(1M) for more information.

For example, to list all printers for a given base DN you would type the following.

# lpget -n ldap list

myprinter:
	dn=myprinter,ou=printers,dc=mkt,dc=example,dc=com
	bsdaddr=printsvr.example.com,myprinter,Solaris
	description=HP LaserJet (PS)

Populating the Server with Additional Profiles

Use ldapclient with the genprofile option to create an LDIF representation of a configuration profiles, based on the attributes specified. The profile you create can then be loaded into an LDAP server to be used as the client profile, which can be downloaded by the client using ldapclient init.

Refer to ldapclient(1M) for information on using ldapclient genprofile.

The following is an example of how to populate the server with additional profiles using ldapclient.

Example 15–3 How to populate the server with additional profiles

1. Become superuser,

2. Use ldapclient with the genprofile command.

   # ldapclient genprofile -a profileName=myprofile \

   -a defaultSearchBase=dc=west,dc=example,dc=com \

   -a "defaultServerList=192.168.0.0 192.168.0.1:386" \

   > myprofile.ldif

3. Upload the new profile to the server.

   # ldapadd –h 192.168.0.0 —D “cn=directory manager” —f myprofile.ldif

Chapter 16 Client Setup (Task)

This chapter describes how to set up a Solaris LDAP naming service client.

This chapter covers the following topics.

• Prerequisites

• Initializing a Client

• Using Profiles to Initialize a Client

• Using Proxy Credentials

• Initializing a Client Manually

• Modifying a Manual Client Configuration

• Un-initializing a Client

• TLS Security Setup

Prerequisites

In order for a Solaris client to use LDAP as a naming service the following needs to be in place.

• The client's domain name must be served by the LDAP server

• The nsswitch.conf file needs to point to LDAP for the required services. For information about the nsswitch.conf file, see Chapter 2, The Name Service Switch (Overview)

• The client needs to be configured with all the given parameters that define its behavior

• ldap_cachemgr needs to be running on the client

• At least one server for which a client is configured must be up and running

The ldapclient utility is the key to setting up an LDAP client, as it performs all of the above steps, except for starting the server. The rest of this chapter will show examples of how to use the ldapclient utility to setup a LDAP client and use the various other LDAP utilities to get information about, and check the status of an LDAP client.

Initializing a Client

ldapclient(1M) is an utility used to setup LDAP clients in a Solaris operating environment. ldapclient assumes the server has already been configured with the appropriate client profiles. You must install and configure the server with the appropriate profiles before you can set up any clients.

There are two ways to set up a client using ldapclient.

• Profile

  At a minimum, you need to specify the server address containing the profile and domain you wish to use. If no profile is specified, then the “default” profile is assumed. The server will provide the rest of the required information, except for proxy and certificate database information. If a client's credential level is proxy or proxy anonymous, you must supply the proxy bind DN and password. See Assigning Client Credential Levels for more information.

• Manual

  You configure the profile on the client itself, which means defining all parameters form the command line. Thus, the profile information is stored in cache files and is never refreshed by the server.

Though you can manually configure clients, it is not recommended. Using the configuration profiles decreases the complexity and cost of managing clients.

Using Profiles to Initialize a Client

How to Initialize a Client Using Profiles

1. Become superuser.

2. Run ldapclient with init.

   # ldapclient init -a profileName=new -a \

   domainName=west.example.com 192.168.0.0

   System successfully configured

Using Proxy Credentials

How to Initialize a Client using Proxy Credentials

1. Become superuser.

2. Run ldapclient (defining proxy values).

   # ldapclient init -a proxyDn=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com -a domainname=west.example.com -a profilename=pit1 -a proxypassword=test1234 192.168.0.0

   System successfully configured

The -a proxyDn and -a proxypassword are required if the profile to be used is setup for proxy. As the credentials are not stored in the profile saved on the server, you need to supply the information when you initialize the client. This method is more secure than the older method of storing the proxy credentials on the server.

The proxy info will be used to create the /var/ldap/ldap_client_cred and the rest of the information will be put in /var/ldap/ldap_client_file.

DO NOT edit either the client configuration files directly. Use ldapclient to create or modify the content of these files.

Initializing a Client Manually

Superusers can perform manual client configurations. However, many of the checks are bypassed during the process, so it is relatively easy to mis-configure your system. In addition, you must change settings on every machine, instead of in one central place, as is done when using profiles.

How to initialize a client manually.

1. Become superuser.

2. Use ldapclient manual.

   # ldapclient manual —a domainName=dc=west.example.com \

   —a credentialLevel=proxy —a defaultSearchBase=dc=west, dc=example, dc=com \

   —a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \

   —a proxyPassword=testtest 192.168.0.0

3. Use ldapclient list to verify.

   NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.0 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_CREDENTIAL_LEVEL= proxy

Modifying a Manual Client Configuration

How to modify a manual configuration

1. Become superuser

2. Use the ldapclient mod to change the authentication method to simple.

   # ldapclient mod -a authenticationMethod=simple

3. Use ldapclient list to verify the change was made.

   # ldapclient list

   NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f NS_LDAP_SERVERS= 192.168.0.0 NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com NS_LDAP_AUTH= simple NS_LDAP_CREDENTIAL_LEVEL= proxy

Un-initializing a Client

How to un-initialize a client

1. Become superuser.

2. Use ldapclient uninit.

   # ldapclient uninit

   System successfully recovered

ldapclient uninit restores the client name service to what it was prior to the most recent init, modify, or manual operation. In other words, it performs an “undo” on the last step taken. For example, if the client was configured to use profile1 and was then changed to use profile2, using ldapclient uninit would revert the client back to using profile1.

TLS Security Setup

The cert7.db and key3.db files must be readable by everyone. Be sure not to include any private keys in the key3.db file.

If using TLS, the necessary security databases must be installed. In particular, the files cert7.db and key3.db are needed. The cert7.db file contains the database of trusted certificates. The key3.db file contains the client's keys. Although the LDAP naming service client does not use client keys, this file must be present.

Before running ldapclient, you should set up and install the needed security database files described in this section.

See the section 'Configuring LDAP Clients to Use SSL' in the Managing SSL chapter of the iPlanet Directory Server 5.1 Administrator's Guide for information on how to create and manage these files. Once configured, these files must be stored in the location expected by the LDAP naming service client. The attribute certificatePath is used to determine this location. This is by default /var/ldap.

For example, after setting up the necessary cert7.db and key3.db files using Netscape Communicator, copy them to the default location.

# cp $HOME/.netscape/cert7.db /var/ldap

# cp $HOME/.netscape/key3.db /var/ldap

Next, give everyone read access.

# chmod 444 /var/ldap/cert7.db

# chmod 444 /var/ldap/key3.db

Netscape will manage the cert7.db and key3.db in the $HOME/.netscape directory. Copies of these security databases must be stored on a local file system if you are using them for the LDAP naming service client.

Configuring PAM

If you are using pam_ldap, follow the sample pam.conf file included in An example pam.conf file for pam_ldap and add the lines containing pam_ldap.so.1 to the client's /etc/pam.conf file. Not every line containing pam_ldap.so.1 is needed. Only the section for the command, login and password, for example, which requires pam_ldap, needs to be modified. For details, see pam.conf(4).

Retrieving Naming Service Information

Using ldaplist

ldaplist is an LDAP utility to list the naming information from the LDAP servers in LDIF format. It can be useful for troubleshooting. See ldaplist(1) for further information.

Listing All LDAP Containers

ldaplist displays its output with a blank line separating records, which is helpful for big multiline records.

The output of ldaplist depends upon the client configuration. For example, if the value of ns_ldap_search is sub rather than one, ldaplist lists all the entries under the current search baseDN.

The following is and example of ldaplist output.

# ldaplist

dn: ou=people,dc=west,dc=example,dc=com

dn: ou=group,dc=west,dc=example,dc=com

dn: ou=rpc,dc=west,dc=example,dc=com

dn: ou=protocols,dc=west,dc=example,dc=com

dn: ou=networks,dc=west,dc=example,dc=com

dn: ou=netgroup,dc=west,dc=example,dc=com

dn: ou=aliases,dc=west,dc=example,dc=com

dn: ou=hosts,dc=west,dc=example,dc=com

dn: ou=services,dc=west,dc=example,dc=com

dn: ou=ethers,dc=west,dc=example,dc=com

dn: ou=profile,dc=west,dc=example,dc=com

dn: automountmap=auto_home,dc=west,dc=example,dc=com

dn: automountmap=auto_direct,dc=west,dc=example,dc=com

dn: automountmap=auto_master,dc=west,dc=example,dc=com

dn: automountmap=auto_shared,dc=west,dc=example,dc=com

Listing All User Entry Attributes

To list specific information such as a user's passwd entry, use getent as follows.

# getent passwd user1

user1::30641:10:Joe Q. User:/home/user1:/bin/csh

If you want to list all attributes, use ldaplist with the -l option.

# ldaplist -l passwd user1

dn: uid=user1,ou=People,dc=west,dc=example,dc=com
        uid: user1
        cn: user1
        uidNumber: 30641
        gidNumber: 10
        gecos: Joe Q. User
        homeDirectory: /home/user1
        loginShell: /bin/csh
        objectClass: top
        objectClass: shadowAccount
        objectClass: account
        objectClass: posixAccount
        shadowLastChange: 6445
        userPassword: {crypt}J6vlYXRU.sW8c

Customizing the Client Environment

There are a couple of things you can tune in your client environment to make things work the way you want.

Modifying the nsswitch.conf File

You can modify your /etc/nsswitch.conf file to customize where each service gets its information. The default settings are stored in /etc/nsswitch.ldap and ldapclient uses this file to create your /etc/nsswitch.conf file when the client is initialized.

If you want to enable DNS by setting up a /etc/resolv.conf file, you will want to add DNS to your hosts lines as shown below.

hosts:      ldap dns [NOTFOUND=return] files

You can change any of the services, but be careful, because if the data is not populated on the server for the service specified things will stop working. In some cases files may not be setup by default as well.

Chapter 17 Troubleshooting

This chapter describes configuration problems and suggested solutions.

Monitoring Client Status

This section shows various commands that can be used to help determine the state of the LDAP client environment. For more information see the section on troubleshooting which will give more information on common problems and how to solve them. Also see the man pages for additional information on the options that can be used.

Verifying ldap_cachemgr is running

The ldap_cachemgr daemon must be running and functioning correctly at all times. Otherwise, nothing works. There are two ways to check if ldap_cachemgr is running.

• Use ps -ef.

  # ps -ef | grep ldap_cachemgr

• Pass the -g option to ldap_cachemgr.

  This causes it to dump the following status information, which is useful when you must diagnose a problem.

  # /usr/lib/ldap/ldap_cachemgr -g

  cachemgr configuration: server debug level 0 server log file "/var/ldap/cachemgr.log" number of calls to ldapcachemgr 19 cachemgr cache data statistics: Configuration refresh information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:43:28 Server information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:36:08 server: 192.168.0.0, status: UP server: 192.168.0.1, status: ERROR error message: Can't connect to the LDAP server Cache data information: Maximum cache entries: 256 Number of cache entries: 2

Checking the Current Profile Information

Become superuser and run ldapclient with the list option.

# ldapclient list

NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com
NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f
NS_LDAP_SERVERS= 192.168.0.0, 192.168.0.1
NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_SERVER_PREF= 192.168.0.0
NS_LDAP_PROFILE= pit1
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,dc=west,dc=example,dc=com?one
NS_LDAP_BIND_TIME= 5

Currently the /var/ldap files are in ASCII format, but that could change to binary at some time and cating the files would cause problems. ldapclient list is the supported method for accessing this information.

Verifying Basic Client/Server Communication

The best way to show that your client is talking to the LDAP server is with the ldaplist command. The simplest form, ldaplist with no arguments will dump all the containers on the server. This works as long as the containers exist, and do not have to be populated. If the first step works, you can try ldaplist passwd username or ldaplist hosts hostname but if they contain lots of data you might want to pick a less populated service, or pipe them to head or more.

Checking Server Data From a Non-client Machine

Most of the commands above assume you are already an LDAP client. If you have not created a client and want to check the data on the server, use the ldapsearch command. The following example lists all of the containers.

# ldapsearch -h server1 -b "dc=west,dc=example,dc=com" -s one "objectclass=*"

Configuration Problems and Solutions

The following discussion briefly describes LDAP configuration problems and suggested solutions to the problems.

Unresolved Hostname

The Solaris operating environment LDAP client backend returns fully qualified hostnames for host lookups, such as hostnames returned by gethostbyname(3N) and getipnodebyname(3N). If the name stored is qualified that is contains at least one dot, the client returns the name as is. For example, if the name stored is hostB.eng, the returned name is hostB.eng.

If the name stored in the LDAP directory is not qualified (it does not contain any dot), the client backend appends the domain part to the name. For example, if the name stored is hostA, the returned name is hostA.domainname.

Unable to Reach Systems in the LDAP Domain Remotely

If the DNS domain name is different from the LDAP domain name, then the LDAP naming service cannot be used to serve host names unless the host names are stored fully qualified.

Login Does Not Work

LDAP clients use the pam(3) modules for user authentication during the logins. When using the standard UNIX^TM PAM module, the password is read from the server and checked on the client side. This can fail due to one of the following reasons.

1. ldap not used by the passwd service in the /etc/nsswitch.conf file

2. The user's userPassword attribute on the server list is not readable by the proxy agent. You need to allow at least the proxy agent to read the password because the proxy agent returns it to the client for comparison. pam_ldap does not require read access to the password

3. Proxy agent might not have correct password

4. The entry does not have the shadowAccount objectclass

5. There is no password defined for the user

   When you use ldapaddent, you must use the -p option to ensure that the password is added to the user entry. If you used ldapaddent without using the -p option, the, users's password will not be stored in the directory unless you also add the /etc/shadow file using ldapaddent.

6. None of the LDAP servers are reachable.

   Check the status of the servers.

   # /usr/lib/ldap/ldap_cachemgr —g

7. pam_conf is configured incorrectly.

8. The user is not defined in the LDAP namespace.

9. NS_LDAP_CREDENTIAL_LEVEL is set to anonymous for pam_unix and userPassword attribute is not available to anonymous users.

10. Password is not stored in crypt format.

Lookup Too Slow

The LDAP database relies on indexes to improve the performance. A major performance degradation occurs when indexes are not configured properly. As part of the documentation, we have provided a common set of attributes that should be indexed. You can also add your own indexes to improve performance at your site.

ldapclient Cannot Bind to Server

ldapclient failed to initialize the client when using the init profile option. There are several possible reasons for this failure.

1. The incorrect domain name was specified on the command line.

2. nisDomain attribute is not set in the DIT to represent the entry point for the specified client domain.

3. Access control information is not set up properly on the server, thus disallowing anonymous search in the LDAP database.

4. Incorrect server address passed to the ldapclient command. Use ldapsearch(1) to verify the server address

5. Incorrect profile name passed to the ldapclient command. Use ldapsearch(1) to verify the profile name in the DIT.

6. Use snoop(1M) on the client's network interface to see what sort of traffic is going out, and determine to which server it is talking.

Using ldap_cachemgr for Debugging

Usingldap_cachemgr with the —g option can be a useful way to debug, as you can view the current client configuration and statistics. For example,

#ldap_cachemgr —g

would print current configuration and statistics to standard output, including the status of all LDAP servers, as mentioned previously. Note that you do not need to become superuser to execute this command.

ldapclient Hangs During Setup

If the ldapclient command hangs, hitting Ctrl-C will exit after restoring the previous environment. If this happens, check with the server administrator to make sure the server is running.

Also check the server list attributes on either the profile or the command line and make sure the server information is correct.

Frequently Asked Questions

Can I use LDAP naming services with Older Solaris Releases?

Currently, LDAP is only supported in Solaris 8 and Solaris 9. For differences between the two see New LDAP Naming Service Features for Solaris 9.

What are the DIT Default Locations in Solaris LDAP Naming Services?

See Default Directory Information Tree (DIT).

Chapter 18 General Reference

1. Blank Checklists

2. Upgrade Information

3. LDAP Commands

4. An example pam.conf file for pam_ldap

5. IETF Schemas

6. Directory User Agent Profile (DUAProfile) Schema

7. Solaris Schemas

8. Internet Print Protocol Information

9. Generic Directory Server Requirements

10. Default Filters Used By Naming Services

Blank Checklists

Upgrade Information

Solaris 9 clients are fully compatible with directory servers setup to serve Solaris 8 clients. ldapclient(1M) can simply download such a profile and configure the client using version 1 profiles. However to take advantage of new features built into Solaris 9 and to use the new security model, version 2 profiles must be used.

Servers can serve a mix of both old and new clients so that both clients see the same results from the server as long as schema mapping is not enabled and version 2 profiles are not configured to use special filters in serviceSearchDescriptors. Obviously if the server is not using the default schema older clients can not use that server as Solaris 8 clients can not arbitrarily map their schema.

One additional change that also should be considered is that in Solaris 8 clients running ldap_cachemgr() was recommended, but optional. In Solaris 9, ldap_cachemgr() must be running at all times. This daemon is required for the client to function properly.

New Automount Schema

By default, Solaris 9 uses a new schema for automount entries instead of using generic NIS map schema which Solaris 8 clients used. This means that if you setup a server with Solaris 9 tools, Solaris 8 clients can not see the automount entries. For sites where the server being setup is to serve both Solaris 9 and Solaris 8 clients, a profile can be created to map the schema to the old one before adding automounter entries. This would ensure that ldapaddent(1M) adds the entries using the old schema. However, note that this would also mean that all Solaris 9 clients must use a profile where the schema for automount is mapped.

You need to add the following mapping attributes to your profile for this mapping to take effect.

attributeMap: 		automount:automountMapName=nisMapName
attributeMap: 		automount:automountKey=cn
attributeMap: 		automount:automountInformation=nisMapEntry
objectclassMap: 	automount:automountMap=nisMap
objectclassMap: 	automount:automount=nisObject

LDAP Commands

There are two sets of LDAP related commands in Solaris. One set is the general LDAP tools which do not require the client to be configured with the LDAP naming service. The second set use the common LDAP configuration on the client and therefore can only be used if the client is configured to use LDAP as its naming service.

General LDAP Tools

LDAP command line tools support a common set of options, including authentication and bind parameters.

These commands can be used to manipulate directory entries directly. The ldapsearch, ldapadd, and ldapmodify tools support a common text-based format for representing directory information called the LDAP Data Interchange Format (LDIF).

LDAP Tools Requiring LDAP Naming Services

An example pam.conf file for pam_ldap

#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login   auth required           pam_authtok_get.so.1
login   auth required           pam_dhkeys.so.1
login   auth required           pam_dial_auth.so.1
login   auth sufficient         pam_unix_auth.so.1
login   auth required           pam_ldap.so.1 try_first_pass
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin  auth sufficient         pam_rhosts_auth.so.1
rlogin  auth required           pam_authtok_get.so.1
rlogin  auth required           pam_dhkeys.so.1
rlogin  auth sufficient         pam_unix_auth.so.1
rlogin  auth required           pam_ldap.so.1 try_first_pass
#
# rsh service (explicit because of pam_rhost_auth)
#
rsh     auth sufficient         pam_rhosts_auth.so.1
rsh     auth required           pam_authtok_get.so.1
rsh     auth required           pam_dhkeys.so.1
rsh     auth sufficient         pam_unix_auth.so.1
rsh     auth required           pam_ldap.so.1 try_first_pass
#
# PPP service (explicit because of pam_dial_auth)
#
ppp     auth required           pam_authtok_get.so.1
ppp     auth required           pam_dhkeys.so.1
ppp     auth required           pam_dial_auth.so.1
ppp     auth sufficient         pam_unix_auth.so.1
ppp     auth required           pam_ldap.so.1 try_first_pass
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authenctication

#
other   auth required           pam_authtok_get.so.1
other   auth required           pam_dhkeys.so.1
other   auth sufficient         pam_unix_auth.so.1
other   auth required           pam_ldap.so.1 try_first_pass
#
# passwd command (explicit because of a different authentication module)

#
passwd  auth sufficient         pam_passwd_auth.so.1
passwd  auth required           pam_ldap.so.1  try_first_pass
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron    account required        pam_projects.so.1
cron    account required        pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account
management
#
other   account requisite       pam_roles.so.1
other   account required        pam_projects.so.1
other   account required        pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session
management
#
other   session required        pam_unix_session.so.1
#
# Default definition for  Password management
# Used when service name is not explicitly mentioned for password
management
#
other   password required       pam_dhkeys.so.1
other   password required       pam_authtok_get.so.1
other   password required       pam_authtok_check.so.1
other   password sufficient     pam_authtok_store.so.1
other   password required       pam_ldap.so.1
#
# Support for Kerberos V5 authentication (uncomment to use Kerberos)
#
#rlogin         auth optional           pam_krb5.so.1 try_first_pass
#login          auth optional           pam_krb5.so.1 try_first_pass
#other          auth optional           pam_krb5.so.1 try_first_pass
#cron           account optional        pam_krb5.so.1
#other          account optional        pam_krb5.so.1
#other          session optional        pam_krb5.so.1
#other          password optional       pam_krb5.so.1 try_first_pass

IETF Schemas

Schemas are definitions describing what types of information can be stored as entries in a server's directory.

In order for a directory server to support Solaris 9 LDAP naming clients, schemas defined in this chapter must be configured in the server unless schema is mapped using the schema mapping feature of the clients.

There are four required LDAP schemas defined by IETF: the RFC 2307 Network Information Service schema, the LDAP mailgroups Internet draft and the LDAP Internet Print Protocol (IPP) draft schema. To support Naming Information Service, the definition of these schemas must be added to the directory server. The various RFCs can also be accessed on the IETF website http://www.ietf.org.

Internet-Drafts are draft documents valid for a maximum of six months and might be updated, or rendered obsolete by other documents at any time

RFC 2307 Network Information Service Schema

The LDAP servers must be configured to support the revised RFC 2307.

The nisSchema OID is 1.3.6.1.1. The RFC 2307 Attributes are the following.

( nisSchema.1.0 NAME 'uidNumber'
DESC 'An integer uniquely identifying a user in an
		administrative domain'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.1 NAME 'gidNumber'
DESC 'An integer uniquely identifying a group in an
		administrative domain'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.2 NAME 'gecos'
DESC 'The GECOS field; the common name'
EQUALITY caseIgnoreIA5Match
SUBSTRINGS caseIgnoreIA5SubstringsMatch
SYNTAX 'IA5String' SINGLE-VALUE )
 
( nisSchema.1.3 NAME 'homeDirectory'
DESC 'The absolute path to the home directory'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' SINGLE-VALUE )
 
( nisSchema.1.4 NAME 'loginShell'
DESC 'The path to the login shell'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' SINGLE-VALUE )
 
( nisSchema.1.5 NAME 'shadowLastChange'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.6 NAME 'shadowMin'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.7 NAME 'shadowMax'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.8 NAME 'shadowWarning'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.9 NAME 'shadowInactive'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.10 NAME 'shadowExpire'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.11 NAME 'shadowFlag'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.12 NAME 'memberUid'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
 
( nisSchema.1.13 NAME 'memberNisNetgroup'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
 
( nisSchema.1.14 NAME 'nisNetgroupTriple'
DESC 'Netgroup triple'
SYNTAX 'nisNetgroupTripleSyntax' )
 
( nisSchema.1.15 NAME 'ipServicePort'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.16 NAME 'ipServiceProtocol'
SUP name )
 
( nisSchema.1.17 NAME 'ipProtocolNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
 
( nisSchema.1.18 NAME 'oncRpcNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )

( nisSchema.1.19 NAME 'ipHostNumber'
DESC 'IP address as a dotted decimal, eg. 192.168.1.1
	     omitting leading zeros'
SUP name )
 
( nisSchema.1.20 NAME 'ipNetworkNumber'
DESC 'IP network as a dotted decimal, eg. 192.168,
     	omitting leading zeros'
SUP name SINGLE-VALUE )
 
( nisSchema.1.21 NAME 'ipNetmaskNumber'
DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
	      omitting leading zeros'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )
 
( nisSchema.1.22 NAME 'macAddress'
DESC 'MAC address in maximal, colon separated hex
      notation, eg. 00:00:92:90:ee:e2'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' )
 
( nisSchema.1.23 NAME 'bootParameter'
DESC 'rpc.bootparamd parameter'
SYNTAX 'bootParameterSyntax' )
 
( nisSchema.1.24 NAME 'bootFile'
DESC 'Boot image name'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' )
 
( nisSchema.1.26 NAME 'nisMapName'
SUP name )
 
( nisSchema.1.27 NAME 'nisMapEntry'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String{1024}' SINGLE-VALUE )
 
( nisSchema.1.28 NAME 'nisPublicKey'
DESC 'NIS public key'
SYNTAX 'nisPublicKeySyntax' )
 
( nisSchema.1.29 NAME 'nisSecretKey'
DESC 'NIS secret key'
SYNTAX 'nisSecretKeySyntax' )
 
( nisSchema.1.30 NAME 'nisDomain'
DESC 'NIS domain'
SYNTAX 'IA5String' )

( nisSchema.1.31 NAME 'automountMapName'
DESC 'automount Map Name'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

( nisSchema.1.32 NAME 'automountKey'
DESC 'Automount Key value'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

( nisSchema.1.33 NAME 'automountInformation'
DESC 'Automount information'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

The nisSchema OID is 1.3.6.1.1. The RFC 2307 objectClasses are the following.

( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY
  DESC 'Abstraction of an account with POSIX attributes'
  MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
  MAY ( userPassword $ loginShell $ gecos $ description ) )
 
( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY
  DESC 'Additional attributes for shadow passwords'
  MUST uid
  MAY ( userPassword $ shadowLastChange $ shadowMin
        shadowMax $ shadowWarning $ shadowInactive $
        shadowExpire $ shadowFlag $ description ) )
 
( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
  DESC 'Abstraction of a group of accounts'
  MUST ( cn $ gidNumber )
  MAY ( userPassword $ memberUid $ description ) )
 
( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL
  DESC 'Abstraction an Internet Protocol service.
        Maps an IP port and protocol (such as tcp or udp)
        to one or more names; the distinguished value of
        the cn attribute denotes the service's canonical
        name'
  MUST ( cn $ ipServicePort $ ipServiceProtocol )
  MAY ( description ) )
 
( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
  DESC 'Abstraction of an IP protocol. Maps a protocol number
        to one or more names. The distinguished value of the cn
        attribute denotes the protocol's canonical name'
  MUST ( cn $ ipProtocolNumber )
  MAY  description )
 
( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL
  DESC 'Abstraction of an Open Network Computing (ONC)
        [RFC1057] Remote Procedure Call (RPC) binding.
        This class maps an ONC RPC number to a name.
        The distinguished value of the cn attribute denotes
        the RPC service's canonical name'
  MUST ( cn $ oncRpcNumber $ description )
  MAY  description )
 
( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY
  DESC 'Abstraction of a host, an IP device. The distinguished
        value of the cn attribute denotes the host's canonical
        name. Device SHOULD be used as a structural class'
  MUST ( cn $ ipHostNumber )
  MAY ( l $ description $ manager $ userPassword ) )
 
( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
  DESC 'Abstraction of a network. The distinguished value of
        the cn attribute denotes the network's canonical name'
  MUST ipNetworkNumber
  MAY ( cn $ ipNetmaskNumber $ l $ description $ manager ) )
 
( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
  DESC 'Abstraction of a netgroup. May refer to other netgroups'
  MUST cn
  MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )

( nisSchema.2.9 NAME 'nisMap' SUP top STRUCTURAL
  DESC 'A generic abstraction of a NIS map'
  MUST nisMapName
  MAY description )
 
( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL
  DESC 'An entry in a NIS map'
  MUST ( cn $ nisMapEntry $ nisMapName )
  MAY description )

( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY
  DESC 'A device with a MAC address; device SHOULD be
        used as a structural class'
  MAY macAddress )
 
( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY
  DESC 'A device with boot parameters; device SHOULD be
  used as a structural class'
  MAY ( bootFile $ bootParameter ) )
 
( nisSchema.2.14 NAME 'nisKeyObject' SUP top AUXILIARY
  DESC 'An object with a public and secret key'
  MUST ( cn $ nisPublicKey $ nisSecretKey )
  MAY ( uidNumber $ description ) )
 
( nisSchema.2.15 NAME 'nisDomainObject' SUP top AUXILIARY
  DESC 'Associates a NIS domain with a naming context'
  MUST nisDomain )

( nisSchema.2.16 NAME 'automountMap' SUP top STRUCTURAL
  MUST ( automountMapName )
  MAY description )

( nisSchema.2.17 NAME 'automount' SUP top STRUCTURAL
  DESC 'Automount information'
  MUST ( automountKey $ automountInformation )
  MAY description )

Mail Alias Schema

Mail alias information uses the schema defined by the LDAP Mailgroups Internet draft, formerly known as the draft-steinback-ldap-mailgroups draft. Until a new schema becomes available, Solaris LDAP clients will continue to use this schema for mail alias information.

The original LDAP Mailgroups schema contains a large number of attributes and object classes. Only two attributes and a single object class are used by Solaris clients. These are listed below.

The mail alias Attributes are the following.

( 0.9.2342.19200300.100.1.3
  NAME 'mail'
  DESC 'RFC822 email address for this person'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String(256)'
  SINGLE-VALUE )
 
( 2.16.840.1.113730.3.1.30
  NAME 'mgrpRFC822MailMember'
  DESC 'RFC822 mail address of email only member of group'
  EQUALITY CaseIgnoreIA5Match
  SYNTAX 'IA5String(256)' )

The mail alias objectClass is the following.

( 2.16.840.1.113730.3.2.4
  NAME 'mailGroup'
  SUP top
  STRUCTURAL
  MUST mail
  MAY ( cn $ mailAlternateAddress $ mailHost $ mailRequireAuth $
   mgrpAddHeader $ mgrpAllowedBroadcaster $ mgrpAllowedDomain $
   mgrpApprovePassword $ mgrpBroadcasterModeration $ mgrpDeliverTo $
   mgrpErrorsTo $ mgrpModerator $ mgrpMsgMaxSize $
   mgrpMsgRejectAction $ mgrpMsgRejectText $ mgrpNoMatchAddrs $
   mgrpRemoveHeader $ mgrpRFC822MailMember ))

Directory User Agent Profile (DUAProfile) Schema

The DUAConfSchemaOID is 1.3.6.1.4.1.11.1.3.1.

DESC 'Default LDAP server host address used by a DUA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.1 NAME 'defaultSearchBase'
            DESC 'Default LDAP base DN used by a DUA'
            EQUALITY distinguishedNameMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.2 NAME 'preferredServerList'
            DESC 'Preferred LDAP server host addresses to be used by a
            DUA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.3 NAME 'searchTimeLimit'
            DESC 'Maximum time in seconds a DUA should allow for a
            search to complete'
            EQUALITY integerMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.4 NAME 'bindTimeLimit'
            DESC 'Maximum time in seconds a DUA should allow for the
            bind operation to complete'
            EQUALITY integerMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.5 NAME 'followReferrals'
            DESC 'Tells DUA if it should follow referrals
            returned by a DSA search result'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.6 NAME 'authenticationMethod'
            DESC 'A keystring which identifies the type of
            authentication method used to contact the DSA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.7 NAME 'profileTTL'
            DESC 'Time to live, in seconds, before a client DUA
            should re-read this configuration profile' 
				'serviceSearchDescriptor'
            DESC 'LDAP search descriptor list used by a DUA'
            EQUALITY caseExactMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

          ( DUAConfSchemaOID.1.9 NAME 'attributeMap'
            DESC 'Attribute mappings used by a DUA'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

          ( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
            DESC 'Identifies type of credentials a DUA should
            use when binding to the LDAP server'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
            SINGLE-VALUE )

          ( DUAConfSchemaOID.1.11 NAME 'objectclassMap'
            DESC 'Objectclass mappings used by a DUA'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

          ( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope' SINGLE-VALUE )

          ( DUAConfSchemaOID.1.13 NAME 'serviceCredentialLevel'
            DESC 'Identifies type of credentials a DUA
            should use when binding to the LDAP server for a
            specific service'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

          ( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod'
            DESC 'Authentication Method used by a service of the DUA'
            EQUALITY caseIgnoreMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

			  ( DUAConfSchemaOID.2.4 NAME 'DUAConfigProfile'
			  	 SUP top STRUCTURAL
				 DESC 'Abstraction of a base configuration for a DUA'
				 MUST ( cn )
				 MAY ( defaultServerList $ preferredServerList $
                defaultSearchBase $ defaultSearchScope $
                searchTimeLimit $ bindTimeLimit $
                credentialLevel $ authenticationMethod $
                followReferrals $ serviceSearchDescriptor $
                serviceCredentialLevel $ serviceAuthenticationMethod $
                objectclassMap $ attributeMap $
                profileTTL ) )  	

Solaris Schemas

The schemas required for the Solaris operating environment are the following.

• Solaris Projects schema

• Role based access control and execution profile schemas

• Printer schemas

Solaris Projects Schema

/etc/project is a local source of attributes associated with projects. For more information see project(4).

The Project Attributes are the following.

( 1.3.6.1.4.1.42.2.27.5.1.1 NAME 'SolarisProjectID'
  DESC 'Unique ID for a Solaris Project entry'
  EQUALITY integerMatch
  SYNTAX INTEGER SINGLE )

( 1.3.6.1.4.1.42.2.27.5.1.2 NAME 'SolarisProjectName'
  DESC 'Name of a Solaris Project entry'
  EQUALITY caseExactIA5Match
  SYNTAX IA5String SINGLE )

( 1.3.6.1.4.1.42.2.27.5.1.3 NAME 'SolarisProjectAttr'
  DESC 'Attributes of a Solaris Project entry'
  EQUALITY caseExactIA5Match
  SYNTAX IA5String )

( 1.3.6.1.4.1.42.2.27.5.1.30 NAME 'memberGid'
  DESC 'Posix Group Name'
  EQUALITY caseExactIA5Match
  SYNTAX 'IA5String' )

The Project objectClass is:

( 1.3.6.1.4.1.42.2.27.5.2.1 NAME 'SolarisProject'
  SUP top STRUCTURAL
  MUST ( SolarisProjectID $ SolarisProjectName )
  MAY ( memberUid $ memberGid $ description $ SolarisProjectAttr ) )

Role Based Access Control and Execution Profile Schema

/etc/user_attr is a local source of extended attributes associated with users and roles. For more information see user_attr(4).

The role based access control Attributes are the following.

( 1.3.6.1.4.1.42.2.27.5.1.4 NAME 'SolarisAttrKeyValue'
  DESC 'Semi-colon separated key=value pairs of attributes'
  EQUALITY caseIgnoreIA5Match
  SUBSTRINGS caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.7 NAME 'SolarisAttrShortDesc'
  DESC 'Short description about an entry, used by GUIs'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.8 NAME 'SolarisAttrLongDesc'
  DESC 'Detail description about an entry'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.9 NAME 'SolarisKernelSecurityPolicy'
  DESC 'Solaris  kernel security policy'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.10 NAME 'SolarisProfileType'
  DESC 'Type of object defined in profile'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.11 NAME 'SolarisProfileId'
  DESC 'Identifier of object defined in profile'
  EQUALITY caseExactIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.12 NAME 'SolarisUserQualifier'
  DESC 'Per-user login attributes'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.13 NAME 'SolarisReserved1'
  DESC 'Reserved for future use'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )
 
( 1.3.6.1.4.1.42.2.27.5.1.14 NAME 'SolarisReserved2'
  DESC 'Reserved for future use'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 'IA5String' SINGLE-VALUE )

The role based access control objectClassses are the following.

( 1.3.6.1.4.1.42.2.27.5.2.3 NAME 'SolarisUserAttr' SUP top AUXILIARY
  DESC 'User attributes'
  MAY ( SolarisUserQualifier $ SolarisAttrReserved1 $ \
        SolarisAttrReserved2 $ SolarisAttrKeyValue ) )
 
( 1.3.6.1.4.1.42.2.27.5.2.4 NAME 'SolarisAuthAttr' SUP top STRUCTURAL
  DESC 'Authorizations data'
  MUST cn
  MAY ( SolarisAttrReserved1 $ SolarisAttrReserved2 $ \
        SolarisAttrShortDesc $ SolarisAttrLongDesc $ \
        SolarisAttrKeyValue ) )
 
( 1.3.6.1.4.1.42.2.27.5.2.5 NAME 'SolarisProfAttr' SUP top STRUCTURAL
  DESC 'Profiles data'
  MUST cn
  MAY ( SolarisAttrReserved1 $ SolarisAttrReserved2 $ \
        SolarisAttrLongDesc $ SolarisAttrKeyValue ) )
 
( 1.3.6.1.4.1.42.2.27.5.2.6 NAME 'SolarisExecAttr' SUP top AUXILIARY
  DESC 'Profiles execution attributes'
  MAY ( SolarisKernelSecurityPolicy $ SolarisProfileType $ \
        SolarisAttrReserved1 $ SolarisAttrReserved2 $ \
        SolarisProfileId $ SolarisAttrKeyValue ) )

Internet Print Protocol Information

Internet Print Protocol (IPP) Attributes

( 1.3.18.0.2.4.1140 
NAME 'printer-uri' 
DESC 'A URI supported by this printer.  
This URI SHOULD be used as a relative distinguished name (RDN).  
If printer-xri-supported is implemented, then this URI value 
MUST be listed in a member value of printer-xri-supported.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

( 1.3.18.0.2.4.1107 
NAME 'printer-xri-supported' 
DESC 'The unordered list of XRI (extended resource identifiers) supported 
by this printer.  
Each member of the list consists of a URI (uniform resource identifier) 
followed by optional authentication and security metaparameters.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

( 1.3.18.0.2.4.1135 
NAME 'printer-name' 
DESC 'The site-specific administrative name of this printer, more end-user 
friendly than a URI.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}  SINGLE-VALUE )

( 1.3.18.0.2.4.1119 
NAME 'printer-natural-language-configured' 
DESC 'The configured language in which error and status messages will be 
generated (by default) by this printer.  
Also, a possible language for printer string attributes set by operator, 
system administrator, or manufacturer.  
Also, the (declared) language of the "printer-name", "printer-location", 
"printer-info", and "printer-make-and-model" attributes of this printer. 
For example: "en-us" (US English) or "fr-fr" (French in France) Legal values of 
language tags conform to [RFC3066] "Tags for the Identification of Languages".' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}  SINGLE-VALUE )

( 1.3.18.0.2.4.1136 
NAME 'printer-location' 
DESC 'Identifies the location of the printer. This could include
things like: "in Room 123A", "second floor of building XYZ".' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} SINGLE-VALUE )

( 1.3.18.0.2.4.1139 
NAME 'printer-info' 
DESC 'Identifies the descriptive information about this printer.  
This could include things like: "This printer can be used for 
printing color transparencies for HR presentations", or 
"Out of courtesy for others, please print only small (1-5 page) 
jobs at this printer", or even "This printer is going away on July 1, 1997, 
please find a new printer".' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} 
SINGLE-VALUE )

( 1.3.18.0.2.4.1134 
NAME 'printer-more-info' 
DESC 'A URI used to obtain more information about this specific printer.  
For example, this could be an HTTP type URI referencing an HTML page 
accessible to a Web Browser.  
The information obtained from this URI is intended for end user consumption.' 
EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

( 1.3.18.0.2.4.1138 
NAME 'printer-make-and-model' 
DESC 'Identifies the make and model of the device.  
The device manufacturer MAY initially populate this attribute.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}  SINGLE-VALUE )

( 1.3.18.0.2.4.1133 
NAME 'printer-ipp-versions-supported' 
DESC 'Identifies the IPP protocol version(s) that this printer supports, 
including major and minor versions, 
i.e., the version numbers for which this Printer implementation meets 
the conformance requirements.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1132 
NAME 'printer-multiple-document-jobs-supported' 
DESC 'Indicates whether or not the printer supports more than one 
document per job, i.e., more than one Send-Document or Send-Data 
operation with document data.' 
EQUALITY booleanMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )

( 1.3.18.0.2.4.1109 
NAME 'printer-charset-configured' 
DESC 'The configured charset in which error and status messages will be 
generated (by default) by this printer.  
Also, a possible charset for printer string attributes set by operator, 
system administrator, or manufacturer.  
For example: "utf-8" (ISO 10646/Unicode) or "iso-8859-1" (Latin1).  
Legal values are defined by the IANA Registry of Coded Character Sets and 
the "(preferred MIME name)" SHALL be used as the tag.  
For coherence with IPP Model, charset tags in this attribute SHALL be 
lowercase normalized.  
This attribute SHOULD be static (time of registration) and SHOULD NOT be
dynamically refreshed attributetypes: (subsequently).' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63} SINGLE-VALUE )

( 1.3.18.0.2.4.1131 
NAME 'printer-charset-supported' 
DESC 'Identifies the set of charsets supported for attribute type values of 
type Directory String for this directory entry.  
For example: "utf-8" (ISO 10646/Unicode) or "iso-8859-1" (Latin1).  
Legal values are defined by the IANA Registry of Coded Character Sets and 
the preferred MIME name.' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63} )

( 1.3.18.0.2.4.1137 
NAME 'printer-generated-natural-language-supported' 
DESC 'Identifies the natural language(s) supported for this directory entry.  
For example: "en-us" (US English) or "fr-fr" (French in France).  
Legal values conform to [RFC3066], Tags for the Identification of Languages.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{63} )

( 1.3.18.0.2.4.1130 
NAME 'printer-document-format-supported' 
DESC 'The possible document formats in which data may be interpreted 
and printed by this printer.  
Legal values are MIME types come from the IANA Registry of Internet Media Types.' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1129 
NAME 'printer-color-supported' 
DESC 'Indicates whether this printer is capable of any type of color printing 
at all, including highlight color.' 
EQUALITY booleanMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.7  SINGLE-VALUE )

( 1.3.18.0.2.4.1128 
NAME 'printer-compression-supported' 
DESC 'Compression algorithms supported by this printer.  
For example: "deflate, gzip".  Legal values include; "none", "deflate" 
attributetypes: (public domain ZIP), "gzip" (GNU ZIP), "compress" (UNIX).' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1127 
NAME 'printer-pages-per-minute' 
DESC 'The nominal number of pages per minute which may be output by this 
printer (e.g., a simplex or black-and-white printer).  
This attribute is informative, NOT a service guarantee.  
Typically, it is the value used in marketing literature to describe this printer.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1126 NAME 'printer-pages-per-minute-color' 
DESC 'The nominal number of color pages per minute which may be output by this 
printer (e.g., a simplex or color printer).  
This attribute is informative, NOT a service guarantee.  
Typically, it is the value used in marketing literature to describe this printer.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1125 NAME 'printer-finishings-supported' 
DESC 'The possible finishing operations supported by this printer. 
Legal values include; "none", "staple", "punch", "cover", "bind", "saddle-stitch", 
"edge-stitch", "staple-top-left", "staple-bottom-left", "staple-top-right", 
"staple-bottom-right", "edge-stitch-left", "edge-stitch-top", "edge-stitch-right", 
"edge-stitch-bottom", "staple-dual-left", "staple-dual-top", "staple-dual-right", 
"staple-dual-bottom".' 
EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1124 NAME 'printer-number-up-supported' 
DESC 'The possible numbers of print-stream pages to impose upon a single side of 
an instance of a selected medium. Legal values include; 1, 2, and 4.  
Implementations may support other values.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27 )

( 1.3.18.0.2.4.1123 NAME 'printer-sides-supported' 
DESC 'The number of impression sides (one or two) and the two-sided impression 
rotations supported by this printer.  
Legal values include; "one-sided", "two-sided-long-edge", "two-sided-short-edge".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1122 NAME 'printer-media-supported' 
DESC 'The standard names/types/sizes (and optional color suffixes) of the media 
supported by this printer.  
For example: "iso-a4",  "envelope", or "na-letter-white".  
Legal values  conform to ISO 10175, Document Printing Application (DPA), and any 
IANA registered extensions.'
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1117 NAME 'printer-media-local-supported' 
DESC 'Site-specific names of media supported by this printer, in the language in 
"printer-natural-language-configured".  
For example: "purchasing-form" (site-specific name) as opposed to 
(in "printer-media-supported"): "na-letter" (standard keyword from ISO 10175).' 
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1121 NAME 'printer-resolution-supported' 
DESC 'List of resolutions supported for printing documents by this printer.  
Each resolution value is a string with 3 fields:  
1) Cross feed direction resolution (positive integer), 2) Feed direction 
resolution (positive integer), 3) Resolution unit.  
Legal values are "dpi" (dots per inch) and "dpcm" (dots per centimeter).  
Each resolution field is delimited by ">".  For example:  "300> 300> dpi>".' 
EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255} )

( 1.3.18.0.2.4.1120 NAME 'printer-print-quality-supported' 
DESC 'List of print qualities supported for printing documents on this printer.  
For example: "draft, normal".  Legal values include; "unknown", "draft", "normal", 
"high".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1110 NAME 'printer-job-priority-supported' 
DESC 'Indicates the number of job priority levels supported.  
An IPP conformant printer which supports job priority must always support a 
full range of priorities from "1" to "100" 
(to ensure consistent behavior), therefore this attribute describes the 
"granularity". 
 Legal values of this attribute are from "1" to "100".' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1118 
NAME 'printer-copies-supported' 
DESC 'The maximum number of copies of a document that may be printed as a single job.  
A value of "0" indicates no maximum limit.  
A value of "-1" indicates unknown.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1111 
NAME 'printer-job-k-octets-supported' 
DESC 'The maximum size in kilobytes (1,024 octets actually) incoming print job that 
this printer will accept.  
A value of "0" indicates no maximum limit.  A value of "-1" indicates unknown.' 
EQUALITY integerMatch 
ORDERING integerOrderingMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.27  SINGLE-VALUE )

( 1.3.18.0.2.4.1113 
NAME 'printer-service-person' 
DESC 'The name of the current human service person responsible for servicing this 
printer.  
It is suggested that this string include information that would enable other humans 
to reach the service person, such as a phone number.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127}  
SINGLE-VALUE )

( 1.3.18.0.2.4.1114 
NAME 'printer-delivery-orientation-supported' 
DESC 'The possible delivery orientations of pages as they are printed and ejected 
from this printer.  
Legal values include; "unknown", "face-up", and "face-down".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1115 
NAME 'printer-stacking-order-supported' 
DESC 'The possible stacking order of pages as they are printed and ejected from 
this printer. 
Legal values include; "unknown", "first-to-last", "last-to-first".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1116 
NAME 'printer-output-features-supported' 
DESC 'The possible output features supported by this printer. 
Legal values include; "unknown", "bursting", "decollating", "page-collating", 
"offset-stacking".' 
EQUALITY caseIgnoreMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.18.0.2.4.1108 
NAME 'printer-aliases' 
DESC 'Site-specific administrative names of this printer in addition the printer 
name specified for printer-name.' 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{127} )

( 1.3.6.1.4.1.42.2.27.5.1.63 
NAME 'sun-printer-bsdaddr' 
DESC 'Sets the server, print queue destination name and whether the client generates 
protocol extensions. 
"Solaris" specifies a Solaris print server extension. The value is represented b the 
following value: server "," destination ", Solaris".' 
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )

( 1.3.6.1.4.1.42.2.27.5.1.64 
NAME 'sun-printer-kvp' 
DESC 'This attribute contains a set of key value pairs which may have meaning to the 
print subsystem or may be user defined. 
Each value is represented by the following: key "=" value.' 
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )

Internet Print Protocol (IPP) ObjectClasses

objectclasses: ( 1.3.18.0.2.6.2549 
NAME 'slpService' 
DESC 'DUMMY definition' 
SUP 'top' MUST (objectclass) MAY ())

objectclasses: ( 1.3.18.0.2.6.254 
NAME 'slpServicePrinter' 
DESC 'Service Location Protocol (SLP) information.' 
AUXILIARY SUP 'slpService')

objectclasses: ( 1.3.18.0.2.6.258 
NAME 'printerAbstract' 
DESC 'Printer related information.' 
ABSTRACT SUP 'top' MAY ( printer-name 
$ printer-natural-language-configured 
$ printer-location 
$ printer-info 
$ printer-more-info 
$ printer-make-and-model 
$ printer-multiple-document-jobs-supported 
$ printer-charset-configured 
$ printer-charset-supported 
$ printer-generated-natural-language-supported 
$ printer-document-format-supported 
$ printer-color-supported 
$ printer-compression-supported 
$ printer-pages-per-minute 
$ printer-pages-per-minute-color 
$ printer-finishings-supported 
$ printer-number-up-supported 
$ printer-sides-supported 
$ printer-media-supported 
$ printer-media-local-supported 
$ printer-resolution-supported 
$ printer-print-quality-supported 
$ printer-job-priority-supported 
$ printer-copies-supported 
$ printer-job-k-octets-supported 
$ printer-current-operator 
$ printer-service-person 
$ printer-delivery-orientation-supported 
$ printer-stacking-order-supported $ printer! -output-features-supported ))

objectclasses: ( 1.3.18.0.2.6.255 
NAME 'printerService' 
DESC 'Printer information.' 
STRUCTURAL SUP 'printerAbstract' MAY ( printer-uri 
$ printer-xri-supported ))

objectclasses: ( 1.3.18.0.2.6.257 
NAME 'printerServiceAuxClass' 
DESC 'Printer information.' 
AUXILIARY SUP 'printerAbstract' MAY ( printer-uri $ printer-xri-supported ))

objectclasses: ( 1.3.18.0.2.6.256 
NAME 'printerIPP' 
DESC 'Internet Printing Protocol (IPP) information.' 
AUXILIARY SUP 'top' MAY   ( printer-ipp-versions-supported $ 
printer-multiple-document-jobs-supported ))

objectclasses: ( 1.3.18.0.2.6.253 
NAME 'printerLPR' 
DESC 'LPR information.' 
AUXILIARY SUP 'top' MUST ( printer-name ) MAY ( printer-aliases))

objectclasses: ( 1.3.6.1.4.1.42.2.27.5.2.14 
NAME 'sunPrinter' 
DESC 'Sun printer information' 
SUP 'top' AUXILIARY MUST (objectclass $ printer-name)  MAY 
(sun-printer-bsdaddr $ sun-printer-kvp))

Sun Printer Attributes

ATTRIBUTE ( 1.3.6.1.4.1.42.2.27.5.1.63
NAME sun-printer-bsdaddr
DESC 'Sets the server, print queue destination name and whether the 
     client generates protocol extensions. "Solaris" specifies a 
     Solaris print server extension.  The value is represented by 
     the following value: server "," destination ", Solaris".'
EQUALITY caseIgnoreIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15   
SINGLE-VALUE
)


ATTRIBUTE ( 1.3.6.1.4.1.42.2.27.5.1.64
NAME sun-printer-kvp
DESC 'This attribute contains a set of key value pairs which may have
      meaning to the print subsystem or may be user defined.  Each
      value is represented by the following: key "=" value.'
EQUALITY caseIgnoreIA5Match 
SYNTAX  1.3.6.1.4.1.1466.115.121.1.15  )

Sun Printer ObjectClasses

OBJECTCLASS ( 1.3.6.1.4.1.42.2.27.5.2.14
NAME sunPrinter
DESC 'Sun printer information'
SUP  top
AUXILIARY
MUST ( printer-name )
MAY  ( sun-printer-bsdaddr $ sun-printer-kvp ))

Generic Directory Server Requirements

To support Solaris 9 LDAP clients, the server, regardless of what brand, must support the LDAP v3 protocol and compound naming and auxiliary object classes. In addition, at least one of the following controls must be supported.

• Simple paged-mode (RFC 2696)

• Virtual List View controls

  The server must support at least one of the following authentication methods.

  • anonymous
  • simple
  • sasl/cram-MD5
  • sasl/digest-MD5

If using pam_unix, the server must support storing passwords in UNIX crypt format.

If using TLS, the server must support SSL or TLS.

Default Filters Used By Naming Services

The following table lists the getent attribute filters.