Part V LDAP Naming Services Setup and Administration

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

Chapter 12 Introduction to LDAP Naming Services (Overview/Reference)

The LDAP chapters describe how to set up a Solaris LDAP naming services client to work with Sun ONE Directory Server (formerly iPlanet Directory Server). However, while using the Sun ONE Directory Server is recommended, it is not required. A brief description of generic directory server requirements appears in Chapter 18, LDAP General Reference (Reference).

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

Audience Assumptions

The LDAP naming services chapters are written for system administrators who already have a working knowledge of LDAP. Following is a partial list of concepts with which you must be very familiar. Otherwise, you might have difficulty using this guide to deploy LDAP naming services in the Solaris environment.

• LDAP Information Model (entries, object classes, attributes, types, 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 Sun ONE 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 and how to design the DIT, topology, replication, and security

Suggested Background Reading

To learn more about any of the aforementioned concepts or to study LDAP and the deployment of directory services in general, refer to the following sources:

• 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. Examples of deployments include a large university, a large multinational enterprise, and an enterprise with an extranet.

• Sun ONE Directory Server Deployment Guide, which is included in the documentation CD.

  This guide provides a foundation for planning your directory, including directory design, schema design, the directory tree, topology, replication, and security. The last chapter provides sample deployment scenarios to help you plan both simple, smaller-scale deployments and complex worldwide deployments.

• Sun ONE Directory Server Administration Guide, which is included in the documentation CD.

Additional Prerequisite

If you need to install Sun ONE Directory Server, refer to the Installation Guide for the version of Sun ONE Directory Server that you are using.

LDAP Naming Services Compared to Other Naming Services

The following table shows a comparison between the FNS, DNS, NIS, NIS+, and LDAP naming services.

Advantages of LDAP Naming Services

• LDAP enables you to consolidate information by replacing application-specific databases, which reduces the number of distinct databases to be managed.

• LDAP allows data to be shared by different naming services.

• LDAP provides a central repository for data.

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

• LDAP is multi-platform and multi-vendor compatible.

Restrictions of LDAP Naming Services

Following are some restrictions associated with LDAP naming services:

• Clients prior to Solaris 8 are not supported.

• An LDAP server cannot be its own client.

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

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

LDAP Naming Services Setup (Task Map)

Chapter 13 Basic Components and Concepts (Overview)

This chapter covers the following topics.

• LDAP Data Interchange Format (LDIF)

• Using Fully Qualified Domain Names

• Default Directory Information Tree (DIT)

• Default Schema

• Service Search Descriptors (SSDs) and Schema Mapping

• Client Profiles

• ldap_cachemgr Daemon

• LDAP Naming Services Security Model

LDAP Data Interchange Format (LDIF)

LDIF is a text-based format for describing directory service entities and their attributes. Using LDIF format you can move information from one directory to another with commands such as ldapadd and ldapmodify. The following are examples of LDIF format for each service. Use ldaplist(1) with the -l option to display the following information.

% ldaplist -l hosts myhost

hosts

dn: cn=myhost+ipHostNumber=7.7.7.115,ou=Hosts,dc=mydc,dc=mycom,dc=com
cn: myhost
iphostnumber: 7.7.7.115
objectclass: top
objectclass: device
objectclass: ipHost
description: host 1 - floor 1 - Lab a - building b

% ldaplist -l passwd user1

passwd

dn: uid=user1,ou=People,dc=mydc,dc=mycom,dc=com
uid: user1
cn: user1
userpassword: {crypt}duTx91g7PoNzE
uidnumber: 199995
gidnumber: 20
gecos: Joe Smith [New York]
homedirectory: /home/user1
loginshell: /bin/csh
objectclass: top
objectclass: shadowAccount
objectclass: account
objectclass: posixAccount

% ldaplist -l services name

services

dn: cn=name+ipServiceProtocol=udp,ou=Services,dc=mydc,dc=mycom,dc=com
cn: name
cn: nameserver
ipserviceprotocol: udp
ipserviceport: 42
objectclass: top
objectclass: ipService

% ldaplist -l group mygroup

group

dn: cn=mygroup,ou=Group,dc=mydc,dc=mycom,dc=com
cn: mygroup
gidnumber: 4441
memberuid: user1
memberuid: user2
memberuid: user3
userpassword: {crypt}duTx91g7PoNzE
objectclass: top
objectclass: posixGroup

% ldaplist -l netgroup mynetgroup

netgroup

cn=mynetgroup,ou=netgroup,dc=central,dc=sun,dc=com
objectclass=nisNetgroup
objectclass=top
cn=mynetgroup
nisnetgrouptriple=(user1..mydc.mycom.com,-,)
nisnetgrouptriple=(user1.,-,)
membernisnetgroup=mylab

% ldaplist -l networks 200.20.20.0

networks

dn: ipNetworkNumber=200.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com
cn: mynet-200-20-20
ipnetworknumber: 200.20.20.0
objectclass: top
objectclass: ipNetwork
description: my Lab Network
ipnetmasknumber: 255.255.255.0

% ldaplist -l netmasks 201.20.20.0

netmasks

dn: ipNetworkNumber=201.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com
cn: net-201
ipnetworknumber: 201.20.20.0
objectclass: top
objectclass: ipNetwork
description: my net 201
ipnetmasknumber: 255.255.255.0

% ldaplist -l rpc ypserv

rpc

dn: cn=ypserv,ou=Rpc,dc=mydc,dc=mycom,dc=com
cn: ypserv
cn: ypprog
oncrpcnumber: 100004
objectclass: top
objectclass: oncRpc

% ldaplist -l protocols tcp

protocols

dn: cn=tcp,ou=Protocols,dc=mydc,dc=mycom,dc=com
cn: tcp
ipprotocolnumber: 6
description: transmission control protocol
objectclass: top
objectclass: ipProtocol

% ldaplist -l bootparams myhost

bootparams

dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com
bootparameter: root=boothost:/export/a/b/c/d/e
objectclass: top
objectclass: device
objectclass: bootableDevice
cn: myhost

% ldaplist -l ethers myhost

ethers

dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com
macaddress: 8:1:21:71:31:c1
objectclass: top
objectclass: device
objectclass: ieee802Device
cn: myhost

% ldaplist -l publickey myhost

publickey

dn: cn=myhost+ipHostNumber=200.20.20.99,ou=Hosts,dc=mydc,dc=mycom,dc=com
cn: myhost
iphostnumber: 200.20.20.99
description: Joe Smith
nispublickey: 9cc01614d929848849add28d090acdaa1c78270aeec969c9
nissecretkey: 9999999998769c999c39e7a6ed4e7afd687d4b99908b4de99
objectclass: top
objectclass: NisKeyObject
objectclass: device
objectclass: ipHost

% ldaplist -l aliases myname

aliases

dn: mail=myname,ou=aliases,dc=mydc,dc=mycom,dc=com
cn: myname
mail: myname
objectclass: top
objectclass: mailgroup
mgrprfc822mailmember: my.name

Using Fully Qualified Domain Names

Unlike NIS or NIS+ clients, an LDAP client always returns a fully qualified domain name (FQDN) for a host name. The LDAP FQDN is similar to the FQDN returned by DNS. For example, suppose your domain name is the following:

west.example.net

Both gethostbyname() and getnameinfo() return the FQDN version when looking up the host name server:

server.west.example.net

Also, if you use interface-specific aliases such as server-#, a long list of fully qualified host names are returned. If you are using host names to share file systems or have other such checks, you must account for the checks. For example, if you assume non-FQDNs for local hosts and FQDNs only for remote DNS-resolved hosts, you must account for the difference. If you set up LDAP with a different domain name from DNS, the same host might end up with two different FQDNs, depending on the lookup source.

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 a 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 well known containers that hold entries for a specific information type. See the following table for the names of these subtrees. (This information can be found in RFC 2307 and others.)

Default Schema

Schemas are definitions describing what types of information can be stored as entries in an LDAP directory. To support 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, LDAP General Reference (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. Make sure the syntax of the mapped attribute is consistent with the attribute it is mapped to. In other words, make sure that single-valued attributes map to single-valued attributes, that the attribute syntaxes are in agreement, and that mapped object classes have the correct mandatory (possibly mapped) attributes.

As previously discussed, LDAP naming services expect, by default, the DIT to be structured in a certain way. If you want, 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 LDAP Naming Services.

Description of 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.

The default location is not searched for a service (database) with an SSD unless it is included in the SSD. Unpredictable behavior will result if multiple SSDs are given for 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 look up 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 look up 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 containers with a particular service type.

For example, the following service search descriptor 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.

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

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, LDAP General Reference (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 might 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 for this attribute is service:attribute-name=mapped-attribute-name.

If you want 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 used 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

This 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 want 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 table shows the Solaris LDAP client's profile attributes, which can be set automatically when you run idsconfig. See Initializing a Client Manually and the idsconfig(1M) man page 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. See the ldapclient(1M) man page for more information.

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 are appended to the BaseDN before a search is performed.

ldap_cachemgr Daemon

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

• Gains access to the configuration files, running as root

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

• Maintains a sorted list of active LDAP servers to use

• Improves lookup efficiency by caching some common lookup requests submitted by various clients

• Improves the efficiency of host lookups

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

Refer to the ldap_cachemgr(1M) man page for detailed information.

LDAP Naming Services Security Model

Introduction

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

To access the information 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 Administration Guide for the version of Sun ONE Directory Server that you are using.

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 the server. Once the client has established its identity, it can then make the various LDAP requests.

There is a distinction between how the naming service and the authentication service (pam_ldap) access the directory. The naming service reads various entries and their attributes from the directory based on predefined identity. The authentication service establishes whether the user has entered the correct password by using that user's name and password to authenticate to the LDAP server. See the pam_ldap(5) man page for more information about the authentication service.

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 superset of the Secure Sockets Layer (SSL) protocol. Solaris LDAP naming services support TLS connections. Be aware that using SSL adds load to the directory server and the client.

You will need to set up your directory server for SSL. For more information about setting up Sun ONE Directory Server for SSL, see the Administration Guide for the version of Sun ONE Directory Server that you are using. You will also need to set up your LDAP client for SSL.

In order to use TLS for Solaris LDAP naming services, 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 Setting Up TLS Security for more information.

Assigning Client Credential Levels

LDAP naming services clients authenticate to the LDAP server according to a client's 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 can access only the 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 has read access. If you use an anonymous credential level, you 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.

Sun ONE Directory Server 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. For more information, see “Managing Access Control” in the Administration Guide for the version of Sun ONE Directory Server that you are using.

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 need to configure the proxyDN and proxyPassword on every client using the proxy credential level. The encrypted proxyPassword is stored locally on the client. You can set up 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, 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 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, depending on your environment. See Credential Storage 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 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 lockout, 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, Solaris 9 LDAP naming services do 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, Setting Up Clients (Tasks) 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.

LDAP naming services support 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 unless the session is protected by ipsec(7). The primary advantages of using the simple authentication method are 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 Sun ONE Directory Server, 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.

  ---

  Note –

  If you are using Sun ONE Directory Server, the password must be stored in the clear in the directory.

  ---

• 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. cram-MD5 is only supported by some directory servers. For instance, Sun ONE Directory Server does not support cram-MD5.

• tls:simple

  The client binds using the 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.

Sun ONE Directory Server 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 especially careful that the userPassword attribute has the proper ACIs if it is stored in the clear, so that it is not readable.

The following table summarizes the various authentication methods and their respective characteristics.

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(5).

  pam_ldap supports account management.

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(5) or pam_ldap(5) in conjunction with LDAP.

Because of its increased flexibility, support of stronger authentication methods, and ability to use account management, 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 the following:

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 whether the user should be authenticated.

Additionally, there are two restrictions when using pam_unix.

• 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 the sasl authentication method digest-MD5, since Sun ONE Directory Server requires passwords to be stored in the clear in order to use digest-MD5. pam_unix requires the password be stored in crypt format.

See the pam_unix(5) man page for details.

pam_ldap

When using , the user binds to the LDAP server using the authentication method defined in pam_ldap's serviceAuthenticationMethod parameter, if one exists. Otherwise, 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_ldap. pam_ldap does not support the none authentication method. Thus, you must define the serviceAuthenticationMethod or the authenticationMethod attributes so clients can use pam_ldap. See the pam_ldap(5) man page for more information.

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

See Example pam.conf File for pam_ldap.

The following table summarizes the main differences between pam_unix and pam_ldap. See the pam_unix(5) and pam_ldap(5) man pages for more information.

PAM and Changing Passwords

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

In the case of pam_unix(5), the new userPassword attribute is encrypted using UNIX crypt format 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 unencrypted. Therefore, to insure privacy, use TLS. If TLS is not used, the new userPassword will be subject to snooping.

When setting the password with pam_ldap(5) with Sun ONE Directory Server, the password is encrypted using the passwordStorageScheme (as it is untagged). For more information about the passwordStorageScheme attribute, see “User Account Management” in the Administration Guide for the version of Sun ONE Directory Server that you are using.

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 Sun ONE Directory Server, passwordStorageScheme must be set to clear. See the following section for more information.

Using Sun ONE Directory Server With digest-MD5

If you are using the Sun ONE Directory Server with digest-MD5, a user who changes her password will not be able to login with the new password if the change fails for any password management reason.

For example, is password history is enabled on the server and the user attempts to change her password to a previously used password, pam_ldap fails to change the password due to the constraint violations (a previously used password in this case). pam ignores pam_ldap and falls through to pam_unix. As a result, the password is stored in crypt format and not in the clear. Consequently, the next time the user attempts to login with her new password, her login will fail.

To avoid having pam_ldap “fall through” to pam_unix, use the following configuration on all clients' pam.conf files:

  other   password required        pam_dhkeys.so.1
  other   password requisite       pam_authtok_get.so.1
  other   password requisite       pam_authtok_check.so.1
  other   password binding         pam_authtok_store.so.1 server_policy

Note that there is no pam_ldap.so.1 in the above configuration. The server_policy specifies that pam_authtok_store.so.1 should always send clear text for LDAP accounts to the directory server and allows the server to store the password according to its own password encryption scheme. However, when using the above configuration, you also need the matching authentication configurations. For example, use the following configuration:

login     auth     binding    pam_unix_auth.so.1 server_policy
login     auth     required   pam_ldap.so.1

and

passwd     auth    binding     pam_passwd_auth.so.1    server_policy
passwd     auth    required    pam_ldap.so.1

Make sure that every client in the same directory naming domain uses the configuration above. If even one client is using a different pam.conf, if a user changes her password on that system, login authentication will fail on the rest of the clients.

Password Management

LDAP naming services take advantage of the password and account lockout policy support in Sun ONE Directory Server. You can configure pam_ldap(5) to support user account management. passwd(1) enforces password syntax rules set by the Sun ONE Directory Server password policy, when used with the proper PAM configuration.

The following password management features are supported through pam_ldap(5). These features depend on Sun ONE Directory Server's password and account lockout policy configuration. You can enable as many or as few of the features as you want.

• Password aging and expiration notification

  Users must change their passwords according to a schedule. A password expires if it is not changed within the time configured. An expired password causes user authentication to fail.

  Users see a warning message whenever they log in within the expiration warning period. The message specifies the number of hours or days until the password expires.

• Password syntax checking

  New passwords must meet the minimum password length requirements. In addition, a password cannot match the value of the uid, cn, sn, or mail attributes in the user's directory entry.

• Password in history checking

  Users cannot reuse passwords. If a user attempts to change the password to one that was previously used, passwd(1) fails. LDAP administrators can configure the number of passwords kept in the server's history list.

• User account lockout

  A user account can be locked out after a given number of repeated authentication failures. A user can also be locked out if his account is inactivated by an administrator. Authentication will continue to fail until the account lockout time is passed or the administrator reactivates the account.

The preceding password management features only work with the Sun ONE Directory Server version bundled with Solaris 9. For information about configuring the password and account lockout policy on the server, see the “User Account Management” chapter in the Administration Guide for the version of Sun ONE Directory Server that you are using. Also see Example pam_conf file for pam_ldap Configured for Password Management. Do not enable password management for proxy accounts.

Before configuring the password and account lockout policy on Sun ONE Directory Server, make sure all hosts use the “newest” LDAP client with pam_ldap password management.

In addition, make sure the clients have a properly configured pam.conf(4) file. Otherwise, LDAP naming services will not work when proxy or user passwords expire.

Chapter 14 Planning Requirements for LDAP Naming Services (Tasks)

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

This chapter covers the following topics.

• Planning 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

Planning Overview

The LDAP client profile is a collection of configuration information an LDAP client uses to access LDAP naming services information about the supporting LDAP server. This chapter discusses 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, each subnet of the company-wide network should have its own LDAP server to service all the LDAP clients in the subnet. Only one of the servers 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 a client would be able to get to the servers, and in what order the servers should be accessed. If there is one per subnet, you 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 a certain order due to speed or data management reasons, you 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 might 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. The profileTTL attribute can be used to control how often the LDAP client should download its profile from the servers. For a slow or unstable network, the bindTimeLimit and searchTimeLimit attributes might need a larger value than the defaults. For early stage testing of the deployment, you might 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)

LDAP naming services have a default directory information tree (DIT) and an 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 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) in the directory tree the naming services 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.

The 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 object class to an existing object class, myAccount, for example. You can map an attribute in the posixAccount object class to an attribute in the myAccount object class.

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 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 Chapter 11, Sun ONE Directory Server Configuration for information about how to choose an appropriate directory suffix.

Replica Servers

There are three different strategies to employ when setting up 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 the 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 partitioned 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.

For information about how to set up replica servers, refer to the Administration Guide for the version of Sun ONE Directory Server that you are using.

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. For example, you must decide 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 Services 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 backward 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 about ACIs, consult the Administration Guide for the version of Sun ONE Directory Server that you are using.

Planning Client Profiles and Default Attribute Values

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

• cn

• defaultServerList

• preferredServerList

• bindTimeLimit

• searchTimeLimit

• profileTTL

• defaultSearchBase

• defaultSearchScope

• serviceSearchDescriptor

• attributeMap

• objectclassMap

• followReferrals

• credentialLevel

• authenticationMethod

• serviceCredentialLevel

• serviceAuthenticationMethod

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

See Chapter 16, Setting Up Clients (Tasks) for more information about setting up LDAP clients.

Planning the Data Population

To populate the LDAP server with data, after the LDAP server has been configured with the proper DIT and schema. 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 types 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.

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

For better performance, load the databases in this order:

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 add 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 the files, or perform ldapaddent on the different hosts one by one, with the expectation that each host is already configured as a LDAP client.

If your naming service data is already in an 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. Then, run ldapaddent against these files to add the data to the LDAP server.

ldapaddent can only be run on an LDAP client.

The following procedure assumes that the tables are to be extracted from a yp client.

How to Populate a Server With host Entries Using ldapaddent

1. Make sure that Sun ONE Directory Server was set up using idsconfig.

2. Become superuser on a client machine.

3. Make the machine an LDAP client.

   # ldapclient —p —d domainName=west.example.com 192.168.0.0

4. Populate the server with data.

   # ldapaddent —h 192.168.0.0 —D directory_manager —f /etc/hosts hosts

In this example, the directory_manager password would be sent in the clear, as currently, ldapaddent binds using the simple authentication method.

Chapter 15 Setting Up Sun ONE Directory Server (Tasks)

This chapter describes how to configure Sun ONE Directory Server (formerly iPlanet Directory Server) to support a network of Solaris LDAP naming services clients. The information is specific to the Sun ONE Directory Server.

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

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

This chapter covers the following topics.

• Configuring Sun ONE Directory Server 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 Directory Server With Additional Profiles

• Configuring the Directory Server to Enable Password Management

Configuring Sun ONE Directory Server 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 Indexes

idsconfig indexes the following list of attributes for improved performance.

membernisnetgroup

pres,eq,sub

nisnetgrouptriple

pres,eq,sub

memberuid

pres,eq

uidNumber

pres,eq

gidNumber

pres,eq

ipHostNumber

pres,eq

ipNetworkNumber

pres,eq

ipProtocolNumber

pres,eq

oncRpcNumber

pres,eq

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, LDAP General Reference (Reference) for an extended list of schemas used by the LDAP naming service.

Using Browsing Indexes

The browsing index functionality of the Sun ONE 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.

Before configuring browsing indexes on the Sun ONE Directory Server, consider the performance cost associated with using these indexes. For more information, refer to the Administration Guide for the version of Sun ONE Directory Server that you are using.

In the following example, note that the -n option denotes the name of the database with the entries to be indexed 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 transitional 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 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 Sun ONE Directory Server 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 do 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 Sun ONE Directory Server Using idsconfig

1. Make sure the target Sun ONE Directory Server 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

# usr/lib/ldap/idsconfig
It is strongly recommended that you BACKUP the directory server
before running idsconfig.

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 directory server's 
hostname to setup: myserver

Enter the port number for  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 iDS (current=3600): [-1]

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

Enter the size limit for iDS (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  iDS Time Limit                : -1
 11  iDS 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:
      west.example.com.getgrent vlv_index   Entry created
      west.example.com.gethostent vlv_index   Entry created
      west.example.com.getnetent vlv_index   Entry created
      west.example.com.getpwent vlv_index   Entry created
      west.example.com.getrpcent vlv_index   Entry created
      west.example.com.getspent vlv_index   Entry created

idsconfig: Setup of directory 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 west.example.com.getgrent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.gethostent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getnetent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getpwent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getrpcent
  directoryserver -s ipdserver vlvindex -n userRoot -T west.example.com.getspent

Any parameters left blank in the summary screen will not be set up.

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 about setting the password in UNIX crypt format, see the Sun ONE Directory Server documents.

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.

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

How to Populate Sun ONE Directory Server With User Password Data Using ldapaddent

1. Use the ldapaddent command to add /etc/passwd entries 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 about LDAP security and write-access to the directory server.

Managing Printer Entries

Adding Printers

To add printer entries to 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 might 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, 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 Directory Server With Additional Profiles

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

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

How to Populate the Directory Server With Additional Profiles Using ldapclient

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

Configuring the Directory Server to Enable Password Management

In order for pam_ldap to work properly, the password and account lockout policy must be properly configured on the server. You can use the Directory Server Console or ldapmodify to configure the password management policy for the LDAP directory. For procedures and more information, see the “User Account Management” chapter in the Administration Guide for the version of Sun ONE Directory Server that you are using.

Passwords for proxy users should never be allowed to expire. If proxy passwords expire, clients using the proxy credential level cannot retrieve naming service information from the server. To ensure that proxy users have passwords that do not expire, modify the proxy accounts with the following script.

# ldapmodify -h ldapserver —D administrator DN \
-w  administrator password <<EOF 
dn: proxy user DN
DNchangetype: modify
replace: passwordexpirationtime
passwordexpirationtime: 20380119031407Z
EOF

pam_ldap password management relies on Sun ONE Directory Server to maintain and provide password aging and account expiration information for users. The directory server does not interpret the corresponding data from shadow entries to validate user accounts. pam_unix, however, examines the shadow data to determine if accounts are locked or if passwords are aged. Since the shadow data is not kept up to date by the LDAP naming services or the directory server, pam_unix should not grant access based on the shadow data. The shadow data is retrieved using the proxy identity. Therefore, do not allow proxy users to have read access to the userPassword Attribute. Denying proxy users read access to userPassword prevents pam_unix from making an invalid account validation.

Chapter 16 Setting Up Clients (Tasks)

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

This chapter covers the following topics.

• Prerequisites to Client Setup

• Initializing a Client

• Using Profiles to Initialize a Client

• Using Proxy Credentials

• Initializing a Client Manually

• Modifying a Manual Client Configuration

• Uninitializing a Client

• Setting Up TLS Security

Prerequisites to Client Setup

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

• 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 a utility used to setup LDAP clients in the 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 clients.

There are two main 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 want 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 from 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 -p.

   # ldapclient -p new \

   -d 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 -p profilename -D cn=proxyagent,ou=profile,dc=west,dc=example,dc=com -d west.example.com -p pit1 -w test1234 192.168.0.0

   System successfully configured

The values for -D and -w 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 must 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 information is used to create /var/ldap/ldap_client_cred. The rest of the information is put in /var/ldap/ldap_client_file.

Do not edit either of 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 -i to initialize the client.

   # ldapclient -i –d dc=west.example.com \

   -c dc=west, dc=example, dc=com \

   -D cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \

   -w 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 -m to change the authentication method to simple.

   # ldapclient -m -a 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

Uninitializing a Client

How to Uninitialize a Client

1. Become superuser.

2. Use ldapclient.

   # 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.

Setting Up TLS Security

The cert7.db and key3.db files must be readable by everyone. Do 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. Even if 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 about configuring LDAP clients to use SSL in the “Managing SSL” chapter of the Administrator's Guide for the version of Sun ONE Directory Server you are using. 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 services 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^TM, copy the files 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 files in the $HOME/.netscape directory. Copies of these security databases must be stored on a local file system if you are using them for an LDAP naming services client.

Configuring PAM

You can configure pam_ldap with or without password management support. Choose the appropriate procedure for your configuration from the following two options.

Using pam_ldap Without Password Management Support

If you are using pam_ldap without password management support, follow the sample pam.conf file in Example pam.conf File for pam_ldap. Add the lines that contain pam_ldap.so.1 to the client's /etc/pam.conf file. For details, see pam.conf(4).

Configuring pam_ldap for Password Management Support

If you need to configure pam_ldap for password management support, copy the sample pam.conf file in Example pam_conf file for pam_ldap Configured for Password Management. Then, add the lines that contain pam_ldap.so.1 to the client's /etc/pam.conf file. In addition, if any PAM module in the sample pam.conf file specifies the binding control flag and the server_policy option, use the same flag and option for the corresponding module in the client's /etc/pam.conf file. Also, add the server_policy option to the line that contains the service module pam_authtok_store.so.1.

• The binding control flag

  Using the binding control flag allows a local password override of a remote (LDAP) password. For example, if a user account is found on both the local files and the LDAP namespace, the password associated with the local account takes precedence over the remote password. Thus, if the local password expires, authentication fails even if the remote LDAP password is still valid.

• The server_policy option

  The server_policy option instructs pam_unix to ignore a user found in the LDAP namespace and to allow pam_ldap to perform authentication or account validation. In the case of pam_authtok_store.so.1, a new password is passed to the LDAP server without encryption. The password is thereby stored in the directory according to the password encryption scheme configured on the server. For more information, see pam.conf(4) and pam_ldap(5).

Retrieving LDAP Naming Services Information

You can retrieve information about LDAP naming services by using the ldaplist utility. This LDAP utility lists 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

The following sections describe how you can customize the client environment.

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.

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.

Enabling DNS

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

hosts:      ldap dns [NOTFOUND=return] files

Chapter 17 LDAP Troubleshooting (Reference)

This chapter describes configuration problems and suggests solutions for resolving them.

Monitoring Client Status

The following sections show various commands to help determine the state of the LDAP client environment. Also see the man pages for additional information about 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, the system doesn't work. There are two ways to check if ldap_cachemgr is running.

• Use the ps command with the ef option.

  # ps -ef | grep ldap_cachemgr

• Pass the -g option to ldap_cachemgr.

  This option provided status information, which is useful when you are diagnosing 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 -l option.

# ldapclient -l
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. Because the files could change to binary at some time, concatenating 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. Using ldaplist with no arguments dumps 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 in the previous sections assume you already have created 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 sections describe LDAP configuration problems and suggests solutions to the problems.

Unresolved Hostname

The Solaris operating environment LDAP client back end returns fully qualified host names for host lookups, such as host names returned by gethostbyname() and getaddrinfo(). 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 a dot), the client back end 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 modules for user authentication during login. When using the standard UNIX 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 is 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. The proxy agent might not have the correct password.

4. The entry does not have the shadowAccount object class.

5. No password is 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 use ldapaddent without the -p option, the user's password is not stored in the directory unless you also add the /etc/shadow file by using ldapaddent.

6. No 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 is not available to anonymous users.

10. The password is not stored in crypt format.

11. If pam_ldap is configured to support password management, login failure could be the result of one of the following:

    • The user's password has expired.

    • The user's account is locked out due to too many failed login attempts.

    • The user's account has been deactivated by the administrator.

Lookup Too Slow

The LDAP database relies on indexes to improve search performance. A major performance degradation occurs when indexes are improperly configured. The documentation includes 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 -p option. Possible reasons for failure include the following:

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

2. The 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. An incorrect server address passed to the ldapclient command. Use ldapsearch to verify the server address.

5. An incorrect profile name passed to the ldapclient command. Use ldapsearch to verify the profile name in the DIT.

6. Use snoop 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

Using ldap_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 super user to execute this command.

ldapclient Hangs During Setup

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

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

Chapter 18 LDAP General Reference (Reference)

This chapter covers the following topics.

1. Blank Checklists

2. Upgrade Information

3. LDAP Commands

4. 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 LDAP Naming Services

Blank Checklists

Upgrade Information

Solaris 9 clients are compatible with directory servers set up to serve Solaris 9 clients. ldapclient(1M) can download such a profile and configure the client using version 1 profiles. To take advantage of new features built into Solaris 9 and to use the new security model, you must use version 2 profiles.

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 cannot use that server as Solaris 9 clients cannot arbitrarily map their schema.

One additional change is that in Solaris naming clients, running ldap_cachemgr() was recommended, but optional. The ldap_cachemgr() must be running at all times. The daemon is required for the client to function properly.

New automount Schema

By default, Solaris uses a new schema for automount entries instead of using generic NIS map schema which Solaris 9 clients used. This means that if you set up a server with Solaris 9 tools, Solaris clients cannot see the automount entries. For sites where the server being setup is to serve both Solaris 8 and Solaris 9 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 the Solaris operating environment. One set is the general LDAP tools, which do not require the client to be configured with LDAP naming services. The second set uses 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(1), ldapmodify(1), ldapadd(1), and ldapdelete(1) tools support a common text-based format for representing directory information called the LDAP Data Interchange Format (LDIF).

LDAP Tools Requiring LDAP Naming Services

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 authentication

#
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

Example pam_conf file for pam_ldap Configured for Password Management

# PAM configuration
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login  auth     requisite pam_authtok_get.so.1
login  auth     required  pam_dhkeys.so.1
login  auth     required  pam_dial_auth.so.1
login  auth     binding   pam_unix_auth.so.1 server_policy
login  auth     required  pam_ldap.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin  auth     sufficient pam_rhosts_auth.so.1
rlogin  auth     requisite  pam_authtok_get.so.1
rlogin  auth     required   pam_dhkeys.so.1
rlogin  auth     binding    pam_unix_auth.so.1 server_policy
rlogin  auth     required   pam_ldap.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh     auth sufficient         pam_rhosts_auth.so.1
rsh     auth required           pam_unix_auth.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp     auth requisite          pam_authtok_get.so.1
ppp     auth required           pam_dhkeys.so.1
ppp     auth required           pam_dial_auth.so.1
ppp     auth binding            pam_unix_auth.so.1 server_policy
ppp     auth required           pam_ldap.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other   auth requisite          pam_authtok_get.so.1
other   auth required           pam_dhkeys.so.1
other   auth binding            pam_unix_auth.so.1 server_policy
other   auth required           pam_ldap.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd auth     binding   pam_passwd_auth.so.1 server_policy
passwd auth     required  pam_ldap.so.1
#
# 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  binding   pam_unix_account.so.1 server_policy
other  account  required  pam_ldap.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 requisite pam_authtok_get.so.1
other  password requisite pam_authtok_check.so.1
other  password required  pam_authtok_store.so.1 server_policy
#
# 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 that describe what types of information can be stored as entries in a server's directory.

For a directory server to support Solaris 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 three 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 the 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 Web site 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 the following.

( 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

The following sections provide information about the attributes and ObjectClasses for the internet print protocol and the Sun printer.

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 LDAP Naming Services

If you do not manually specify a parameter for a given service using an SSD, the default filter is used. To list the default filters for a given service, use ldaplist with the —v option.

In the following example, filter=(&(objectclass=iphost)(cn=abcde)defines the default filters.

database=hosts
filter=(&(objectclass=iphost)(cn=abcde)
user data=(&(%s) (cn=abcde))

ldaplist generates the following list of default filters, where %s signifies a string and %d, a number.

hosts
(&(objectclass=iphost)(cn=%s))
--------------
passwd
(&(objectclass=posixaccount)(uid=%s))
--------------
services
(&(objectclass=ipservice)(cn=%s))
--------------
group
(&(objectclass=posixgroup)(cn=%s))
--------------
netgroup
(&(objectclass=nisnetgroup)(cn=%s))
--------------
networks
(&(objectclass=ipnetwork)(ipnetworknumber=%s))
--------------
netmasks
(&(objectclass=ipnetwork)(ipnetworknumber=%s))
--------------
rpc
(&(objectclass=oncrpc)(cn=%s))
--------------
protocols
(&(objectclass=ipprotocol)(cn=%s))
--------------
bootparams
(&(objectclass=bootableDevice)(cn=%s))
--------------
ethers
(&(objectclass=ieee802Device)(cn=%s))
--------------
publickey
(&(objectclass=niskeyobject)(cn=%s))
or
(&(objectclass=niskeyobject)(uidnumber=%d))
--------------
aliases
(&(objectclass=mailGroup)(cn=%s))
--------------

The following table lists the getent attribute filters.

Chapter 19 Transitioning From NIS to LDAP (Overview/Tasks)

This chapter describes how to enable support of NIS clients that use naming information stored in the LDAP directory. By following the procedures in this chapter, you can transition from using an NIS naming service to using LDAP naming services.

To determine the benefits of transitioning to LDAP, see LDAP Naming Services Compared to Other Naming Services.

The following information is included in this chapter.

• NIS-to-LDAP Service Overview

• Transitioning From NIS to LDAP (Task Map)

• Prerequisites for the NIS-to-LDAP Transition

• Setting Up the N2L Service

• N2L Best Practices With Sun ONE Directory Server

• N2L Restrictions

• N2L Troubleshooting

• Reverting to NIS

NIS-to-LDAP Service Overview

Enabling the NIS–to–LDAP transition service (N2L service) requires reconfiguring the NIS daemons on the NIS master server. The N2L service is enabled if the daemons find a NIS–to–LDAP mapping file on the master server. The mapping file specifies the mapping between NIS map entries and equivalent Directory Information Tree (DIT) entries in LDAP. An NIS master server that has gone through this transition is referred to as an N2L server. The slave servers do not have an NISLDAPmapping file, so they continue to function in the usual manner. The slave servers periodically update their data from the N2L server as if it were a regular NIS master.

The behavior of the N2L service is controlled by the ypserv and NISLDAPmapping configuration files. A script, inityp2l, assists with the initial setup of these configuration files. Once the N2L server has been established, you can maintain N2L by directly editing the configuration files.

The N2L service supports the following:

• Import of NIS maps into the LDAP Directory Information Tree (DIT)

• Client access to DIT information with the speed and extensibility of NIS

In any naming system, only one source of information can be the authoritative source. In traditional NIS, NIS sources are the authoritative information. When using the N2L service, the source of authoritative data is the LDAP directory. The directory is managed by using directory management tools, as described in Chapter 13, Basic Components and Concepts (Overview).

NIS sources are retained for emergency backup or backout only. After using the N2L service, you can gradually phase out NIS clients. Eventually, all NIS clients can be replaced by Solaris LDAP naming services clients.

Additional overview information is provided in the following subsections:

• N2L Audience Assumptions

• When Not to Use the N2L Service

• Effects of the N2L Service on Users

• NIS-to-LDAP Transition Terminology

• N2L Commands and Files

• Supported Standard Mappings

N2L Audience Assumptions

You need to be familiar with NIS and LDAP concepts, terminology, and IDs to perform the procedures in this chapter. For more information about the NIS and LDAP naming services, see the following sections of this book.

• Chapter 7, Network Information Service (NIS) (Overview), for an overview of NIS

• Chapter 12, Introduction to LDAP Naming Services (Overview/Reference), for an overview of LDAP

When Not to Use the N2L Service

Do not use the N2L service in these situations:

• In an environment where there is no plan to share data between NIS and LDAP naming services clients

  In such an environment, an N2L server would serve as an excessively complex NIS master server.

• In an environment where NIS maps are managed by tools that modify the NIS source files (other than yppasswd)

  Regeneration of NIS sources from DIT maps is an imprecise task that requires manual checking of the resulting maps. Once the N2L service is used, regeneration of NIS sources is provided only for backout or reverting to NIS.

• In an environment with no NIS clients

  In such an environment, use Solaris LDAP naming services clients and their corresponding tools.

Effects of the N2L Service on Users

Simply installing the files that are related to the N2L service does not change the NIS server's default behavior. At installation, the administrator will see some changes to NIS man pages and the addition of N2L helper scripts, inityp2l and ypmap2src, on the servers. But as long as inityp2l is not run or the N2L configuration files are not created manually on the NIS server, the NIS components continue to start in traditional NIS mode and function as usual.

After inityp2l is run, users see some changes in server and client behavior. Following is a list of NIS and LDAP user types and a description of what each type of user should notice after the N2L service is deployed.

NIS-to-LDAP Transition Terminology

The following terms are related to the implementation of the N2L service.

N2L Commands and Files

The following commands and files are associated with the N2L transition.

Supported Standard Mappings

By default, the N2L service supports mappings between the following list of maps and RFC 2307, or its successors', LDAP entries. These standard maps do not require manual modification to the mapping file. Any maps on your system that are not in the following list are considered custom maps and require manual modification.

The N2L service also supports automatic mapping of the auto.* maps. However, since most auto.* file names and contents are specific to each network configuration, those files are not specified in this list. The exceptions to this are the auto.home and auto.master maps, which are supported as standard maps.

audit_user
auth_attr
auto.home
auto.master
bootparams
ethers.byaddr ethers.byname
exec_attr
group.bygid group.byname group.adjunct.byname
hosts.byaddr hosts.byname
ipnodes.byaddr ipnodes.byname
mail.byaddr mail.aliases
netgroup netgroup.byprojid netgroup.byuser netgroup.byhost
netid.byname
netmasks.byaddr
networks.byaddr networks.byname
passwd.byname passwd.byuid passwd.adjunct.byname
printers.conf.byname
prof_attr
project.byname project.byprojectid
protocols.byname protocols.bynumber
publickey.byname
rpc.bynumber
services.byname services.byservicename
timezone.byname
user_attr

Transitioning From NIS to LDAP (Task Map)

The following table identifies the procedures needed to install and manage the N2L service with standard and with custom NIS–to–LDAP mappings.

Prerequisites for the NIS-to-LDAP Transition

Before implementing the N2L service, you must check or complete the following items.

• Make sure that the system is set up as a working traditional NIS server before running the inityp2l script to enable N2L mode.

• Configure the LDAP directory server.

  Sun ONE Directory Server (formerly iPlanet Directory Server) and compatible versions of directory servers offered by Sun Microsystems, Inc., are supported with the NIS-to-LDAP migration tools. If you use Sun ONE Directory Server, configure the server by using the idsconfig command before you set up the N2L service. For more information about idsconfig, see Chapter 15, Setting Up Sun ONE Directory Server (Tasks) and the idsconfig(1M) man page.

  Other (third party) LDAP servers might work with the N2L service, but they are not supported by Sun. If you are using an LDAP server other than the Sun ONE Directory Server or compatible Sun servers, you must manually configure the server to support RFC 2307, or its successors', schemas before you set up the N2L service.

• Make sure that the nsswitch.conf file lists files before nis for the lookup order, at least for the hosts and ipnodes entries.

• Ensure that the addresses of the N2L master server and the LDAP server are present in the hosts or ipnodes files on the N2L master server. Whether the server addresses must be listed in hosts, ipnodes, or both files depends on how your system is configured to resolve local host names.

  An alternative solution is to list the LDAP server address, not its host name, in ypserv. This means that the LDAP server address is listed in another place, so changing the address of either the LDAP server or the N2L master server requires additional file modifications.

Setting Up the N2L Service

You can set up the N2L service either by using standard mappings or by using custom mappings, as described in the next two procedures.

As part of the NIS-to -LDAP conversion, you need to run the inityp2l command. This command runs an interactive script for which you must provide configuration information. The following list shows the type of information you need to provide. See the ypserv(1M) man page for explanations of these attributes.

• The name of the configuration file being created (default = /etc/default/ypserv)

• The DN that stores configuration information in LDAP (default = ypserv)

• Preferred server list for mapping data to/from LDAP

• Authentication method for mapping data to/from LDAP

• Transport Layer Security (TLS) method for mapping data to/from LDAP

• Proxy user bind DN to read/write data from/to LDAP

• Proxy user password to read/write data from/to LDAP

• Timeout value (in seconds) for LDAP bind operation

• Timeout value (in seconds) for LDAP search operation

• Timeout value (in seconds) for LDAP modify operation

• Timeout value (in seconds) for LDAP add operation

• Timeout value (in seconds) for LDAP delete operation

• Time limit (in seconds) for search operation on LDAP server

• Size limit (in bytes) for search operation on LDAP server

• Whether N2L should follow LDAP referrals

• LDAP retrieval error action, number of retrieval attempts, and timeout (in seconds) between each attempt

• Store error action, number of attempts, and timeout (in seconds) between each attempt

• Mapping file name

• Whether to generate mapping information for auto.* maps

  The script places relevant information regarding custom maps at appropriate places in the mapping file.

• The naming context

• Whether to enable password changes

• Whether to change the default TTL values for any map

sasl/cram-md5 authentication is not supported by most LDAP servers, including Sun ONE Directory Server.

How to Set Up the N2L Service With Standard Mappings

Use this procedure if you are transitioning the maps listed in Supported Standard Mappings. If you are using custom or nonstandard maps, see How to Set Up the N2L Service With Custom or Nonstandard Mappings.

When the LDAP server has been set up, run the inityp2l script and supply configuration information when prompted. inityp2l sets up the configuration and mapping files for standard and auto.* maps.

1. Complete the prerequisite steps that are listed in Prerequisites for the NIS-to-LDAP Transition.

2. Become superuser, or equivalent, on the NIS master server.

3. Convert the NIS master server into a N2L server.

   # inityp2l

   Run the inityp2l script on the NIS master server and follow the prompts. See Setting Up the N2L Service for a list of the information you need to provide.

   See the inityp2l(1M) man page for more details.

4. Determine if the LDAP Directory Information Tree (DIT) is fully initialized.

   The DIT is fully initialized if it already contains the information necessary to populate all the maps that are listed in the NISLDAPmapping file.

   • If no, continue with Step 5 and skip Step 6.

   • If yes, skip Step 5 and go to Step 6.

5. Initialize the DIT for the transition from the NIS source files.

   Perform these steps only if the DIT has not been fully initialized.

   1. Make sure that the old NIS maps are up-to-date.

      # cd /var/yp # make

      For more information, see the ypmake(1M) man page.

   2. Stop the NIS daemons.

      # ypstop

   3. Copy the old maps to the DIT, then initialize N2L support for the maps.

      # ypserv -Ir

      Wait for ypserv to exit.

      ---

      Tip –

      The original NIS dbm files are not overwritten. You can recover these files, if needed.

      ---

   4. Restart the NIS daemons to ensure that they use the new maps.

      # ypstart

      This completes the set up of the N2L service with standard maps. You do not need to complete Step 6.

6. Initialize the NIS maps.

   Perform these steps only if the DIT is fully initialized and you skipped Step 5.

   1. Stop the NIS daemons.

      # ypstop

   2. Initialize the NIS maps from information in the DIT.

      # ypserv -r

      Wait for ypserv to exit.

      ---

      Tip –

      The original NIS dbm files are not overwritten. You can recover these files, if needed.

      ---

   3. Restart the NIS daemons to ensure that they use the new maps.

      # ypstart

How to Set Up the N2L Service With Custom or Nonstandard Mappings

Use this procedure if the following circumstances apply:

• You have maps that are not listed in Supported Standard Mappings.

• You have standard NIS maps that you want to map to non-RFC 2307 LDAP mappings.

1. Complete the prerequisite steps that are listed in Prerequisites for the NIS-to-LDAP Transition.

2. Become superuser, or equivalent, on the NIS master server.

3. Configure the NIS master server into the N2L server.

   # inityp2l

   Run the inityp2l script on the NIS master server and follow the prompts. See Setting Up the N2L Service for a list of the information you need to provide.

   See the inityp2l(1M) man page for more details.

4. Modify the /var/yp/NISLDAPmapping file.

   See Examples of Custom Maps for examples of how to modify the mapping file.

5. Determine if the LDAP Directory Information Tree (DIT) is fully initialized.

   The DIT is fully initialized if it already contains the information necessary to populate all the maps that are listed in the NISLDAPmapping file.

   • If no, complete Step 6, Step 8, and Step 9.

   • If yes, skip Step 6 and complete Step 7, Step 8, and Step 9.

6. Initialize the DIT for the transition from the NIS source files.

   1. Make sure that the old NIS maps are up-to-date.

      # cd /var/yp # make

      For more information, see the ypmake(1M) man page.

   2. Stop the NIS daemons.

      # ypstop

   3. Copy the old maps to the DIT, then initialize N2L support for the maps.

      # ypserv -Ir

      Wait for ypserv to exit.

      ---

      Tip –

      The original NIS dbm files are not overwritten. You can recover these files, if needed.

      ---

   4. Restart the NIS daemons to ensure that they use the new maps.

      # ypstart

   5. Skip Step 7 and continue with Step 8.

7. Initialize the NIS maps.

   Perform this step only if the DIT is fully initialized.

   1. Stop the NIS daemons.

      # ypstop

   2. Initialize the NIS maps from information in the DIT.

      # ypserv -r

      Wait for ypserv to exit.

      ---

      Tip –

      The original NIS dbm files are not overwritten. You can recover these files, if needed.

      ---

   3. Restart the NIS daemons to ensure that they use the new maps.

      # ypstart

8. Verify that the LDAP entries are correct.

   If the entries are not correct, then the entries can not be found by LDAP naming services clients.

   # ldapsearch -h server -s sub -b "ou=servdates, dc=..." \ "objectclass=servDates"

9. Verify the contents of the LDAP_ maps.

   The following sample output shows how to use makedm to verify the contents of the hosts.byaddr map.

   # makedbm -u LDAP_servdate.bynumber plato: 1/3/2001 johnson: 2/4/2003,1/3/2001 yeats: 4/4/2002 poe: 3/3/2002,3/4/2000

   If the contents are as expected, the transition from NIS to LDAP was successful.

   Note that the original NIS dbm files are not overwritten, so you can always recover those files. See Reverting to NIS for more information.

Examples of Custom Maps

The following two examples show how you might customize maps. Use your preferred text editor to modify the /var/yp/NISLDAPmapping file as needed. For more information about file attributes and syntax, see the NISLDAPmapping(4) man page and the LDAP naming services information in Chapter 13, Basic Components and Concepts (Overview).

Example 1–Moving Host Entries

This example shows how to move host entries from the default location to another (nonstandard) location in the DIT.

Change the nisLDAPobjectDN attribute in the NISLDAPmapping file to the new base LDAP distinguished name (DN). For this example, the internal structure of the LDAP objects is unchanged, so objectClass entries are unchanged.

Change:

nisLDAPobjectDN hosts: \
                        ou=hosts,?one?, \
                        objectClass=device, \
                        objectClass=ipHost

To:

nisLDAPobjectDN hosts: \
                        ou=newHosts,?one?, \
                        objectClass=device, \
                        objectClass=ipHost

This change causes entries to be mapped under

   dn: ou=newHosts, dom=domain1, dc=sun, dc=com

instead of under

   dn: ou=hosts, dom=domain1, dc=sun, dc=com.

Example 2–Implementing a Custom Map

This example shows how to implement a custom map.

A hypothetical map, servdate.bynumber, contains information about the servicing dates for systems. This map is indexed by the machine's serial number which, in this example, is 123. Each entry consists of the machine owner's name, a colon, and a comma-separated list of service dates, such as John Smith:1/3/2001,4/5/2003.

The old map structure is to be mapped onto LDAP entries of the following form:

dn: number=123,ou=servdates,dc=... \
                 number: 123 \
                 userName: John Smith \
                 date: 1/3/2001 \
                 date: 4/5/2003 \
                  .
                  .
                  .
                 objectClass: servDates

By examining the NISLDAPmapping file, you can see that the mapping closest to the required pattern is group. The custom mappings can be modeled on the group mapping. Since there is only one map, no nisLDAPdatabaseIdMapping attribute is required. The attributes to be added to NISLDAPmapping are the following:

nisLDAPentryTtl servdate.bynumber:1800:5400:3600

nisLDAPnameFields servdate.bynumber: \
                        ("%s:%s", uname, dates)

nisLDAPobjectDN servdate.bynumber: \
                        ou=servdates, ?one? \
                        objectClass=servDates:

nisLDAPattributeFromField servdate.bynumber: \
                        dn=("number=%s,", rf_key), \
                        number=rf_key, \
                        userName=uname, \
                        (date)=(dates, ",")

nisLDAPfieldFromAttribute servdate.bynumber: \
                        rf_key=number, \
                        uname=userName, \
                        dates=("%s,", (date), ",")  

N2L Best Practices With Sun ONE Directory Server

The N2L service supports Sun ONE Directory Server (formerly iPlanet Directory Server) and compatible versions of directory servers offered by Sun Microsystems, Inc. Other (third party) LDAP servers might work with the N2L service, but they are not supported by Sun. If you are using an LDAP server other than the Sun ONE Directory Server or compatible Sun servers, you must manually configure the server to support RFC 2307, or its successors', schemas.

If you are using the Sun ONE Directory Server, you can enhance the directory server to improve performance. To make these enhancements, you must have LDAP administrator privileges on the Sun ONE Directory Server. In addition, the directory server might need to be rebooted, a task that must be coordinated with the server's LDAP clients. The iPlanet Directory Server 5.1 documentation is available on the docs.sun.com web site.

Creating Virtual List View Indexes With Sun ONE Directory Server

For large maps, LDAP virtual list view (VLV) indexes must be used to ensure LDAP searches return complete results. For information about setting up VLV indexes on the Sun ONE Directory Server, see the Sun ONE Directory Server documentation on the docs.sun.com web site.

VLV search results use a fixed page size of 50000. If VLVs are used with Sun ONE Directory Server, both the LDAP server and N2L server must be able to handle transfers of this size. If all of your maps are known to be smaller than this limit, you do not need to use VLV indexes. However, if your maps are larger than the size limit, or you are unsure of the size of all maps, use VLV indexes to avoid incomplete returns.

If you are using VLV indexes, set up the appropriate size limits as follows.

• On the Sun ONE Directory Server: nsslapd-sizelimit attribute must be set greater than or equal to 50000 or -1. See the idsconfig(1M) man page.

• On the N2L server: nisLDAPsearchSizelimit attribute must be set greater than or equal to 50000 or zero. For more information, see the NISLDAPmapping(4) man page.

Once VLV indexes have been created, activate them by running directoryserver with the vlvindex option on the Sun ONE Directory Server. See the directoryserver(1M) man page for more information.

VLVs for Standard Maps

Use the Sun ONE Directory Server idsconfig command to set up VLVs if the following conditions apply:

• You are using the Sun ONE Directory Server.

• You are mapping standard maps to RFC 2307 LDAP entries.

VLVs are domain specific, so each time idsconfig is run, VLVs are created for one NIS domain. Therefore, during the NIS–to–LDAP transition, you must run idsconfig once for each nisLDAPdomainContext attribute included in the NISLDAPmapping file.

VLVs for Custom and Nonstandard Maps

You must manually create new Sun ONE Directory Server VLVs for maps, or copy and modify existing VLV indexes, if the following conditions apply:

• You are using the Sun ONE Directory Server.

• You have large custom maps or have standard maps that are mapped to nonstandard DIT locations.

To view existing VLV indexes, type the following:

# ldapsearch -h hostname -s sub -b "cn=ldbm database,cn=plugins,cn=config" \
"objectClass=vlvSearch"

Avoiding Server Timeouts With Sun ONE Directory Server

When the N2L server refreshes a map, the result might be a large LDAP directory access. If the Sun ONE Directory Server is not correctly configured, the refresh operation might time out before completion. To avoid directory server timeouts, modify the following Sun ONE Directory Server attributes manually or by running the idsconfig command.

For example, to increase the minimum amount of time in seconds that the server should spend performing the search request, modify these attributes:

dn: cn=config
nsslapd-timelimit: -1

For testing purposes, you can use an attribute value of -1, which indicates no limit. When you have determined the optimum limit value, change the attribute value. Do not maintain any attribute settings at -1 on a production server. With no limits, the server might be vulnerable to Denial of Service attacks.

For more information about configuring Sun ONE Directory Server with LDAP, see Part IV of this book.

Avoiding Buffer Overruns With Sun ONE Directory Server

To avoid buffer overruns, modify the Sun ONE Directory Server attributes manually or by running the idsconfig command.

1. For example, to increase the maximum number of entries that are returned for a client search query, modify these attributes:

   dn: cn=config nsslapd-sizelimit: -1

2. To increase the maximum number of entries that are verified for a client search query, modify these attributes:

   dn: cn=config, cn=ldbm database, cn=plugins, cn=config nsslapd-lookthroughlimit: -1

For testing purposes, you can use an attribute value of -1, which indicates no limit. When you have determined the optimum limit value, change the attribute value. Do not maintain any attribute settings at -1 on a production server. With no limits, the server might be vulnerable to Denial of Service attacks.

If VLVs are being used, the sizelimit attribute values should be set as defined in Creating Virtual List View Indexes With Sun ONE Directory Server. If VLVs are not being used, the size limit should be set large enough to accommodate the largest container.

For more information about configuring Sun ONE Directory Server see Part IV of this book.

N2L Restrictions

When the N2L server has been set up, the NIS source files are no longer used. Therefore, do not run ypmake on an N2L server. If ypmake is accidentally run, such as for an existing cron job, the N2L service is unaffected. However, a warning is logged suggesting that yppush should be called explicitly.

N2L Troubleshooting

This section covers two areas of troubleshooting:

• Common LDAP Error Messages

• N2L Issues

Common LDAP Error Messages

Sometimes the N2L server logs errors that relate to internal LDAP problems, resulting in LDAP-related error messages. Although the errors are nonfatal, they indicate problems to investigate. For example, the N2L server might continue to operate, but provide out-of-date or incomplete results.

The following list includes some of the common LDAP error messages that you might encounter when implementing the N2L service. Error descriptions, and possible causes and solutions for the errors, are included.

Administrative limit exceeded

Error Number: 11




Cause: An LDAP search was made that was larger than allowed by the directory server's nsslapd-sizelimit attribute. Only partial information will be returned.




Solution: Increase the value of the nsslapd-sizelimit attribute, or implement a VLV index for the failing search.

Invalid DN Syntax

Error Number: 34




Cause: An attempt has been made to write an LDAP entry with a DN that contains illegal characters. The N2L server attempts to escape illegal characters, such as the + symbol, that are generated in DNs.




Solution: Check the LDAP server error log to find out which illegal DNs were written, then modify the NISLDAPmapping file that generated the illegal DNs.

Object class violation

Error Number: 65




Cause: An attempt has been made to write an LDAP entry that is invalid. Generally, this error is due to missing MUST attributes that can be caused by either of the following circumstances.

• Bugs in the NISLDAPmapping file that create entries with missing attributes

• Attempts to add an AUXILIARY attribute to an object that does not exist

  For example, if a user name has not yet been created from the passwd.byxxx map, an attempt to add auxiliary information to that user will fail.




Solution: For bugs in the NISLDAPmapping file, check what was written in the LDAP server error log to determine the nature of the problem.

Can't contact LDAP server

Error Number: 81




Cause: The ypserv file might be incorrectly configured to point to the wrong LDAP directory server. Alternatively, the directory server might not be running.




Solution:

• Reconfigure the ypserv file to point to the correct LDAP directory server.

• To confirm that the LDAP server is running, become superuser on the directory server and type:

  # pgrep -l slapd

Timeout

Error Number: 85




Cause: An LDAP operation timed out, typically while updating a map from the DIT. The map might now contain out-of-date information.




Solution: Increase the nisLDAPxxxTimeout attributes in the ypserv configuration file.

N2L Issues

The following problems could occur while running the N2L server. Possible causes and solutions are provided.

Debugging the NISLDAPmapping File

The mapping file, NISLDAPmapping, is complex. Many potential errors might cause the mapping to behave in unexpected ways. Use the following techniques to resolve such problems.

Console Message Displays When ypserv -ir (or -Ir) Runs

Problem: A simple message is displayed on the console and the server exits (a detailed description is written to syslog).




Cause: The syntax of the mapping file might be incorrect.




Solution: Check and correct the syntax in the NISLDAPmapping file.

NIS Daemon Exits at Startup

Problem: When ypserv or other NIS daemons run, an LDAP-related error message is logged and the daemon exits.




Cause: The cause might be one of the following:

• The LDAP server cannot be contacted.

• An entry found in an NIS map or in the DIT is incompatible with the mapping specified.

• An attempt to read or write to the LDAP server returns an error.




Solution: Examine the error log on the LDAP server. See the LDAP errors that are listed in Common LDAP Error Messages.

Unexpected Results From NIS Operations

Problem: NIS operations do not return the expected results, but no errors are logged.




Cause: Incorrect entries might exist in the LDAP or NIS maps, which results in mappings not completing as intended.




Solution: Check and correct entries in the LDAP DIT and in the N2L versions of the NIS maps.

1. Check that the correct entries exist in the LDAP DIT, and correct the entries as needed.

   If you are using the Sun ONE Directory Server, start the management console by running directoryserver startconsole.

2. Check that the N2L versions of the NIS maps in the /var/yp directory contain the expected entries by comparing the newly generated map to the original map. Correct entries as needed.

   # cd /var/yp/domainname # makedbm -u test.byname # makedbm -u LDAP_test.byname

   Be aware of the following when checking the output for the maps:

   • The order of entries might not be the same in both files.

     Use the sort command before comparing output.

   • The use of white space might not be the same in both files.

     Use the diff -b command when comparing output.

Processing Order of NIS Maps

Problem: Object class violations occur.




Cause: When the ypserv -i command is run, each NIS map is read and its contents are written into the DIT. Several maps might contribute attributes to the same DIT object. Generally, one map creates most of the object, including all the object's MUST attributes. Other maps contribute additional MAY attributes.

Maps are processed in the same order that nisLDAPobjectDN attributes appear in the NISLDAPmapping file. If maps containing MAY attributes get processed before maps containing MUST attributes, then object class violations occur. See Error 65 in Common LDAP Error Messages for more information about this error.




Solution: Reorder the nisLDAPobjectDN attributes so that maps are processed in the correct order.

As a temporary fix, rerun the ypserv -i command several times. Each time the command is executed, more of the LDAP entry is built up.

Mapping in such a way that all of an object's MUST attributes cannot be created from at least one map is not supported.

N2L Server Timeout Issue

Problem: The server times out.




Cause: When the N2L server refreshes a map, the result might be a large LDAP directory access. If the Sun ONE Directory Server is not correctly configured, this operation might time out before completion.




Solution: To avoid directory server timeouts, modify the Sun ONE Directory Server attributes manually or by running the idsconfig command. See Common LDAP Error Messages and N2L Best Practices With Sun ONE Directory Server for details.

N2L Lock File Issue

Problem: The ypserv command starts but does not respond to NIS requests.




Cause: The N2L server lock files are not correctly synchronizing access to the NIS maps. This should never happen.




Solution: Type the following commands on the N2L server.

# ypstop # rm /var/run/yp_maplock /var/run/yp_mapupdate # ypstart

N2L Deadlock Issue

Problem: The N2L server deadlocks.




Cause: If the addresses of the N2L master server and the LDAP server are not listed properly in the hosts, ipnodes, or ypserv files, a deadlock might result. See Prerequisites for the NIS-to-LDAP Transition for details about proper address configuration for N2L.

For an example of a deadlock scenario, consider the following sequence of events:

1. An NIS client tries to look up an IP address.

2. The N2L server finds that the hosts entry is out-of-date.

3. The N2L server tries to update the hosts entry from LDAP.

4. The N2L server gets the name of its LDAP server from ypserv, then does a search by using libldap.

5. libldap tries to convert the LDAP server's name to an IP address by making a call to the name service switch.

6. The name service switch might make an NIS call to the N2L server, which deadlocks.




Solution: List the addresses of the N2L master server and the LDAP server in the hosts or ipnodes files on the N2L master server. Whether the server addresses must be listed in hosts, ipnodes, or both files depends on how these files are configured to resolve local host names. Also, check that the hosts and ipnodes entries in the nsswitch.conf file list files before nis in the lookup order.

An alternative solution to this deadlock problem is to list the LDAP server address, not its host name, in the ypserv file. This means that the LDAP server address would be listed in another place. Therefore, changing the address of either the LDAP server or the N2L server would require slightly more effort.

Reverting to NIS

It is anticipated that a site that has transitioned from NIS to LDAP using the N2L service will gradually replace all NIS clients with Solaris LDAP naming services clients. Support for NIS clients eventually becomes redundant. However, if required, the N2L service provides two ways to return to traditional NIS, as explained in the next two procedures.

Traditional NIS ignores the N2L versions of the NIS maps if those maps are present. After reverting to NIS, if you leave the N2L versions of the maps on the server, the N2L maps do not cause problems. Therefore, it might be useful to keep the N2L maps in case you later decide to re-enable N2L. However, the maps do take up disk space.

How to Revert to Maps Based on Old Source Files

1. Become superuser.

2. Stop the NIS daemons.

   # ypstop

3. Disable N2L.

   This command backs up and moves the N2L mapping file.

   # mv /var/yp/NISLDAPmapping backup_filename

4. Set the NOPUSH environment variable so the new maps are not pushed by ypmake.

   # NOPUSH=1

5. Make a new set of NIS maps that are based on the old sources.

   # cd /var/yp # make

6. (Optional) Remove N2L versions of the NIS maps.

   # rm /var/yp/domainname/LDAP_*

7. Restart the NIS daemons.

   # ypstart

How to Revert to Maps Based on Current DIT Contents

Back up the old NIS source files before performing this procedure.

1. Become superuser.

2. Stop the NIS daemons.

   # ypstop

3. Update the maps from the DIT.

   # ypserv -r

   Wait for ypserv to exit.

4. Disable N2L.

   This command backs up and moves the N2L mapping file.

   # mv /var/yp/NISLDAPmapping backup_filename

5. Regenerate the NIS source files.

   # ypmap2src

6. Manually check that regenerated NIS source files have the correct content and structure.

7. Move the regenerated NIS source files to the appropriate directories.

8. (Optional) Remove the N2L versions of the mapping files.

   # rm /var/yp/domainname/LDAP_*

9. Restart the NIS daemons.

   # ypstart

Chapter 20 Transitioning From NIS+ to LDAP

This chapter describes how to make the transition from using the NIS+ naming service to LDAP naming services.

NIS+ to LDAP Overview

The NIS+ server daemon, rpc.nisd, stores NIS+ data in proprietary-format files in the /var/nis/data directory. While it is entirely possible to keep NIS+ data synchronized with LDAP, such synchronization has previously required an external agent. However, the NIS+ daemon now enables you to use an LDAP server as a data repository for NIS+ data. Since this makes it possible for NIS+ and LDAP clients to share the same naming service information, it is easier to transition from using NIS+ as the main naming service, to using LDAP for the same role.

By default, the rpc.nisd daemon continues to work as before, relying only on the/var/nis/data NIS+ database. If desired, the system administrator can choose to use an LDAP server as the authoritative data repository for any subset of the NIS+ database. In this case, the /var/nis/data files serve as a cache for the rpc.nisd daemon, reducing LDAP lookup traffic, and enabling the rpc.nisd to continue working if the LDAP server is temporarily unavailable. In addition to continuous synchronization between NIS+ and LDAP, you can also perform uploads of NIS+ data to LDAP, or downloads of LDAP data to NIS+.

Mapping of data to and from LDAP is controlled by a flexible configuration file syntax. (All standard NIS+ tables (except for client_info.org_dir and timezone.org_dir) are covered by a template mapping file, /var/nis/NIS+LDAPmapping.template), which should require little or no change for most NIS+ installations. (See client_info and timezone Tables for information on client_info.org_dir and timezone.org_dir.) In addition to locations for NIS+ data in the LDAP Directory Information Tree (DIT), the mapping file also allows establishing time-to-live (TTL) for NIS+ data sourced from LDAP. While there often is a one-to-one mapping between NIS+ column values and LDAP attribute values, the mapping file can be used to maintain more complicated relationships as well.

The new /etc/default/rpc.nisd file is used to select LDAP server and authentication, and controls some general rpc.nisd behavior. See rpc.nisd(4). The details of the mapping is specified via the /var/nis/NIS+LDAPmapping file. For more information, see NIS+LDAPmapping(4). The name of this file can be changed using the -m command-line option of rpc.nisd. For more information, see rpc.nisd(1M).

The following terms are used in this chapter.

• Container

  A container is the location in the LDAP DIT where all related entries are stored. For example, user account information is often stored in the ou=People container, while host address information can be stored in the ou=Hosts container.

• Netname

  A netname is an entity in secure RPC (user or machine) that can be authenticated.

• Mapping

  Mapping is the relationship between an NIS+ object and an LDAP entry. For example, data from the name column in the passwd.org_dir NIS+ table (such as the user name of an account) corresponds to the LDAP uid attribute of the posixAccount object class in the ou=People container. The configuration can establish a mapping between the name column and the uid attribute. You can also say that the name column is mapped to the uid attribute (or vice versa).

• Principal

  A principal is an entity in NIS+ (user or machine) that can be authenticated. Usually, there is a one-to–one correspondence between netnames and principal names.

Configuration Files

Two configuration files control rpc.nisd operation.

• /etc/default/rpc.nisd

  This file contains information regarding the LDAP server and authentication, the NIS+ base domain, the LDAP default search base, exception processing, and general rpc.nisd configuration, which applies whether or not LDAP mapping is in effect.

• /var/nis/NIS+LDAPmapping

  This file contains information on mapping of NIS+ data to and from LDAP. The template file (/var/nis/NIS+LDAPmapping.template) covers all standard NIS+ objects, except client_info.org_dir and timezone.org_dir. See client_info and timezone Tables and NIS+LDAPmapping(4).

Configuration is done by assigning values to pre-defined attributes. In addition to the configuration files, the configuration attributes can also be read from LDAP (see Storing Configuration Information in LDAP) or can be specified on the rpc.nisd command line by way of the -x option. If the same attribute is specified in more than one place, the priority order is (from higher to lower) as follows.

1. rpc.nisd -x option

2. Configuration file

3. LDAP

Creating Attributes and Object Classes

Depending on how you configure the NIS+/LDAP mapping, you might need to create a number of new LDAP attributes and object classes. The examples show how to do this by specifying LDIF data that can be used as input to the ldapadd command. Create a file containing the LDIF data, and then invoke ldapadd(1).

# ldapadd -D bind-DN -f ldif -file

This method works with Sun ONE Directory Server, and might work with other LDAP servers as well.

Except for the defaultSearchBase, preferredServerList, and authenticationMethod attributes, as well as the SYNTAX specifications, the object identifiers (OIDs) used in this chapter are intended for illustration only. As no official OIDs have been assigned, you are free to use any suitable OIDs.

Getting Started

For an introduction to the configuration needed to start using an LDAP repository for NIS+ data, see NIS+LDAPmapping(4). The remainder of this section goes into more detail about the organization of the configuration files.

/etc/default/rpc.nisd File

All assignments in the /etc/default/rpc.nisd file are of the attributeName=value type.

General Configuration

The following attributes control general configuration of the rpc.nisd, and are active whether or not LDAP mapping is in effect. They should generally be left at their default values. See rpc.nisd(4) for more information.

• nisplusNumberOfServiceThreads

• nisplusThreadCreationErrorAction

• nisplusThreadCreationErrorAttempts

• nisplusThreadCreationErrorTimeout

• nisplusDumpErrorAction

• nisplusDumpErrorAttempts

• nisplusDumpErrorTimeout

• nisplusResyncService

• nisplusUpdateBatching

• nisplusUpdateBatchingTimeout

Configuration Data From LDAP

The following attributes control the reading of other configuration attributes from LDAP. These attributes cannot themselves reside in LDAP. They are read only from the command line or the configuration file. See rpc.nisd(4) for more information.

• nisplusLDAPconfigDN

• nisplusLDAPconfigPreferredServerList

• nisplusLDAPconfigAuthenticationMethod

• nisplusLDAPconfigTLS

• nisplusLDAPconfigTLSCertificateDBPath

• nisplusLDAPconfigProxyUser

• nisplusLDAPconfigProxyPassword

Server Selection

• preferredServerList

  Specify the LDAP server and port number.

  # LDAP server can be found at port 389 # LDAP server can be found at port 389 on the local machine # preferredServerList=127.0.0.1 # Could also be written # preferredServerList=127.0.0.0.1:389 LDAP server on the machine at IP # address "1.2.3.4", at port 65042 # preferredServerList=1.2.3.4:65042

Authentication and Security

• authenticationMethod

• nisplusLDAPproxyUser

• nisplusLDAPproxyPassword

The authentication method and, if appropriate for the method selected, the proxy user (bind distinguished name [DN]) and password (key or other shared secret) to be used between the rpc.nisd daemon and the LDAP server. See Security and Authentication for more information.

• nisplusLDAPTLS

• nisplusLDAPTLSCertificateDBPath

Default Location in LDAP and NIS+

• defaultSearchBase

  The point in the LDAP DIT where the containers for RFC 2307- style naming services data live. This is the default used when individual container DNs do not specify a full search base. See nisplusLDAPobjectDN Attribute for more information.

• nisplusLDAPbaseDomain

  The default NIS+ domain name to use when NIS+ object specifications (see nisplusLDAPdatabaseIdMapping Attribute) are not fully qualified.

Timeout/Size Limits and Referral Action for LDAP Communication

• nisplusLDAPbindTimeout

• nisplusLDAPmodifyTimeout

• nisplusLDAPaddTimeout

• nisplusLDAPdeleteTimeout

The above parameters are timeouts for the ldap bind, modify, add, and delete operations, respectively. They should generally be left at their default values.

• nisplusLDAPsearchTimeout

• nisplusLDAPsearchTimeLimit

The above parameters set the timeout for the LDAP search operation, and request a server-side search time limit, respectively. Since the nisplusLDAPsearchTimeLimit will control how much time the LDAP server spends on the search request, make sure that nisplusLDAPsearchTimeLimit is not smaller than nisplusLDAPsearchTimeout. Depending on the performance of the NIS+ server, the LDAP server, and the connection between them, you might have to increase the search limits from the default values. Watch for timeout syslog messages from rpc.nisd as a clue to making these values larger.

• nisplusLDAPsearchSizeLimit

  The above parameter requests a limit on the amount of LDAP data returned for an LDAP search request. The default is to ask for no limitation. This is a server side limit. The LDAP server might impose restrictions on the maximum, and these restrictions might be tied to the proxy user (bind DN) used. Make sure that the LDAP server allows the rpc.nisd to transfer enough data to account for the largest container (depending on the site, often the container used for passwd.org_dir, mail_aliases.org_dir, or netgroup.org_dir). Consult your LDAP server documentation for more information.

• nisplusLDAPfollowReferral

  The above parameter defines the action to be taken when an LDAP operation results in a referral to another LDAP server. The default is to not follow referrals. Enable follow referrals if you want or need referrals to be honored. Keep in mind that while referrals are convenient, they can also slow down operations by making the rpc.nisd talk to multiple LDAP servers for each request. The rpc.nisd should generally be pointed directly to an LDAP server that can handle all LDAP requests that the rpc.nisd might make.

Error Actions

The following parameters define the actions to take when an error occurs during an LDAP operation. You should generally leave these at their defaults. See rpc.nisd(4) for more information.

• nisplusLDAPinitialUpdateAction

• nisplusLDAPinitialUpdateOnly

• nisplusLDAPretrieveErrorAction

• nisplusLDAPretrieveErrorAttempts

• nisplusLDAPretrieveErrorTimeout

• nisplusLDAPstoreErrorAction

• nisplusLDAPstoreErrorAttempts

• nisplusLDAPstoreErrorTimeout

• nisplusLDAPrefreshErrorAction

• nisplusLDAPrefreshErrorAttempts

• nisplusLDAPrefreshErrorTimeout

General LDAP Operation Control

• nisplusLDAPmatchFetchAction

  The above parameter determines whether or not LDAP data should be pre-fetched for NIS+ match operations. In most cases, leave this value at the default. See rpc.nisd(4) for more information.

/var/nis/NIS+LDAPmapping File

The name of the above configuration can be changed via the -m option of rpc.nisd(1M). The presence of the NIS+LDAPmapping file serves as a master switch for NIS+/LDAP mapping.

If you use a name other than the default for the mapping file, you will have to edit the /etc/init.d/rpc boot script to specify the mapping file name on the rpc.nisd startup line.

For each NIS+ object that should be mapped to and/or from LDAP, the NIS+LDAPmapping file specifies two to five attributes, depending on the object and whether or not the default values are sufficient.

nisplusLDAPdatabaseIdMapping Attribute

You must establish an alias to be used in the other mapping attributes. If the NIS+ object name is not fully qualified (does not end in a dot), the value of the nisplusLDAPbaseDomain is appended.

For example,

nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

defines the database id rpc as an alias for the NIS+ rpc.org_dir table.

Note that NIS+ table objects might appear twice with two different database ids, once for the table object itself (if the object should be mapped to LDAP), and once for the table entries. For example,

nisplusLDAPdatabaseIdMapping	rpc_table:rpc.org_dir
nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

defines the database ids rpc_table and rpc as aliases for the rpc.org_dir table. Later definitions will make it clear that rpc_table is used for the rpc.org_dir table object, and rpc for the entries in that table.

nisplusLDAPentryTtl Attribute

Since the rpc.nisd daemon's local database (in memory and on disk) functions as a cache for LDAP data, the nisplusLDAPentryTtl attribute allows you to set the time-to-live (TTL) values of entries in that cache. There are three TTLs for each database ID. The first two control the initial TTL when the rpc.nisd first loads the corresponding NIS+ object data from disk, and the third TTL is assigned to an object when it is read or refreshed from LDAP.

For example the following results in the rpc.org_dir table object getting an initial TTL randomly selected in the range 21600 to 43200 seconds.

nisplusLDAPentryTtl	rpc_table:21600:43200:43200

When that initial TTL expires and the table object is refreshed from LDAP, the TTL will be set to 43200 seconds.

Similarly the following will assign an initial TTL between 1800 and 3600 seconds to the entries in the rpc.org_dir table when it is first loaded.

nisplusLDAPentryTtl	rpc:1800:3600:3600

Each entry gets its own randomly selected TTL in the range specified. When a table entry expires and is refreshed, the TTL is set to 3600 seconds.

When selecting TTL values, consider the trade-off between performance and consistency. If the TTLs used for LDAP data cached by the rpc.nisd are very long, performance is the same as if rpc.nisd was not mapping data from LDAP at all. However, if the LDAP data is changed (by some entity other than rpc.nisd), it can also take a very long time before that change is visible in NIS+.

Conversely, selecting a very short (or even zero) TTL means that changes to LDAP data are quickly visible in NIS+, but can also impose a significant performance penalty. Typically, an NIS+ operation that also reads data from or writes data to LDAP will take at least two to three times longer (plus the LDAP lookup overhead) than the same operation without LDAP communication. Although performance can vary greatly depending on the hardware resources, scanning a large (tens of thousands or hundreds of thousands of entries) LDAP container to identify NIS+ entries that should be refreshed can take a long time. The rpc.nisddaemon performs this scan in the background, continuing to serve possibly stale data while it is running, but the background scan still consumes CPU and memory on the NIS+ server.

Carefully consider how critical it is to have NIS+ data in close synchronization with LDAP, and select the longest TTL that is acceptable for each NIS+ object. The default (when no nisplusLDAPentryTtl is specified) is 1 hour. The template mapping file /var/nis/NIS+LDAPmapping.template changes this to 12 hours for objects other than table entries. However, there is no auto-recognition of non-entry objects, so if you add mapping for a non-entry object, the TTL will default to 1 hour.

There are no TTLs for nonexistent objects. Hence, no matter which TTLs are in effect for LDAP-mapped entries in an NIS+ table, a request for an entry that does not exist in NIS+ will query LDAP for that entry.

nisplusLDAPobjectDN Attribute

For each mapped NIS+ object, nisplusLDAPobjectDN establishes the location in the LDAP DIT where the object data resides. It also allows specification of the action to take when an LDAP entry is deleted. Each nisplusLDAPobjectDN value has three parts. The first specifies where LDAP data is read from, the second to where it is written, and the third what should happen when LDAP data is deleted. Refer to the following example.

nisplusLDAPobjectDN	rpc_table:\
										cn=rpc,ou=nisPlus,?base?\
													objectClass=nisplusObjectContainer:\
										cn=rpc,ou=nisPlus,?base?\
													objectClass=nisplusObjectContainer,\
														objectClass=top

The above example shows that the rpc.org_dir table object should be read from the DN cn=rpc,ou=nisPlus, (since the value ends in a comma, the value of the defaultSearchBase attribute is appended), with scope base, and that entries with a value of nisplusObjectContainer for the ObjectClass attribute are selected.

The table object is written to the same place. The delete specification is missing, which implies the default action, which is as follows. If the NIS+ table object is deleted, the entire LDAP entry should also be deleted.

If data should be read from, but not written to LDAP, omit the write portion (and the colon separating it from the read part).

nisplusLDAPobjectDN	rpc_table:\
										cn=rpc,ou=nisPlus,?base?\
										objectClass=nisplusObjectContainer

Note that the nisplusObjectContainer object class is not part of RFC 2307. In order to use it, you must configure your LDAP server as detailed in Mapping NIS+ Objects Other Than Table Entries.

For the rpc.org_dir table entries, you could use the following example.

nisplusLDAPobjectDN rpc:ou=Rpc,?one?objectClass=oncRpc:\
											ou=Rpc,?one?objectClass=onRpc,objectClass=top

The above shows that the table entries are read from and written to the base ou=Rpc. Again, the trailing comma appends the defaultSearchBase value. Select entries that have an objectClass attribute value of oncRpc. When creating an entry in the ou=Rpc container in LDAP, you also must specify top as an objectClass value.

As an example showing a non-default delete specification, consider the following.

nisplusLDAPobjectDN	user_attr:\
										ou=People,?one?objectClass=SolarisUserAttr,\
											solarisAttrKeyValue=*:\
										ou=People,?one?objectClass=SolarisUserAttr:\
											dbid=user_attr_del

The user_attr.org_dir data resides in the ou=People LDAP container, which it shares with account information from other sources, such as the passwd.org_dir NIS+ table.

Select entries in that container that have the solarisAttrKeyValue attribute, since only those contain user_attr.org_dir data. The dbid=user_attr_del portion of the nisplusLDAPobjectDN shows that when an entry in the user_attr.org_dir NIS+ table entry is deleted, deletion of the corresponding LDAP entry (if any) should follow the rules in the rule set identified by the user_attr_del database ID. See nisplusLDAPcolumnFromAttribute Attribute for more information.

nisplusLDAPattributeFromColumn Attribute

nisplusLDAPattributeFromColumn specifies the rules used to map NIS+ data to LDAP. Mapping rules for the other direction is controlled by nisplusLDAPcolumnFromAttribute.

nisplusLDAPcolumnFromAttribute Attribute

nisplusLDAPcolumnFromAttribute specifies the rules used to map LDAP data to NIS+.

The full entry mapping syntax can be found on NIS+LDAPmapping(4). However, a few examples should make things clearer.

The NIS+ rpc.org_dir table contains four columns called cname, name, numbe, and comment. Therefore, the entries for the NIS+ RPC program number (100300) with the canonical name nisd and the aliases rpc.nisd and nisplusd could be represented by the following NIS+ entries in rpc.org_dir.

nisd nisd 100300	NIS+ server
nisd rpc.nisd 100300	NIS+ server
nisd nisplusd 100300	NIS+ server

Assuming the defaultSearchBase value is dc=some,dc=domain, the corresponding LDAP entry, as listed by ldapsearch(1), would be the following.

cn=nisd,ou=Ppc,dc=some,dc=domain
cn=nisd
cn=rpc.nsid
cn=nisplusd
oncrocnumber=100300
description=NIS+ server
objectclass=oncRpc
objectclass=top

This makes for a simple one-to-one mapping between NIS+ and LDAP data, and the corresponding mapping attribute value going from NIS+ to LDAP is the following.

nisplusLDAPattributeFromColumn \
rpc:		dn=("cn=%s,", name), \
				cn=cname, \
				cn=name, \
				oncRpcNumber=number, \
				description=comment

This constructs the DN for the entry to be cn=%s, with the value of the cname column substituted for %s.

cn=nisd,

Since the value ends in a comma, the read base value from the nisplusObjectDN is appended, and you have the following.

cn=nisd,ou=Rpc,dc=some,dc=domain

The oncRpcNumber and description attribute values are just simple assignments of the corresponding NIS+ column values. The rpc.nisd will collect the multiple NIS+ entries into one LDAP entry, with multiple cn values to represent the different name column values.

Similarly, the mapping from LDAP to NIS+ would be as follows.

nisplusLDAPcolumnFromAttribute \
 					rpc:		cname=cn, \
			 						(name)=(cn), \
									number=oncRpcNumber, \
									comment=description

The above assigns the oncRpcNumber and description values to the corresponding NIS+ columns. The multi-valued cn (denoted by (cn) is mapped to multiple name column values (denoted by (name)). Since the name column cannot be multi-valued, the rpc.nisd creates one NIS+ entry for each cn value.

Finally, the nisplusLDAPattributeFromColumn value is an example of rule sets used for deletion.

nisplusLDAPattributeFromColumn \
user_attr_del:	dn=("uid=%s,", name), \
						SolarisUserQualifier=, \
						SolarisAttrReserved1=, \
 						SolarisAttrReserved2=, \
						SolarisAttrKeyValue= 

Again, the user_attr.org_dir data shares the ou=People container with other account information (from the passwd.org_dir and other tables). If an entry in the user_attr.org_dir table is deleted, you probably do not want to delete the entire ou=People entry. Instead, the delete entry above says that when a user_attr.org_dir entry is deleted, the SolarisUserQualifier, SolarisAttrReserved1, SolarisAttrReserved2, and SolarisAttrKeyValue attributes (if any) are deleted from the ou=People entry specified by the following rule.

dn=("uid=%s,", name)

The rest of the LDAP entry is left unchanged.

NIS+ to LDAP Migration Scenarios

Likely scenarios for a migration from NIS+ to LDAP include the following.

• Convert all NIS+ clients to LDAP in one operation. You can use the rpc.nisd daemon to upload any NIS+ data that does not yet exist in LDAP. See How to Convert All NIS+ Data to LDAP in One Operation.

• Do a gradual migration from NIS+ to LDAP. Start by converting NIS+ data to LDAP (see How to Convert All NIS+ Data to LDAP in One Operation). You could have both NIS+ and LDAP clients sharing the same naming service data, and let the rpc.nisd automatically keep NIS+ and LDAP data synchronized. Initially, perhaps, NIS+ would be authoritative, and the LDAP server(s) would maintain a duplicate of the NIS+ data for the benefit of LDAP clients. At a convenient time, LDAP can become the authoritative naming service, and NIS+ service gradually phased out, until there are no more NIS+ clients.

• LDAP is already used as a naming service, so you need to merge the NIS+ and LDAP data. There are three possible ways to perform this merge.

  • Add the NIS+ data to LDAP. Entries that exist in NIS+, but not in LDAP, are added to LDAP. Entries that appear both in NIS+ and LDAP, but with different data, end up with the NIS+ data. See How to Convert All NIS+ Data to LDAP in One Operation.

  • Overwrite the NIS+ data with the LDAP data. If there are entries that exist in NIS+ but not in LDAP, they will disappear from NIS+. Entries that exist both in NIS+ and LDAP end up with the LDAP data. See How to Convert All LDAP Data to NIS+ in One Operation.

  • Merge NIS+ and LDAP data, resolving conflicts on an individual basis. See Merging NIS+ and LDAP Data.

How to Convert All NIS+ Data to LDAP in One Operation

1. Use the rpc.nisd to upload any NIS+ data that does not yet exist in LDAP.

   Assuming all NIS+/LDAP data mappings have been established in the default location (/var/nis/NIS+LDAPmapping), use the following command.

   # /usr/sbin/rpc.nisd -D \

   —x nisplusLDAPinitialUpdateAction=to_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

   The above would make the rpc.nisd upload data to LDAP, and then exit. The NIS+ data would be unaffected by this operation.

   See the nisplusLDAPinitialUpdateAction attribute on rpc.nisd(4).

How to Convert All LDAP Data to NIS+ in One Operation

1. Use the rpc.nisd to download all LDAP data to NIS+, overwriting existing NIS+ data.

   Assuming all NIS+/LDAP data mappings have been established in the default location (/var/nis/NIS+LDAPmapping), use the following command.

   # /usr/sbin/rpc.nisd -D \

   -x nisplusLDAPinitialUpdateAction=from_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

   The above would make the rpc.nisd daemon download data from LDAP, and then exit. The LDAP data would be unaffected by this operation.

   See the nisplusLDAPinitialUpdateAction attribute on rpc.nisd(4).

Merging NIS+ and LDAP Data

NIS+ to LDAP Migration Scenarios showed how to synchronize NIS+ and LDAP data when data conflicts between the two should be resolved by letting either the NIS+ or the LDAP data be authoritative. Merging data requires a more complicated procedure.

The example procedure in this section assumes the following.

• You are putting a backup of the NIS+ data in the /nisbackup directory.

• Valid mapping configuration already exists in /etc/default/rpc.nisd and /var/nis/tmpmap (for tables that should be merged).

• Flat file representations of the NIS+ data before the merge are stored in /before, and after-merge representations in /after.

• niscat is used to dump flat file representations of custom NIS+ tables not supported by nisaddent(1M). You might have your own commands or scripts for dumping and loading such custom tables from and to NIS+. If so, those commands/scripts should be used in preference to niscat since the latter has no convenient counterpart to load data back into NIS+.

  If you are forced to dump data using niscat(1), you can use nistbladm(1) to load entries back into NIS+ one by one.

• Your command path includes /usr/lib/nis (which is where nisaddent(1M) resides).

How to merge NIS+ and LDAP data

If the LDAP data should change between the download in Step 4 and the upload in Step 10, the upload might overwrite those changes. For this reason, you should try to prevent modifications to the LDAP data during this procedure. Consult your LDAP server documentation for more information.

1. Back up all NIS+ data using the nisbackup command.

   # nisbackup -a /nisbackup

2. Identify the NIS+ tables that have data which must be merged with LDAP. Dump the contents of these tables to flat files. For example, dump the contents of group.org_dirusing nisaddent as follows.

   # nisaddent -d group | sort > /before/group

   Piping the nisaddent output to sort will make for convenient comparison later on.

3. Stop the rpc.nisd daemon.

   # pkill rpc.nisd

4. Download LDAP data to NIS+.

   # /usr/sbin/rpc.nisd -D -m tmpmap \

   -x nisplusLDAPinitialUpdateAction=from_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

5. Start the rpc.nisd daemon.

   # /usr/sbin/rpc.nisd

   The rpc.nisd daemon will now be serving the data downloaded from LDAP. If the conflicts to be resolved are such that NIS+ clients should not be exposed to them, make sure to perform this and the following steps when there are few (preferably no) active NIS+ clients.

6. Dump the NIS+ data for the affected tables.

   The following example uses the group.org_dir table.

   # nisaddent -d group | sort > /after/group

7. Use your favorite file merge procedure to produce merged versions of the tables. If no other tools are available, you can use diff(1) to collect differences between the /before and /after files, and merge manually with a text editor.

   The following example assumes that the merged results are available in /after.

8. Load the merged data into NIS+. The following example uses the group table.

   # nisaddent -m -f /after/group group

9. Remove LDAP entries that should not exist after the merge.

   A. If there are LDAP entries that do not exist in the (now merged) NIS+ data, and that should not exist in LDAP after the upload, you must remove those LDAP entries.

   Your LDAP server might provide a convenient method for removing multiple entries, such as a way to delete all entries in a container. If this is not the case, you can use ldapsearch(1) to generate a list of entries for each container. For example, to generate a list of all entries in the ou=Rpc container, use ldapsearch(1) as follows.

   # ldapsearch -h server-address -D bind-DN -w password \

   -b ou=Rpc,search-base 'objectClass=*' dn | \

   grep -i ou=Rpc | grep -v -i \^ou=Rpc > \

   /tmp/delete-dn

   See Performance and Indexing for an explanation of the meta-arguments (server-address, bind-DN, for example).

   B. You can now edit the result file (/tmp/delete-dn) to specify only those entries that should be removed. Alternatively, in order to remove all entries in the container, use the file as is, and rely on the NIS+ upload to restore the LDAP data. Either way, you should backup the LDAP data before performing the ldapdelete operation below.

   C. Use ldapdelete to remove LDAP entries, redirecting stdout (which usually is one blank line for each entry removed) to /dev/null.

   # ldapdelete —h server-address —D bind-DN —w password \

   /tmp/delete-dn /dev/null

   D. Repeat the above procedure for each container that has at least one entry which must be removed.

10. NIS+ now contains the merged data, which can be uploaded to LDAP. Do the following.

    Stop the rpc.nisd daemon.

    # pkill rpc.nisd

    Perform the upload.

    # /usr/sbin/rpc.nisd -D -m tmpmap \

    -x nisplusLDAPinitialUpdateAction=to_ldap \

    -x nisplusLDAPinitialUpdateOnly=yes

11. Restart the rpc.nisd daemon.

    • If the rpc.nisd daemon uses the LDAP repository, specify an appropriate mapping file.

    • If the rpc.nisd daemon provides NIS (YP) emulation, specify the -Y option.

    # /usr/sbin/rpc.nisd -m mappingfile [ -Y ]

    Alternatively, omit -x nisplusLDAPinitialUpdateOnly=yes from the upload command in Step 10. This will make the rpc.nisd daemon start serving NIS+ data when the upload is done.

Masters and Replicas

Only NIS+ masters are allowed to write data to LDAP. NIS+ replicas can obtain updates either from the NIS+ master (which might or might not have obtained it from LDAP), or they can read data directly from an LDAP server. A combination of the two is also possible. Therefore, there are two principal ways to arrange for NIS+ replication.

• Leave NIS+ replicas unchanged, and let them obtain their data updates from the NIS+ master.

  This arrangement has the advantage of configurational simplicity (only the NIS+ master need have a connection to an LDAP server), and also maintains the old replication relationship (master knows about new data first, replicas later). It is probably the most convenient solution while NIS+ remains authoritative for naming service data. However, it also lengthens the path between LDAP and NIS+ replica servers.

• Let NIS+ replicas obtain their data directly from LDAP instead of from the NIS+ master.

  In this case, replicas could have updated data before or after the NIS+ master, depending on lookup traffic and TTLs for data derived from LDAP. This arrangement is more complicated, but can be convenient when LDAP is the authoritative naming services repository, and few or no updates are made directly to NIS+ data.

Replication Timestamps

When an NIS+ replica is obtaining data for at least one object in a particular NIS+ directory from LDAP, the update timestamps printed by nisping(1M) do not necessarily indicate the degree of data consistency between the NIS+ master and the replica. For example, assume that the NIS+ directory dir1 contains the tables table1 and table2. When the replica is obtaining data for both table1 and table2 from the NIS+ master, you might see an output like the following.

# nisping dir1

Master server is "master.some.domain."
Last update occurred at Mon Aug  5 22:11:09 2002

Replica server is "replica.some.domain."
	Last Update seen was Mon Aug  5 22:11:09 2002

The above indicates that the master and replica have exactly the same data. However, if the replica is getting data for either or both of table1 and table2 from LDAP, the output only shows that the replica has received an NIS_PING from the master, and updated its resynchronization time stamp for housekeeping purposes. The data in the table or tables mapped from LDAP might differ from that on the NIS+ master if either of the following are true.

• The LDAP data differs from that on the NIS+ master.

• The replica has data in its cache (its local version of the NIS+ database) that has not expired, but that is not up to date with LDAP.

If you cannot accept this type of data inconsistency, let all NIS+ replicas obtain their data from the NIS+ master only. Once you have configured the NIS+ master to get data from LDAP, you do not need to make modifications to the replicas.

The Directory Server

The LDAP mapping portion of the rpc.nisd daemon uses LDAP protocol version 3 to talk to the LDAP server. The default mapping configuration (/var/nis/NIS+LDAPmapping.template) expects that the LDAP server supports an extended version of RFC 2307. RFCs can be retrieved from http://www.ietf.org/rfc.html. While the mapping between NIS+ and LDAP data can be modified using NIS+LDAPmapping(4), there is a basic assumption that the LDAP data is organized along the principles laid out in RFC 2307.

For example, in order to share account information between direct LDAP clients and NIS+ clients, the LDAP server must support storing account (user) passwords in the UNIX crypt format. If the LDAP server cannot be configured to do so, you can still store NIS+ data, including accounts, in LDAP. However, you will not be able to fully share account information between NIS+ users and LDAP bindDNs.

Configuring the Sun ONE Directory Server

Refer to the Sun ONE Directory Server Collection for detailed instructions on the installation, setup and administration of Sun ONE Directory Server.

You can use idsconfig(1M) to configure Sun ONE Directory Server for LDAP clients using LDAP as a naming service. The setup provided by idsconfig(1M) is also appropriate when using NIS+ with an LDAP data repository.

If you are using an LDAP server other than Sun ONE Directory Server, you must manually configure the server to support the RFC 2307 schemas.

Assigning Server Address and Port Number

The /etc/default/rpc.nisd file is set up to use a local LDAP server at port 389. If this is not correct in your configuration, establish a new value for the preferredServerList attribute. For example, to use an LDAP server at IP address 192.0.0.1 and port 65535, you specify the following.

preferredServerList=192.0.0.1:65535

Security and Authentication

Authentication between NIS+ clients and the NIS+ server is not affected when the NIS+ server is obtaining data from LDAP. However, in order to maintain the integrity of the NIS+ data when it is stored in LDAP, consider configuring authentication between the rpc.nisd daemon and the LDAP server. Several different types of authentication are available, depending on the capabilities of the LDAP server.

The LDAP authentication supported by the rpc.nisd daemon includes the following.

• none

  The none authentication method is the default. While using none requires no setup, it also provides no security. It is only suitable for use in environments that have no security requirements at all.

  To use the none authentication, make sure that the authenticationMethod attribute has the following value.

  authenticationMethod=none

The authentication methods that actually provide at least some security typically require that you associate a shared secret (a password or key) with a DN in LDAP. The DN you select for use by the rpc.nisd daemon can be unique, or can also be used for other purposes. It should have appropriate capabilities to support the expected LDAP traffic. For example, if the rpc.nisd daemon should be able to write data to LDAP, the selected DN must have the right to add/update/delete LDAP data in the containers used for the NIS+ data. Also, the LDAP server might, by default, impose limitations on resource usage (such as search time limits or search result size limitations). If this is the case, the selected DN must have sufficient capabilities to support enumeration of the NIS+ data containers.

• simple

  The simple authentication method provides authentication by unencrypted exchange of a password string. Since the password is sent in the clear between the LDAP client (the rpc.nisd daemon) and LDAP server, the simple method is suitable only when information exchange between the NIS+ and LDAP servers is protected by some other method.

  For instance, transport layer encryption of LDAP traffic, or the special case where the NIS+ and LDAP server is one and the same system, and the NIS+/LDAP traffic stays in the kernel, protected from the eyes of unauthorized users.

  Modify the configuration of the rpc.nisd daemon with the DN and password to use for the simple authentication. For example, if the DN is cn=nisplusAdmin,ou=People,dc=some,dc=domain, and the password aword, establish the following.

  authenticationMethod=simple nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  Be sure to protect the place where the password is stored from unauthorized access. Remember that if the password is specified on the rpc.nisd command line, it might be visible to any user on the system via commands such as ps(1).

• sasl/digest-md5

  The sasl/digest-md5 authentication method provides authentication using the digest/md5 algorithm.

  Consult your LDAP server documentation for information on how to set up an authorization identity for use with digest-md5, and modify the /etc/default/rpc.nisd file to specify this identity and its associated password.

  authenticationMethod=sasl/digest-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  Be sure to protect the file where the password is stored from unauthorized access.

• sasl/cram-md5

  Authentication using the cram/md5 algorithm. Probably only supported by the obsolete SunDS LDAP server.

  Consult your LDAP server documentation for information on how to set up a bind DN for use with cram-md5, and modify the /etc/default/rpc.nisd file to specify this DN and its associated password.

  authenticationMethod=sasl/cram-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword

  Be sure to protect the file where the password is stored from unauthorized access.

Using SSL

The rpc.nisd daemon also supports transport layer encryption of LDAP traffic using SSL. Consult your LDAP server documentation to generate an SSL certificate for LDAP server authentication. Store the certificate in a file on the NIS+ server (/var/nis/cert7.db, for example) and modify /etc/default/rpc.nisd as follows.

nisplusLDAPTLS=ssl
nisplusLDAPTLSCertificateDBPath=/var/nis/cert7.db

Be sure to protect the certificate file from unauthorized access. Note that the above provides session encryption and authentication of the LDAP server to the rpc.nisd. It does not provide authentication of the rpc.nisd to the LDAP server, since the certificate does not contain anything that identifies the LDAP client (rpc.nisd). However, you can combine SSL with another authentication method (simple, sasl/digest-md5) in order to achieve mutual authentication.

Performance and Indexing

When the rpc.nisd daemon is asked to enumerate an NIS+ table (using niscat(1) for example) that is mapped from LDAP, it will enumerate the corresponding LDAP container if at least one entry in the table has an expired TTL. Although this container enumeration is done in the background, so that LDAP performance is of limited importance, it can nevertheless be beneficial to establish LDAP indices to speed up container enumeration for large containers.

To obtain an estimate of the amount of time required for enumeration of a particular container, you can use a command like the following.

% /bin/time ldapsearch -h server-address -D bind-DN -w password \

-b container, search-base 'cn=*' /dev/null

where

• server-address

  IP address portion of preferredServerList value from /etc/default/rpc.nisd

• bind-DN

  nisplusLDAPproxyUser value from /etc/default/rpc.nisd

• password

  nisplusLDAPproxyPassword value from /etc/default/rpc.nisd

• container

  One of the RFC 2307 container names (ou=Services, ou=Rpc, and so on)

• search-base

  defaultSearchBase value from /etc/default/rpc.nisd

The “real” value printed by /bin/time is the elapsed (wall-clock) time. If this value exceeds a significant fraction (25 percent or more) of the TTL for the corresponding table entries (see Authentication and Security), it might be beneficial to index the LDAP container.

The rpc.nisd supports the simple page and VLV indexing methods. Refer to your LDAP server documentation to find out which indexing methods it supports, and how to create such indices.

Mapping NIS+ Objects Other Than Table Entries

You can store NIS+ objects other than table entries in LDAP. However, doing so has no particular value unless you also have NIS+ replicas that obtain those NIS+ objects from LDAP. The recommended choices are the following.

• There are no replicas, or the replicas obtain their data from the NIS+ master only.

  Edit the mapping configuration file (see NIS+LDAPmapping(4)) to remove the following attribute values for all non-table-entry objects.

  nisplusLDAPdatabaseIdMapping nisplusLDAPentryTtl nisplusLDAPobjectDN

  For example, if you started out from the /var/nis/NIS+LDAPmapping.template file, the sections you need to remove (or disable by commenting) are as follows.

  # Standard NIS+ directories nisplusLDAPdatabaseIdMapping basedir: . . .

  nisplusLDAPdatabaseIdMapping user_attr_table:user_attr.org_dir

  nisplusLDAPdatabaseIdMapping audit_user_table:audit_user.org_dir # Standard NIS+ directories nisplusLDAPentryTtl basedir:21600:43200:43200 . . .

  nisplusLDAPentryTtl user_attr_table:21600:43200:43200 nisplusLDAPentryTtl audit_user_table:21600:43200:43200 # Standard NIS+ directories nisplusLDAPobjectDN basedir:cn=basedir,ou=nisPlus,?base?\

  objectClass=nisplusObjectContainer:\ cn=basedir,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top . . .

  nisplusLDAPobjectDN audit_user_table:cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer:\ cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top

• NIS+ replicas obtain their data from LDAP server.

  Create the nisplusObject attribute and nisplusObjectContainer object class as shown in the following example (LDIF data is suitable for ldapadd(1). Attribute and object class OIDs are for illustration only.)

  dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.1.0 NAME 'nisplusObject' DESC 'An opaque representation of an NIS+ object' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )

  dn: cn=schema changetype: modify add: objectclasses

  objectclasses: (1.3.6.1.4.1.42.2.27.5.42.42.2.0 NAME'nisplusObjectContainer'

  SUP top STRUCTURAL DESC 'Abstraction of an NIS+ object' MUST ( cn $ nisplusObject ) )

  You also need to create a container for the NIS+ objects. The following LDIF syntax shows how to create the ou=nisPlus,dc=some,dc=domain container, and can be used as input to ldapadd(1).

  dn: ou=nisPlus,dc=some,dc=domain ou: nisPlus objectClass: top objectClass: organizationalUnit

NIS+ Entry Owner, Group, Access, and TTL

When NIS+ table entries are created from LDAP data, the default behavior is to initialize the entry object owner, group, access rights, and TTL using the corresponding values from the table object in which the entry object lives. This is normally sufficient, but there might be cases where these NIS+ entry attributes must be established individually. An example of this would be a site that did not use the rpc.nispasswdd(1M) daemon. In order to allow individual users to change their NIS+ passwords (and re-encrypt their Diffie-Hellman keys stored in the cred.org_dir table), passwd.org_dir and cred.org_dir entries for the user should be owned by the user, and have modify rights for the entry owner.

If you need to store table entry owner, group, access, or TTL in LDAP for one or more NIS+ tables, you need to do the following.

How to Store Additional Entry Attributes in LDAP

1. Consult your LDAP server documentation, and create the following new attributes and object class. (LDIF data is suitable for ldapadd. Attribute and object class OIDs are for illustration only.)

   dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.0 NAME 'nisplusEntryOwner' \ DESC 'Opaque representation of NIS+ entry owner' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.1 NAME 'nisplusEntryGroup' \ DESC 'Opaque representation of NIS+ entry group' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.2 NAME 'nisplusEntryAccess' \ DESC 'Opaque representation of NIS+ entry access' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.3 NAME 'nisplusEntryTtl' \ DESC 'Opaque representation of NIS+ entry TTL' \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   dn: cn=schema changetype: modify add: objectclasses

   objectclasses:(1.3.6.1.4.1.42.2.27.5.42.42.5.0 NAME 'nisplusEntryData'\ SUP top STRUCTURAL DESC 'NIS+ entry object non-column data'\

   MUST ( cn ) MAY ( nisplusEntryOwner $ nisplusEntryGroup $\ nisplusEntryAccess $ nisplusEntryTtl ) )

2. Modify the nisplusLDAPobjectDN attribute value for the relevant table(s) so that the write portion includes the newly created nisplusEntryData object class.

   For example, for the passwd.org_dir table, assuming that you are using a mapping file based on /var/nis/NIS+LDAPmapping.template, edit as follows.

   nisplusLDAPobjectDN passwd:ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount:\ ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount,\ objectClass=account,objectClass=top

   Edit the attribute value as follows.

   nisplusLDAPobjectDN passwd:ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount:\ ou=People,?one?objectClass=shadowAccount,\ objectClass=posixAccount,\ objectClass=nisplusEntryData,\ objectClass=account,objectClass=top

3. Edit the nisplusLDAPattributeFromColumn and nisplusLDAPcolumnFromAttribute attribute values to specify any desired subset of owner, group, access, or TTL.

   In Step 2, you created the LDAP attributes used to store these values. For NIS+, there are predefined pseudo-column names called zo_owner, zo_group, zo_access, and zo_ttl, respectively. For example, in order to store owner, group, and access for passwd.org_dir entries in LDAP, modify the nisplusLDAPattributeFromColumn value from the following.

   nisplusLDAPattributeFromColumn \ passwd: dn=("uid=%s,", name), \ cn=name, \ uid=name, \ userPassword=("{crypt$}%s", passwd), \ uidNumber=uid, \ gidNumber=gid, \ gecos=gcos, \ homeDirectory=home, \ loginShell=shell, \ (shadowLastChange,shadowMin,shadowMax, \ shadowWarning, shadowInactive,shadowExpire)=\ (shadow, ":")

   Edit to read as follows.

   nisplusLDAPattributeFromColumn \ passwd: dn=("uid=%s,", name), \ cn=name, \ uid=name, \ userPassword=("{crypt$}%s", passwd), \ uidNumber=uid, \ gidNumber=gid, \ gecos=gcos, \ homeDirectory=home, \ loginShell=shell, \ (shadowLastChange,shadowMin,shadowMax, \ shadowWarning, shadowInactive,shadowExpire)=\ (shadow, ":"), \ nisplusEntryOwner=zo_owner, \ nisplusEntryGroup=zo_group, \ nisplusEntryAccess=zo_access

   Similarly, to set NIS+ entry owner, group, and access from LDAP data for the passwd.org_dir table, modify the following.

   nisplusLDAPcolumnFromAttribute \ passwd: name=uid, \ ("{crypt$}%s", passwd)=userPassword, \ uid=uidNumber, \ gid=gidNumber, \ gcos=gecos, \ home=homeDirectory, \ shell=loginShell, \ shadow=("%s:%s:%s:%s:%s:%s", \ shadowLastChange, \ shadowMin, \ shadowMax, \ shadowWarning, \ shadowInactive, \ shadowExpire)

   Edit to read as follows.

   nisplusLDAPcolumnFromAttribute \ passwd: name=uid, \ ("crypt$%s", passwd)=authPassword, \ uid=uidNumber, \ gid=gidNumber, \ gcos=gecos, \ home=homeDirectory, \ shell=loginShell, \ shadow=("%s:%s:%s:%s:%s:%s", \ shadowLastChange, \ shadowMin, \ shadowMax, \ shadowWarning, \ shadowInactive, \ shadowExpire), \ zo_owner=nisplusEntryOwner, \ zo_group=nisplusEntryGroup, \ zo_access=nisplusEntryAccess

4. Restart the rpc.nisd daemon in order to make the mapping change take effect.

   First, however, you probably want to upload owner, group, access, and/or TTL entry data to LDAP. Perform an upload as shown in How to Convert All NIS+ Data to LDAP in One Operation.

Principal Names and Netnames

NIS+ authentication relies on principal names (a user or host name, qualified by the domain name) and netnames (the secure RPC equivalent of principal names) to uniquely identify an entity (principal) that can be authenticated. While RFC 2307 provides for storing the Diffie-Hellman keys used for NIS+ authentication, there is no specified place for the principal names or netnames.

The /var/nis/NIS+LDAPmapping.template file works around this problem by deriving the domain portion of principal and netnames from the owner name (itself a principal name) of the cred.org_dir table. Hence, if the NIS+ domain is x.y.z., and the owner of the cred.org_dir table is aaa.x.y.z., all principal names for NIS+ entries created from LDAP data will be of the following form.

user or system.x.y.z.

Netnames are of the following form.

unix.uid@x.y.z.

unix.nodename@x.y.z.

While this method of constructing principal and netnames probably is sufficient for most NIS+ installations, there are also some cases in which it fails, as shown in the following.

• The owner name of the cred.org_dir table belongs to a different domain than the one shared by the principal and netnames in the cred.org_dir table. This could be the case for a cred.org_dir table in a subdomain, if the owner is a principal from the parent domain. You can fix this problem in one of the following ways.

  • Change the owner of the cred.org_dir table to match the domain of the entries in the table.

  • Change the mapping rules for the cred.org_dir database IDs to use the owner of some other NIS+ object (which could be created especially for that purpose, if no suitable object already exists).

    For example, if the cred.org_dir table in the domain sub.dom.ain. is owned by master.dom.ain., but principal and netnames in cred.org_dir.sub.dom.ain. should belong to sub.dom.ain, you could create a link object as follows.

    # nisln cred.org_dir.sub.dom.ain. \

    credname.sub.dom.ain.

    Set the owner of the link object to an appropriate principal in the sub.dom.ain. as follows.

    # nischown trusted.sub.dom.ain. credname.sub.dom.ain.

    Edit the mapping file. Change

    (nis+:zo_owner[]cred.org_dir, "*.%s")), \

    to

    (nis+:zo_owner[]credname.sub.dom.ain., "*.%s")), \

    Note that the use of a link object called credname is an example. Any valid object type (except an entry object) and object name will do. The important point is to set the owner of the object to have the correct domain name.

  • If you do not want to give ownership even of a special purpose object to a principal from the domain used for the principal and netnames, create nisplusPrincipalName and nisplusNetname attributes as detailed below.

• The cred.org_dir table contains principal and netnames belonging to more than one domain.

  Consult the documentation for your LDAP server, and create the nisplusPrincipalName and nisplusNetname attributes, as well as the nisplusAuthName object class. (The following is LDIF data for ldapadd. Attribute and object class OIDs are for illustration only.)

  dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.7.0 NAME 'nisplusPrincipalName' \ DESC 'NIS+ principal name' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

  attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.9.0 NAME 'nisplusNetname' \ DESC 'Secure RPC netname' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.42.2.27.5.42.42.10.0 NAME 'nisplusAuthName' \ SUP top AUXILLIARY DESC 'NIS+ authentication identifiers' \ MAY ( nisplusPrincipalName $ nisplusNetname ) )

  You now need to enable the cred.org_dir mapping to use the newly created nisplusNetname and nisplusPrincipalName attributes. The template mapping file, /var/nis/NIS+LDAPmapping.template, contains commented-out lines for this purpose. See the nisplusObjectDN and nisplusLDAPattributeFromColumn/ nisplusLDAPcolumnFromAttribute attribute values for the credlocal, creduser, and crednode database IDs. Once you have edited your mapping file to this effect, restart the rpc.nisd daemon. Do not forget to add the -m option if your mapping file is not the default, and the -Y option if the rpc.nisd daemon should provide NIS (YP) emulation.

  # pkill rpc.nisd

  # /usr/sbin/rpc.nisd -m mapping-file [-Y]

client_info and timezone Tables

Because RFC 2307 does not provide schemas for the information kept in the NIS+ client_info.org_dir and timezone.org_dir tables, mapping of these tables is not enabled by default in the template mapping file (/var/nis/NIS+LDAPmapping.template). If you want to keep the client_info andtimezone information in LDAP, consult your LDAP server documentation, and create the new attributes and object classes discussed in the following sections.

client_info Attributes and Object Class

Create attributes and object class as below, and then create the container for the client_info data. The suggested container name is ou=ClientInfo. LDIF data is for ldapadd(1). The attribute and object class OIDs used in the following are examples only.

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.0 \
		  NAME 'nisplusClientInfoAttr' \
		  DESC 'NIS+ client_info table client column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.1 \
		  NAME 'nisplusClientInfoInfo' \
		  DESC 'NIS+ client_info table info column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.2 \
		  NAME 'nisplusClientInfoFlags' \
		  DESC 'NIS+ client_info table flags column' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.13.0 \
		  NAME 'nisplusClientInfoData' \
		  DESC 'NIS+ client_info table data' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( nisplusClientInfoAttr $ nisplusClientInfoInfo $ nisplusClientInfoFlags ) )

To create the container, put the following LDIF data in a file. Substitute your actual search base for searchBase.

dn: ou=ClientInfo, searchBase

objectClass: organizationalUnit

ou: ClientInfo

objectClass: top

Use the above file as input to the ldapadd command in order to create the ou=ClientInfo container. For example, if your LDAP administrator DN is cn=directory manager, and the file with the LDIF data is called cifile, do the following.

# ldapadd -D cn="directory manager" -f cifile

Depending on the authentication required, the ldapadd command might prompt for a password.

The /var/nis/NIS+LDAPmapping.template file contains commented-out definitions for the client_info.org_dir table. Copy these to the actual mapping file, enable by removing the comment character '#', and restart the rpc.nisd daemon. If necessary, synchronize NIS+ and LDAP data as described in NIS+ to LDAP Migration Scenarios.

timezone Attributes and Object Class

Create attributes and object class as below, and then create the container for the timezone data. The suggested container name is ou=Timezone. (The LDIF data is suitable for ldapadd(1). Attribute and object class OIDs are examples only.)

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.15.0 NAME 'nisplusTimeZone' \
		  DESC 'tzone column from NIS+ timezone table' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.16.0 NAME 'nisplusTimeZoneData' \
		  DESC 'NIS+ timezone table data' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( nisplusTimeZone $ description ) )

To create the ou=Timezone container, put the following LDIF data in a file. Substitute your actual search base for searchBase.

dn: ou=Timezone,searchBase ou: Timezone objectClass: top

objectClass: organizationalUnit

Use the above file as input to ldapadd(1) in order to create the ou=Timezone container. For example, if your LDAP administrator DN is cn=directory manager, and the file with the LDIF data is called tzfile.

# ldapadd -D cn="directory manager" -f tzfile

Depending on the authentication required, the ldapadd command might prompt for a password.

The /var/nis/NIS+LDAPmapping.template file contains commented-out definitions for the timezone.org_dir table. Copy these to the actual mapping file, enable by removing the comment character '#', and restart therpc.nisd daemon. If necessary, synchronize NIS+ and LDAP data as described in NIS+ to LDAP Migration Scenarios.

Adding New Object Mappings

The template mapping file, /var/nis/NIS+LDAPmapping.template, contains mapping information for all standard NIS+ objects. In order to support mapping of site or application specific objects, you will need to add new mapping entries. This is a simple task for non-entry (that is, directory, group, link, or table) objects, but can become complex for entry objects, if the LDAP organization of the corresponding entry data differs greatly from that used by NIS+. The following example shows the simple case.

How to Map Non-Entry Objects

1. Find the fully qualified name of the object to be mapped.

   If this name resides under the domain name specified by the nisplusLDAPbaseDomain attribute, you can omit the portion that equals the nisplusLDAPbaseDomain value.

   For example, if nisplusLDAPbaseDomain has the value some.domain., and the object to be mapped is a table called nodeinfo.some.domain., the object name can be shortened to nodeinfo.

2. Invent a database id to identify the object.

   The database id must be unique for the mapping configuration used, but is not otherwise interpreted. It does not show up in the LDAP data. In order to reduce confusion with entry object mappings, create a database id identifying the table object proper (not the table entries) using an explanatory string like _table at the end.

   For this example, use the database id nodeinfo_table, and establish the connection between the database id and the object in the standard mapping file location (/var/nis/NIS+LDAPmapping) by adding the following.

   nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo.some.domain.

   Assuming that nisplusLDAPbaseDomain is some.domain., the following would also work.

   nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo

3. Decide on a TTL for the object.

   This is the time during which the rpc.nisd daemon regards its local copy of the object as valid. When the TTL expires, the next reference to the object will initiate an LDAP lookup to refresh the object.

   There are two different TTL values. The first is set when the rpc.nisd daemon first loads the object from disk (after a reboot or restart), and the second pertains to all refreshes from LDAP. The first TTL is selected randomly from a configured range. For example, if nodeinfo_table should be valid for a period of between one and three hours following initial load, and for twelve hours thereafter, specify the following.

   nisplusLDAPentryTtl nodeinfo_table:3600:10800:43200

4. Decide where the object data should be stored in LDAP.

   The template mapping file suggests putting non-entry object data in the ou=nisPlus container.

   If you use this scheme, and have not yet created the appropriate attribute, object class, and container, see Mapping NIS+ Objects Other Than Table Entries.

   For example, assume you want to store the nodeinfo object in the ou=nisPlus,dc=some,dc=domain container, and that the LDAP entry should have the cn nodeinfo. Create the following nisplusLDAPobjectDN.

   nisplusLDAPobjectDN nodeinfo_table:\ cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\ objectClass=nisplusObjectContainer:\ cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\ objectClass=nisplusObjectContainer,\ objectClass=top

   Since NIS+ replicas do not write data to LDAP, you can use the nisplusLDAPobjectDN above for both master and replicas.

5. (Skip this step if the NIS+ object to be mapped has not yet been created in NIS+.) Store the object data in LDAP. You could use the rpc.nisd daemon for this purpose, but it is easier to use the nisldapmaptest(1M) utility, as you can leave the rpc.nisd daemon running.

   # nisldapmaptest -m /var/nis/NIS+LDAPmapping -o -t nodeinfo -r

   The —o option specifies the table object itself, not the table entries.

6. Verify that the object data is stored in LDAP. (This example assumes the LDAP server is running on the local machine at port 389.)

   # ldapsearch -b ou=nisPlus,dc=some,dc=domain cn=nodeinfo

   The output would appear similar to the following.

   cn=nodeinfo,ou=nisPlus,dc=some,dc=domain nisplusobject=NOT ASCII objectclass=nisplusObjectContainer objectclass=top cn=nodeinfo

7. Restart the rpc.nisd daemon so that it will start using the new mapping information. Do not forget the -m option if the mapping file has a name other than the default one. Append the -Y option if the rpc.nisd daemon is providing NIS (YP) service.

   # pkill rpc.nisd

   # /usr/sbin/rpc.nisd -m mappingfile [-Y]

Adding Entry Objects

NIS+LDAPmapping(4) specifies the syntax and semantics of table entry mapping in detail, and also provides examples that show how to use each syntactic element. However, the simplest and least error-prone approach is usually to identify an already existing mapping that is similar to what you want to do, and then copy and modify that existing mapping.

For example, assume that you have an NIS+ table called nodeinfo, which is used to store inventory and owner information for nodes. Assume that the NIS+ table was created by the following command.

# nistbladm -c -D access=og=rmcd,nw=r -s : nodeinfo_tbl \

cname=S inventory=S owner= nodeinfo.`domainname`.

The cname column is expected to contain the canonical name of the node. In other words, the same value as that of the cname column in the hosts.org_dir table for the node.

Also assume that the corresponding information is kept in the ou=Hosts container in LDAP, and that the nodeInfo object class (which is an invention for this example, and is not defined in any RFC) has cn as a MUST attribute, and that nodeInventory and nodeOwner are MAY attributes.

In order to upload existing nodeinfo data to LDAP, it will be convenient to create the new mapping attributes in a separate file. You could, for example, use /var/nis/tmpmapping.

1. Create a database id that identifies the NIS+ table to be mapped.

   nisplusLDAPdatabaseIdMapping nodeinfo:nodeinfo

2. Set the TTL for entries in the nodeinfo table. Since the information is expected to change only rarely, use a twelve hour TTL. When the rpc.nisd daemon first loads the nodeinfo table from disk, the TTLs for entries in the table are randomly selected to be between six and twelve hours.

   nisplusLDAPentryTtl nodeinfo:21600:43200:43200

3. Identify an existing mapping that has similar properties to the one you want to create. In this example, mapping the attribute values is trivial (straight assignment). Instead, the complication is that you store the LDAP data in an existing container, so that you have to be careful during removal of the nodeinfo data. You do not want to remove the entire ou=Hosts entry, just the nodeInventory and nodeOwner attributes. You will need a special deletion rule set for this purpose.

   To summarize, you are looking for a mapping that shares a container, and has a delete rule set. One possible candidate is the netmasks mapping, which shares the ou=Networks container, and does have a delete rule set.

4. The template netmasks mapping has the default mapping (from /var/nis/NIS+LDAPmapping.template) as follows.

   nisplusLDAPobjectDN netmasks:ou=Networks,?one?objectClass=ipNetwork,\ ipNetMaskNumber=*:\ ou=Networks,?one?objectClass=ipNetwork: dbid=netmasks_del

   Transferred to the new mapping for nodeinfo, the database id should be nodeinfo, the container ou=Hosts, and the object class nodeInfo. Thus, the first line of the nodeinfo mapping becomes the following.

   nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\

   The second line in the netmasks mapping is the part of the search filter that selects only those ou=Networks entries that contain the ipNetMaskNumber attribute. In this example, select the ou=Hosts entries that have the following nodeInventory attribute.

   nodeInventory=*:\

   The third and fourth lines are the write portion of the nisplusLDAPobjectDN, and they specify where in LDAP nodeinfo data is written, as well as the rule set that is used when nodeinfo data is deleted. In this case, create a delete rule set identified by the database id nodeinfo_del. Because you are always writing to an existing entry in ou=Hosts, you only need to specify the object class for the nodeinfo data proper as follows.

   ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del

   Putting it all together, our nisplusLDAPobjectDN is the following.

   nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\ nodeInventory=*:\ ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del

5. Create the rule set that maps nodeinfo data from NIS+ to LDAP. The template (from netmasks) is the following.

   nisplusLDAPattributeFromColumn \ netmasks: dn=("ipNetworkNumber=%s,", addr), \ ipNetworkNumber=addr, \ ipNetmaskNumber=mask, \ description=comment

   The ou=Hosts container has an additional complication in this case, as RFC 2307 specifies the dn should contain the IP address. However, the IP address is not stored in the nodeinfo table, so you must obtain it in another manner. Fortunately, the crednode mapping in the template file shows how to obtain the IP address.

   nisplusLDAPattributeFromColumn \ crednode: dn=("cn=%s+ipHostNumber=%s,", \ (cname, "%s.*"), \ ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))), \

   Thus, you can copy that portion of the crednode mapping. In this case, however, the cname column value is the actual host name (not the principal name), so you do not need to extract just a portion of the cname. Making the obvious substitutions of attribute and column names, the nodeinfo mapping becomes the following.

   nisplusLDAPattributeFromColumn \ nodeinfo: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=inventory, \ nodeOwner=owner

6. When mapping data from LDAP to NIS+, the template netmasks entry is as follows.

   nisplusLDAPcolumnFromAttribute \ netmasks: addr=ipNetworkNumber, \ mask=ipNetmaskNumber, \ comment=description

   After substituting attribute and column names, this result is the following.

   nisplusLDAPcolumnFromAttribute \ nodeinfo: cname=cn, \ inventory=nodeInventory, \ owner=nodeOwner

7. The delete rule set for netmasks is as follows.

   nisplusLDAPattributeFromColumn \ netmasks_del: dn=("ipNetworkNumber=%s,", addr), \ ipNetmaskNumber=

   The above specifies that when a netmasks entry is deleted in NIS+, the ipNetmaskNumber attribute in the corresponding ou=Networks LDAP entry is deleted. In this case, delete the nodeInventory and nodeOwner attributes. Therefore, using the dn specification from item (5) above, results in the following.

   nisplusLDAPattributeFromColumn \ nodeinfo_del: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=, \ nodeOwner=

8. The mapping information is complete. In order to begin using it, stop and later start the rpc.nisd daemon.

   # pkill rpc.nisd

9. If there already is data in the NIS+ nodeinfo table, upload that data to LDAP. Put the new nodeinfo mapping information into a separate file, /var/nis/tmpmapping.

   # /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping \

   -x nisplusLDAPinitialUpdateAction=to_ldap \

   -x nisplusLDAPinitialUpdateOnly=yes

10. Add the mapping information from the temporary file, /var/nis/tmpmapping, to the actual mapping file. Use an editor to do this, or append the data (assuming the actual mapping file is /var/nis/NIS+LDAPmapping) as follows.

    # cp -p /var/nis/NIS+LDAPmapping \

    /var/nis/NIS+LDAPmapping.backup

    # cat /var/nis/tmpmapping >> /var/nis/NIS+LDAPmapping

    ---

    Note –

    Note the double arrow redirection, “>>”. A single arrow, “>”, would overwrite the target file.

    ---

11. Restart the rpc.nisd daemon. Add the -Y option if the rpc.nisd daemon also serves NIS (YP) data as follows.

    # /usr/sbin/rpc.nisd -m /var/nis/NIS+LDAPmapping

Storing Configuration Information in LDAP

In addition to keeping NIS+/LDAP configuration information in the configuration files and on the command line, configuration attributes can also be stored in LDAP. This is useful if the configuration information is shared by many NIS+ servers, and is expected to change on a regular basis.

To enable storing of configuration attributes in LDAP, consult your LDAP server documentation and create the following new attributes and object class. The configuration information is expected to reside at the location specified by the nisplusLDAPconfigDN value (from the rpc.nisd command line, or from /etc/default/rpc.nisd), with a cn equal to the nisplusLDAPbaseDomain value (as it is known to the rpc.nisd daemon before reading any configuration information from LDAP).

LDIF data is suitable for ldapadd(1) (attribute and object class OIDs are examples only).

The defaultSearchBase, preferredServerList, and authenticationMethod attributes derive from a draft “DUA config” schema, which is intended to become an IETF standard. In any case, the following definitions are sufficient for the purposes of NIS+LDAPmapping(4).

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.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 )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.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 )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' \
		  DESC 'Identifies the authentication method used to connect to the DSA'\
		  EQUALITY caseIgnoreMatch \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

NIS+/LDAP configuration attributes are as follows.

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.0 \
		  NAME 'nisplusLDAPTLS' \
		  DESC 'Transport Layer Security' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.1 \
		  NAME 'nisplusLDAPTLSCertificateDBPath' \
		  DESC 'Certificate file' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.2 \
		  NAME 'nisplusLDAPproxyUser' \
		  DESC 'Proxy user for data store/retrieval' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.3 \
		  NAME 'nisplusLDAPproxyPassword' \
		  DESC 'Password/key/shared secret for proxy user' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.4 \
		  NAME 'nisplusLDAPinitialUpdateAction' \
		  DESC 'Type of initial update' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.5 \
		  NAME 'nisplusLDAPinitialUpdateOnly' \
		  DESC 'Exit after update ?' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.6 \
		  NAME 'nisplusLDAPretrieveErrorAction' \
		  DESC 'Action following an LDAP search error' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.7 \
		  NAME 'nisplusLDAPretrieveErrorAttempts' \
		  DESC 'Number of times to retry an LDAP search' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.8 \
		  NAME 'nisplusLDAPretrieveErrorTimeout' \
		  DESC 'Timeout between each search attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.9 \
		  NAME 'nisplusLDAPstoreErrorAction' \
		  DESC 'Action following an LDAP store error' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.10 \
		  NAME 'nisplusLDAPstoreErrorAttempts' \
		  DESC 'Number of times to retry an LDAP store' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.11 \
		  NAME 'nisplusLDAPstoreErrorTimeout' \
		  DESC 'Timeout between each store attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.12 \
		  NAME 'nisplusLDAPrefreshErrorAction' \
		  DESC 'Action when refresh of NIS+ data from LDAP fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.13 \
		  NAME 'nisplusLDAPrefreshErrorAttempts' \
		  DESC 'Number of times to retry an LDAP refresh' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.14 \
		  NAME 'nisplusLDAPrefreshErrorTimeout' \
		  DESC 'Timeout between each refresh attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.15 \
		  NAME 'nisplusNumberOfServiceThreads' \
		  DESC 'Max number of RPC service threads' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.16 \
		  NAME 'nisplusThreadCreationErrorAction' \
		  DESC 'Action when a non-RPC-service thread creation fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.17 \
		  NAME 'nisplusThreadCreationErrorAttempts' \
		  DESC 'Number of times to retry thread creation' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.18 \
		  NAME 'nisplusThreadCreationErrorTimeout' \
		  DESC 'Timeout between each thread creation attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.19 \
		  NAME 'nisplusDumpErrorAction' \
		  DESC 'Action when an NIS+ dump fails' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.20 \
		  NAME 'nisplusDumpErrorAttempts' \
		  DESC 'Number of times to retry a failed dump' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.21 \
		  NAME 'nisplusDumpErrorTimeout' \
		  DESC 'Timeout between each dump attempt' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.22 \
		  NAME 'nisplusResyncService' \
		  DESC 'Service provided during a resync' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.23 \
		  NAME 'nisplusUpdateBatching' \
		  DESC 'Method for batching updates on master' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.24 \
		  NAME 'nisplusUpdateBatchingTimeout' \
		  DESC 'Minimum time to wait before pinging replicas' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.25 \
		  NAME 'nisplusLDAPmatchFetchAction' \
		  DESC 'Should pre-fetch be done ?' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.26 \
		  NAME 'nisplusLDAPbaseDomain' \
		  DESC 'Default domain name used in NIS+/LDAP mapping' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.27 \
		  NAME 'nisplusLDAPdatabaseIdMapping' \
		  DESC 'Defines a database id for an NIS+ object' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.28 \
		  NAME 'nisplusLDAPentryTtl' \
		  DESC 'TTL for cached objects derived from LDAP' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.29 \
		  NAME 'nisplusLDAPobjectDN' \
		  DESC 'Location in LDAP tree where NIS+ data is stored' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.30 \
		  NAME 'nisplusLDAPcolumnFromAttribute' \
		  DESC 'Rules for mapping LDAP attributes to NIS+ columns' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.31 \
		  NAME 'nisplusLDAPattributeFromColumn' \
		  DESC 'Rules for mapping NIS+ columns to LDAP attributes' \
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.19.0 NAME 'nisplusLDAPconfig' \
		  DESC 'NIS+/LDAP mapping configuration' \
		  SUP top STRUCTURAL MUST ( cn ) \
		  MAY ( preferredServerList $ defaultSearchBase $
authenticationMethod $ nisplusLDAPTLS $ nisplusLDAPTLSCertificateDBPate
$ nisplusLDAPproxyUser $ nisplusLDAPproxyPassword $ nisplusLDAPinitialUpdateAction
$ nisplusLDAPinitialUpdateOnly $ nisplusLDAPretrieveErrorAction
$ nisplusLDAPretrieveErrorAttempts $ nisplusLDAPretrieveErrorTimeout
$ nisplusLDAPstoreErrorAction $ nisplusLDAPstoreErrorAttempts
$ nisplusLDAPstoreErrorTimeout $ nisplusLDAPrefreshErrorAction
$ nisplusLDAPrefreshErrorAttempts $ nisplusLDAPrefreshErrorTimeout
$ nisplusNumberOfServiceThreads $nisplusThreadCreationErrorAction
$ nisplusThreadCreationErrorAttempts $ nisplusThreadCreationErrorTimeout
$ nisplusDumpErrorAction $ nisplusDumpErrorAttempts
$ nisplusDumpErrorTimeout $ nisplusResyncService $ nisplusUpdateBatching
$ nisplusUpdateBatchingTimeout $ nisplusLDAPmatchFetchAction
$ nisplusLDAPbaseDomain $ nisplusLDAPdatabaseIdMapping $ nisplusLDAPentryTtl 
$ nisplusLDAPobjectDN $ nisplusLDAPcolumnFromAttribute !
$ nisplusLDAPattributeFromColumn ) )

Create a file containing the following LDIF data (substitute your actual search base for searchBase, and the fully qualified domain name for domain.)

dn: cn=domain,searchBase

cn: domain

objectClass: top objectClass: nisplusLDAPconfig

Use the above file as input to ldapadd(1) to create the NIS+/LDAP configuration entry. Initially, the entry is empty. Use ldapmodify(1) to add configuration attributes. For example, to set the nisplusNumberOfServiceThreads attribute to “32”, create the following file (for input to ldapmodify(1)).

dn: cn=domain, searchBasenisplusNumberOfServiceThreads: 32