System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

Part IV 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 OS, with a focus on the use of Sun JavaTM System Directory Server (formerly Sun ONE Directory Server).

Chapter 8 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 Java System Directory Server (formerly Sun ONE Directory Server). However, while using the Sun Java System Directory Server is recommended, it is not required. A brief description of generic directory server requirements appears in Chapter 14, LDAP General Reference (Reference).


Note –

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

Suggested Background Reading

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

Additional Prerequisite

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

LDAP Naming Services Compared to Other Naming Services

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

 

DNS 

NIS 

LDAP 

Namespace

Hierarchical 

Flat 

Hierarchical 

Data Storage

Files/resource records 

2 column maps 

Directories (varied) 

Indexed database 

Servers

Master/slave 

Master/slave 

Master/replica 

Multi master replica 

Security

None 

None (root or nothing) 

SSL, varied 

Transport

TCP/IP 

RPC 

TCP/IP 

Scale

Global 

LAN 

Global 

Advantages of LDAP Naming Services

Restrictions of LDAP Naming Services

Following are some restrictions associated with LDAP naming services:


Note –

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)

Task 

For Instructions 

Confirm that patch is installed 

  

Plan the network model 

Planning the LDAP Network Model

Plan the DIT 

Chapter 10, Planning Requirements for LDAP Naming Services (Tasks)

Set up replica servers 

LDAP and Replica Servers

Plan the security model 

Planning the LDAP Security Model

Choose client profiles and default attribute values 

Planning Client Profiles and Default Attribute Values for LDAP

Plan the data population 

Planning the LDAP Data Population

Configure Sun Java System Directory Server prior to using it with LDAP naming services 

Sun ONE Directory Server 5.2 (Solaris Edition)

Set up Sun Java System Directory Server for use with LDAP naming clients 

Chapter 11, Setting Up Sun Java System Directory Server With LDAP Clients (Tasks)

Manage printer entries 

Managing Printer Entries

Initialize an LDAP client 

Initializing an LDAP Client

Initialize a client by using profiles 

Using Profiles to Initialize a Client

Initialize a client manually  

Initializing a Client Manually

Uninitialize a client 

Uninitializing a Client

Use service search descriptors to modify client profiles 

Using Service Search Descriptors to Modify Client Access to Various Services

Retrieve naming service information 

Retrieving LDAP Naming Services Information

Customize a client environment 

Customizing the LDAP Client Environment

Chapter 9 LDAP Basic Components and Concepts (Overview)

This chapter covers the following topics.

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 -lnetgroup 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 With LDAP

Unlike 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.)

Table 9–1 DIT Default Locations

Default Container 

Information Type 

ou=Ethers

bootparams(4), ethers(4) 

ou=Group

group(4) 

ou=Hosts

hosts(4), ipnodes(4), publickey for hosts 

ou=Aliases

aliases(4) 

ou=Netgroup

netgroup(4) 

ou=Networks

networks(4), netmasks(4) 

ou=People

passwd(1), shadow(4), user_attr(4), audit_user(4), publickey for users 

ou=printers

printers(4) 

ou=Protocols

protocols(4) 

ou=Rpc

rpc(4) 

ou=Services

services(4) 

ou=SolarisAuthAttr

auth_attr(4) 

ou=SolarisProfAttr

prof_attr(4), exec_attr(4) 

ou=projects

project 

automountMap=auto_*

auto_* 

Default LDAP 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 14, 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


Note –

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.


Note –

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. In the following example, the service search descriptor specifies searching for the password entries in three containers.

ou=myuser,dc=example,dc=com

ou=newuser,dc=example,dc=com

ou=extuser,dc=example,dc=com

Note that a trailing ',' in the example 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 14, 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.

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

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

Table 9–2 Client Profile Attributes

Attribute 

Description 

cn

The profile name. The attribute has no default value. The value must be specified. 

preferredServerList

The host addresses of the preferred servers is a space separated list of server addresses. (Do not use host names.) The servers in this list are tried in order before those in defaultServerList until a successful connection is made. This has no default value. At least one server must be specified in either preferredServerList or defaultServerList.

defaultServerList

The host addresses of the default servers is a space separated list of server addresses. (Do not use host names.) After the servers in preferredServerlist are tried, those default servers on the client's subnet are tried, followed by the remaining default servers, until a connection is made. At least one server must be specified in either preferredServerList or defaultServerList. The servers in this list are tried only after those on the preferred server list. This attribute has no default value.

defaultSearchBase

The DN relative to which to locate the well-known containers. There is no default for this value. However, this can be overridden for a given service by the serviceSearchDescriptor attribute.

defaultSearchScope

Defines the scope of a database search by a client. It can be overridden by the serviceSearchDescriptor attribute. The possible values are one or sub. The default value is a one level search.

authenticationMethod

Identifies the method of authentication used by the client. The default is none (anonymous). See Choosing Authentication Methods for more information.

credentialLevel

Identifies the type of credentials a client should use to authenticate. The choices are anonymous, proxy, or self (also known as per user). The default is anonymous.

serviceSearchDescriptor

Defines how and where a client should search for a naming database, for example, if the client should look in one or more points in the DIT. By default no SSDs are defined. 

serviceAuthenticationMethod

Authentication method used by a client for the specified service. By default, no service authentication methods are defined. If a service does not have serviceAuthenticationMethod defined, it will default to the value of authenticationMethod.

attributeMap

Attribute mappings used by client. By default no attributeMap is defined.

objectclassMap

Object class mappings used by client. By default no objectclassMap is defined.

searchTimeLimit

Maximum time [in seconds] a client should allow for a search to complete before timing out. This does not affect the time the LDAP server will allow for a search to complete. The default value is 30 seconds.

bindTimeLimit

Maximum time in seconds a client should allow to bind with a server before timing out. Default value is 30 seconds.

followReferrals

Specifies whether a client should follow an LDAP referral. Possible values TRUE or FALSE. The default value is TRUE.

profileTTL

Time between refreshes of the client profile from the LDAP server by the ldap_cachemgr(1M). Default is 43200 seconds or 12 hours. If given a value of 0, the profile will never be refreshed.

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.

Table 9–3 Local Client Attributes

Attribute 

Description 

adminDN

Specifies the administrator entry's distinguished name for the admin credential. If the value of the enableShadowUpdate switch is true on the client system, and credentialLevel has a value other than self, then adminDN must be specified.

adminPassword

Specifies the administrator entry's password for the admin credential. If the value of the enableShadowUpdate switch is true on the client system, and credentialLevel has a value other than self, then adminPassword must be defined.

domainName

Specifies the client's domain name (which becomes the default domain for the client system). This attribute has no default value and must be specified. 

proxyDN

The proxy's distinguished name. If the client system is configured with credentialLevel of proxy, the proxyDN must be specified.

proxyPassword

The proxy's password. If the client system is configured with credentialLevel of proxy, proxyPassword must be defined.

certificatePath

The directory on the local file system containing the certificate databases. If a client system is configured with authenticationMethod or serviceAuthenticationMethod using TLS, then this attribute is used. The default value is /var/ldap.


Note –

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. When you start the LDAP client, the ldap_cachemgr daemon is invoked. The daemon performs the following key functions.


Note –

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 can use the LDAP repository in two different ways. One is as a source of both a naming service and an authentication service. The other is strictly as the source of naming data. This section discusses the concepts of client identity, authentication methods, pam_ldap and pam_unix modules, and account management when the LDAP repository is used as both a naming service and authentication service. This section also discusses the use of LDAP naming services in conjunction with the Kerberos environment (Part VI, Kerberos Service, in System Administration Guide: Security Services) and pam_krb5(5) modules.


Note –

Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config


Note –

If you use Kerberos as your authentication system and integrate it with the LDAP naming system, you will be able to support a single sign on (SSO) environment in your enterprise through Kerberos. You will also be able to use that same identity system when querying LDAP naming data on a per-user or per-host basis.


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 Java System 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.

When you use pam_ldap 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.

When Kerberos is used to perform authentication, and when authentication in LDAP naming services is also enabled (as is required for per-user mode), Kerberos can provide dual functions. Kerberos authenticates to the server and the Kerberos identity for the principal (user or host) is used to authenticate to the directory. In this way, the same user identity that is used to authenticate to the system is also used to authenticate to the directory for lookups and updates. Administrators can use access control information (ACI) in the directory to limit the results out of the naming service if desired.

Transport Layer Security (TLS)


Note –

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.


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 Java System Directory Server for SSL, see the Administration Guide for the version of Sun Java System Directory Server that you are using. You will also need to set up your LDAP client for SSL.

If using TLS, the necessary security databases must be installed. In particular, the certificate and key database files are needed. For example, if you adopt an older database format from Netscape Communicator, two files, cert7.db and key3.db, are required. Or if you use a new database format from Mozilla, three files, cert8.db, key3.db, and secmod.db are needed. The cert7.db or cert8.dbfile contains trusted certificates. The key3.dbfile contains the client's keys. Even if the LDAP naming service client does not use client keys, this file must be present. The secmod.db file contains the security modules such as the PKCS#11 module. This file is not required if the older format is used.

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 four possible credential levels with which to authenticate to a directory server.

Anonymous

If you use anonymous access, you can access only the data that is available to everyone. In anonymous mode, an LDAP BIND operation does not take place. 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.


Caution – Caution –

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.



Note –

Sun Java System 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 Java System Directory Server that you are using.


Proxy

The client authenticates or binds to the directory using a single 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. The proxy account is a shared-per-system resource. That is, each user logged in to a system using proxy access, including the root user, sees the same results as all other users on that system. 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.


Note –

Be aware that the proxy credential level applies to all users and processes on any given system. If two users need to use different naming policies, they must use different machines, or they must use the per-user authentication model.


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.

Per User

Per-user (self) authentication uses the Kerberos identity (principal) to perform a lookup for each user or each system when authenticating to the directory server. With per-user authentication, the system administrator can use access control instructions (ACI's), access control lists (ACL's), roles, groups or other directory access control mechanisms to grant or deny access to specific naming service data for specific users or systems.


Note –

When configuring per-user mode, the configuration value to enable this mode is “self,” which denotes per-user mode.


To use the per-user authentication model, the Kerberos single sign-on service must be deployed. In addition, the one or more directory servers used in the deployment must support SASL and the SASL/GSSAPI authentication mechanism. Because Kerberos expects to use files and DNS for host name lookups, instead of LDAP, DNS should be deployed in this environment. Also, to use per-user authentication, nscd must be enabled. The nscd daemon is not an optional component in this configuration.

enableShadowUpdate Switch

If the enableShadowUpdate switch is set to true on the client, the admin credentials will be used to update the shadow data. Shadow data is stored in the shadowAccount object class on the directory server. Admin credentials are defined by the values of the adminDN and adminPassword attributes, as described in Local Client Attributes. These admin credentials are not used for any other purpose.

Admin credentials have properties similar to Proxy credentials. The exception is that for admin credentials, the user must have all privileges for the zone or have an effective UID of root to read or update the shadow data. Admin credentials can be assigned to any entry that is allowed to bind to the directory. However, do not use the same directory manager identity (cn=Directory Manager) of the LDAP server.

This entry with admin credentials must have sufficient access to read and write the shadow data in the directory. Because the entry is a shared-per-system resource, the adminDN and adminPassword attributes must be configured on every client. The encrypted adminPassword is stored locally on the client. The password uses the same authentication methods that are configured for the client. The admin credentials are used by all users and processes on a given system to read and update the shadow data.

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 12, Setting Up LDAP Clients (Tasks) for more information on setting up client profiles.

Similarly, if you configure a client to enable shadow data updates, and the client credential level is not self, the client saves its adminDN and adminPassword attributes locally in the /var/ldap/ldap_client_cred file. The value of adminPassword is also encrypted and is used only by the ldap_cachemgr daemon process.

If you configure a client to use per-user authentication, the Kerberos identity and Kerberos ticket information for each principal (each user or host) are used during authentication. In this environment the directory server maps the Kerberos principal to a DN and the Kerberos credentials are used to authenticate to that DN. The directory server can then use its access control instruction (ACI) mechanisms to allow or deny access to naming service data as necessary. In this situation, Kerberos ticket information is used to authenticate to the directory server and the system does not store authentication DNs or passwords on the system. Therefore, for this type of configuration, you do not need to specify the adminDN and adminPassword attributes when the client is initialized with the ldapclient command.

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


Caution – Caution –

Sun Java System 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.

Table 9–4 Authentication Methods

 

Bind 

Password on wire 

Password on Sun Java System Directory Server 

Session 

none

No 

N/A 

N/A 

No encryption 

simple

Yes 

Clear 

Any 

No encryption 

sasl/digest-MD5

Yes 

Encryption 

Clear 

No encryption 

sasl/cram-MD5

Yes 

Encryption 

N/A 

No encryption 

sasl/GSSAPI

Yes 

Kerberos 

Kerberos 

Encryption 

tls:simple

Yes 

Encryption 

Any 

Encryption 

tls:sasl/cram-MD5

Yes 

Encryption 

N/A 

Encryption 

tls:sasl/digest-MD5

Yes 

Encryption 

Clear 

Encryption 

Authentication and Services

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


Note –

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



Note –

In per-user mode, pam_krb5 Service Module (pam Kerberos) is used as the authentication service. ServiceAuthenticationMethod is not needed in this mode of operation.



Note –

If the enableShadowUpdate switch is set to true, the ldap_cachemgr daemon binds to the LDAP server by using the authentication method that is defined in the serviceAuthenticationMethod parameter of passwd-cmd, if the method is defined. Otherwise, authenticationMethod is used. The daemon will not use the none authentication method.


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, including pam_unix, pam_krb5, and pam_ldap.

If the per-user authentication method is used, pam_krb5, the strongest authentication service of the three methods listed above, must be enabled. See pam_krb5(5) and the System Administration Guide: Security Services.

The pam_krb5 authentication system may be used even if per-user authentication is not enabled. If proxy or anonymous credential levels are used to access directory server data then restricting access to directory data on a per-user basis is not possible.

Because of its increased flexibility, support of stronger authentication methods, and ability to use account management, the use of pam_ldap is recommended over the use of pam_unix when anonymous or proxy authentication methods are used.

pam_unix Service Modules

If you have not changed the pam.conf(4) file, pam_unix functionality is enabled by default.


Note –

The pam_unix module has been removed and is no longer supported with Solaris. A set of other service modules provides equivalent or greater functionality. Therefore, in this guide, pam_unix refers to the equivalent functionality, not to the pam_unix module itself.


Following is a list of the modules that provide the equivalent pam_unix functionality.

pam_authtok_check(5)

pam_authtok_get(5)

pam_authtok_store(5)

pam_dhkeys(5)

pam_passwd_auth(5)

pam_unix_account(5)

pam_unix_auth(5)

pam_unix_cred(5)

pam_unix_session(5)

pam_unix follows the traditional model of UNIX authentication, as described in the following list.

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

  2. The user is prompted for the user's 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.


Note –

pam_unix is not compatible with the sasl authentication method digest-MD5, since Sun Java System 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.



Note –

pam_unix supports account management when the enableShadowUpdate switch is set to true. The controls for a remote LDAP user account are applied just as the controls are applied to a local user account that is defined in the passwd and shadow files. In enableShadowUpdate mode, for the LDAP account, the system updates and uses the shadow data on the LDAP server for password aging and account locking. Of course, the shadow data of the local account only applies to the local client system, whereas the shadow data of an LDAP user account applies to the user on all client systems.

Password history checking is only supported for the local client, not for an LDAP user account.


pam_krb5 Service Module

Refer to pam_krb5(5) and the System Administration Guide: Security Services.

pam_ldap Service Module

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

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


Note –

Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

pam_ldap does not read the userPassword attribute. Therefore, there is no need to grant access to read the userPassword attribute unless there are other clients using pam_unix. Also, 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.


Caution – Caution –

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, pam_ldap, and pam_krb5.

Table 9–5 Authentication Behavior in LDAP With pam_unix, pam_ldap, and pam_krb5

 

pam_unix

pam_ldap

pam_krb5

Password Sent  

Uses passwd service authentication method

Uses passwd service authentication method

Uses Kerberos single sign on technology, not passwords 

New Password Sent 

Encrypted 

No encryption (unless TLS is used) 

Uses Kerberos, no passwords are sent over the wire 

New Password Stored 

crypt format

Password storage scheme defined on Sun Java System Directory Server 

Passwords are managed by Kerberos 

Requires password read? 

Yes 

No 

No 

sasl/digest-MD5 compatibility after changing password

No. Password is not stored in clear. User cannot authenticate.

Yes. As long as default storage scheme is set to clear, user can authenticate.

No. sasl/GSSAPI is used. There are no passwords over the wire and there are no passwords to be stored in the directory server, except when using a Kerberos kdc that manages its password database in the LDAP directory server.

Password policy supported? 

Yes. enableShadowUpdate must be set to true.

Yes, if so configured. 

See pam_krb5(5), Kerberos V5 Account Management Module.

PAM and Changing Passwords

Use the passwd command to change a password. If the enableShadowUpdate switch is not set to true, the userPassword attribute must be writable by the user. If the enableShadowUpdate switch is set to true, the admin credentials must be able to update the userPassword attribute. Remember that the serviceAuthenticationMethod for passwd-cmd overrides the authenticationMethod for this operation. Depending on the authentication method that is used, the current password might be unencrypted on the wire.

In the case of pam_unix, 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. See the pam_authtok_store(5) man page for more information.

If the enableShadowUpdate switch is set to true, pam_unix also updates the related shadow information when the user password is changed. pam_unix updates the same shadow fields in the local shadow files that pam_unix updates when the local user password is changed.

As of the Solaris 10 software release, pam_ldap no longer supports password update. The previously recommended use of pam_authtok_store with the server_policy option now replaces the pam_ldap password update capability. When you use pam_authtok_store, the new password is sent to the LDAP server in the clear. Therefore, to ensure privacy, use TLS. If TLS is not used, the new userPassword is subject to snooping. If you set an untagged password with Sun Java System Directory Server, the software encrypts the password by using the passwordStorageScheme attribute. For more information about the passwordStorageScheme, see the section on user account management in the Administration Guide for the version of Sun Java System Directory Server that you are using.


Note –

You need to consider the following configuration issues when setting the passwordStorageScheme attribute. If an 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 Java System Directory Server, passwordStorageScheme must be set to clear.


Account Management

If you select pam_krb5 as your account and password management system, the Kerberos environment will manage all your account, password, account lockout, and other account management details. Refer to pam_krb5(5) and the System Administration Guide: Security Services.

If you do not use pam_krb5, then LDAP naming services can be configured to take advantage of the password and account lockout policy support in Sun Java System Directory Server. You can configure pam_ldap(5) to support user account management. passwd(1) enforces password syntax rules set by the Sun Java System Directory Server password policy, when used with the proper PAM configuration.

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


Note –

The preceding account management features only work with the Sun Java System Directory Server. 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 Java System Directory Server that you are using. Also see Example pam_conf file for pam_ldap Configured for Account Management. Do not enable account management for proxy accounts.


Before configuring the password and account lockout policy on Sun Java System Directory Server, make sure all hosts use the “newest” LDAP client with pam_ldap account 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.


Note –

Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

Account Management With pam_unix

If the enableShadowUpdate switch is set to true on the client, account management functionality that is available to local accounts is also available to LDAP accounts. Functionality includes password aging, account expiry and notification, failed login account locking, and so on. Also, the -dluNfnwx options to the passwd command are now supported in LDAP. Thus, the full functionality of the passwd command and the pam_unix* modules in the files naming service is supported in the LDAP naming service. The enableShadowUpdate switch provides a way to implement consistent account management for users who are defined in both the files and the LDAP scope.

To prevent users from modifying their own account management data and thereby circumventing password policy, the LDAP server is configured to prevent user write access to the user's own shadow data on the server. An administrator with admin credentials performs the shadow data updates for a client system. Such a configuration, however, conflicts with the pam_ldap module, which requires that passwords be modifiable by users. Therefore, account management by pam_ldap and pam_unix are incompatible.


Caution – Caution –

Do not use both pam_ldap and pam_unix in the same LDAP naming domain. Either all clients use pam_ldap or all clients use pam_unix. This limitation might indicate that you need a dedicated LDAP server. For example, a web or email application might expect users to change their own password on the LDAP server.


The implementation of enableShadowUpdate also requires that the admin credential (adminDN plus adminPassword) be stored locally on every client. Even though adminPassword is encrypted and can only be read from the /var/ldap/ldap_client_cred file by the ldap_cachemgr daemon, special care must be taken to protect the admin credential. To protect the credential, make it different from the server's directory manager (cn=directory manager). Another protection would be to configure the serviceAuthenticationMethod with a value of tls:simple or better for the passwd-cmd service, so that the value of adminPassword is not sent in the clear and therefore becomes vulnerable to snooping.

Unlike using pam_ldap for account management, using pam_unix for account management does not require a change to the /etc/pam.conf file. The default /etc/pam.conf file is sufficient.

Chapter 10 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.

LDAP 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 LDAP 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 the Sun Java System Directory Server (formerly Sun ONE Directory Server) documentation for information about how to choose an appropriate directory suffix.

LDAP and Replica Servers

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

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 Java System Directory Server that you are using.

Planning the LDAP 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 an enterprise-wide single sign-on solution, with no passwords being sent over the wire, or the wire encryption of data and the ability to access control data results from the directory server on a per-user basis. You must also decide whether you want strong authentication to protect the user password flow across the wire, and/or if you need 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 four possible credential levels for credentialLevel: anonymous, proxy, proxy anonymous and self. See LDAP Naming Services Security Model for a detailed discussion of LDAP naming service security concepts.


Note –

Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config


Note –

If you enable pam_krb5 and Kerberos as an enterprise-wide single sign on solution, you can design a system whereby login passwords are only needed once at the start of a session. See System Administration Guide: Security Services for further details. If you enable Kerberos you will generally also need to enable DNS. See the chapters on DNS in this manual for further details.


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

Planning Client Profiles and Default Attribute Values for LDAP

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.

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 12, Setting Up LDAP Clients (Tasks) for more information about setting up LDAP clients.

Planning the LDAP 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.


Note –

ldapaddent can only be run on an LDAP client.


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

ProcedureHow to Populate a Server With host Entries Using ldapaddent

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

  2. On a client machine, become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  3. Make the machine an LDAP client.


    # ldapclient init -a profileName=new -a domainName=west.example.com \
    192.168.0.1 
    
  4. Populate the server with data.


    # ldapaddent -D “cn=directory manager” -f /etc/hosts hosts
    

    You will be prompted for a password.

    In this example, ldapaddent will use the authentication method that has been configured in the profile new. Selecting simple will cause the password to be sent in the clear. For more information, refer to the ldapaddent(1M) man page.

Chapter 11 Setting Up Sun Java System Directory Server With LDAP Clients (Tasks)

This chapter describes how to configure Sun Java System Directory Server (formerly Sun ONE Directory Server) to support a network of Solaris LDAP naming services clients. The information is specific to the Sun Java System Directory Server. For information about installing and configuring the directory server, see the Sun Java System Directory Server documentation, that is included with the Sun Java Enterprise System.


Note –

You must have already performed all the procedures described in the installation and configuration documentation that shipped with your Sun Java System Directory Server before you can configure Sun Java System Directory Server to work with Solaris LDAP clients.



Note –

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


This chapter covers the following topics.

Configuring Sun Java System Directory Server by 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.


Note –

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


Table 11–1 Server Variables Defined

Variable 

Definition for Example Network 

Port number at which an instance of the directory server is installed 

389 (default) 

Name of server  

myserver (from the FQDN myserver.west.example.com or 192.168.0.1)

Replica server(s) (IPnumber:port number) 

192.168.0.2 [for myreplica.west.example.com]

Directory manager 

cn=directory manager (default) 

Domain name to be served  

west.example.com

Maximum time (in seconds) to process client requests before timing out 

-1-

Maximum number of entries returned for each search request 

-1-


Note –

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.


Table 11–2 Client Profile Variables Defined

Variable 

Definition for Example Network 

Profile name (the default name is default) 

WestUserProfile

Server list (defaults to the local subnet) 

192.168.0.1

Preferred server list (listed in order of which server to try first, second, and so on) 

none

Search scope (number of levels down through the directory tree. 'One', the default, or 'Sub')

one (default)

Credential used to gain access to server. Default is anonymous

proxy

Follow Referrals? ( a pointer to another server if the main server is unavailable) Default is no.

Y

Search time limit (default is 30 seconds) for waiting for server to return information. 

default

Bind time limit (default is 10 seconds) for contacting the server.  

default

Authentication method Default is none.

simple


Note –

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

ipHostNumber

pres,eq,sub

uidNumber

pres,eq

gidNumber

pres,eq

ipNetworkNumber

pres,eq

automountkey

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 14, 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 Java System Directory Server, otherwise known as the virtual list view (VLV), 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 be enforced.

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

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

idsconfig creates entries for several VLV indexes. Use the directoryserver script to stop the server and to create the actual VLV indexes. See the idsconfig(1M) and the directoryserver(1M) man pages for more information. Refer to the output of the idsconfig command to determine the VLV entries created by idsconfig and the syntax of the corresponding directoryserver commands that you need to run. See Example idsconfig Setup for sample idsconfig output.

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 the latest Solaris release. Using SSDs, you can configure Solaris 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 the latest Solaris release. By definition, Solaris LDAP client assumes that user entries are stored in ou=People container. Thus, when it comes to searching the passwd service, LDAP client 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 client 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 Java System 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


Note –

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.



Caution – Caution –

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.


ProcedureHow to Configure Sun Java System Directory Server by Using idsconfig

  1. Make sure the target Sun Java System Directory Server is up and running.

  2. Run idsconfig.


    # /usr/lib/ldap/idsconfig
    

    Refer to Example 11–1 for an 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.

  3. Answer the questions when 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.

    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.

Example idsconfig Setup

This section provides an example of a basic idsconfig setup that uses many of the defaults. The most complicated method of modifying client profiles is to create SSDs. Refer to Using Service Search Descriptors to Modify Client Access to Various Services for a detailed discussion.

The data in square brackets after a prompt indicates the default value for that prompt. To accept the default value, press Return.


Note –

Any parameters that are left blank in the summary screen are not 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.


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

In the following example, the idsconfig utility is run immediately after a server instance is created on the LDAP server.


# 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 JES Directory Server's  hostname to setup: myserver
Enter the port number for iDS (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]
  Checking LDAP Base DN ...
  Validating LDAP Base DN and Suffix ...
  No valid suffixes were found for Base DN dc=west,dc=example,dc=com
Enter suffix to be created (b=back/h=help): [dc=west,dc=example,dc=com]
Enter ldbm database name (b=back/h=help): [west]
  sasl/GSSAPI is not supported by this LDAP server
Enter the profile name (h=help): [default] WestUserProfile
Default server list (h=help): [192.168.0.1]
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
  4  self
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
  6  sasl/GSSAPI
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]
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]
Do you want to enable shadow update (y/n/h)? [n]
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
         Suffix to create          : dc=west,dc=example,dc=com
         Database to create        : west
  3  Profile name to create        : WestUserProfile
  4  Default Server List           : 192.168.0.1
  5  Preferred Server List         :
  6  Default Search Scope          : one
  7  Credential Level              : proxy
  8  Authentication Method         : simple
  9  Enable Follow Referrals       : FALSE
 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                    : 10
 19  Enable shadow update          : FALSE
 20  Service Search Descriptors Menu

Enter config value to change: (1-20 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. Database west successfully created.
  7. Suffix dc=west,dc=example,dc=com successfully created.
  8. NisDomainObject added to dc=west,dc=example,dc=com.
  9. Top level "ou" containers complete.
  10. automount maps: auto_home auto_direct auto_master auto_shared processed.
  11. ACI for dc=west,dc=example,dc=com modified to disable self modify.
  12. Add of VLV Access Control Information (ACI).
  13. Proxy Agent cn=proxyagent,ou=profile,dc=west,dc=example,dc=com added.
  14. Give cn=proxyagent,ou=profile,dc=west,dc=example,dc=com read permission 
      for password.
  15. Generated client profile and loaded on server.
  16. Processing eq,pres indexes:
      uidNumber (eq,pres)   Finished indexing.
      ipNetworkNumber (eq,pres)   Finished indexing.
      gidnumber (eq,pres)   Finished indexing.
      oncrpcnumber (eq,pres)   Finished indexing.
      automountKey (eq,pres)   Finished indexing.
  17. Processing eq,pres,sub indexes:
      ipHostNumber (eq,pres,sub)   Finished indexing.
      membernisnetgroup (eq,pres,sub)   Finished indexing.
      nisnetgrouptriple (eq,pres,sub)   Finished indexing.
  18. 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
      west.example.com.getauhoent vlv_index   Entry created
      west.example.com.getsoluent vlv_index   Entry created
      west.example.com.getauduent vlv_index   Entry created
      west.example.com.getauthent vlv_index   Entry created
      west.example.com.getexecent vlv_index   Entry created
      west.example.com.getprofent vlv_index   Entry created
      west.example.com.getmailent vlv_index   Entry created
      west.example.com.getbootent vlv_index   Entry created
      west.example.com.getethent vlv_index   Entry created
      west.example.com.getngrpent vlv_index   Entry created
      west.example.com.getipnent vlv_index   Entry created
      west.example.com.getmaskent vlv_index   Entry created
      west.example.com.getprent vlv_index   Entry created
      west.example.com.getip4ent vlv_index   Entry created
      west.example.com.getip6ent vlv_index   Entry created

idsconfig: Setup of iDS server myserver is complete.


Note: idsconfig has created entries for VLV indexes.

      For DS5.x, use the directoryserver(1m) script on myserver
      to stop the server.  Then, using directoryserver, follow the
      directoryserver examples below to create the actual VLV indexes.

      For DS6.x, use dsadm command delivered with DS6.x on myserver
      to stop the server.  Then, using dsadm, follow the
      dsadm examples below to create the actual VLV indexes.

  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getgrent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.gethostent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getnetent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getpwent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getrpcent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getspent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getauhoent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getsoluent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getauduent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getauthent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getexecent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getprofent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getmailent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getbootent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getethent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getngrpent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getipnent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getmaskent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getprent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getip4ent
  directoryserver -s <server-instance> vlvindex -n west -T west.example.com.getip6ent

  <install-path>/bin/dsadm reindex -l -t west.example.com.getgrent <directory-instance-path> 
   dc=west,dc=example,dc=com
  <install-path>/bin/dsadm reindex -l -t west.example.com.gethostent <directory-instance-path> 
   dc=west,dc=example,dc=com
  .
  .
  .
  <install-path>/bin/dsadm reindex -l -t west.example.com.getip6ent <directory-instance-path> 
   dc=west,dc=example,dc=com

Populating the Directory Server Using ldapaddent


Note –

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 Java System 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.


Note –

ldapaddent(1M) can only run on an LDAP client. Chapter 12, Setting Up LDAP Clients (Tasks) describes how to configure a client for the LDAP naming service.


ProcedureHow to Populate Sun Java System Directory Server With User Password Data Using ldapaddent

See ldapaddent(1M). See Chapter 9, LDAP Basic Components and Concepts (Overview) for information about LDAP security and write-access to the directory server.

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


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

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.

ProcedureHow to Populate the Directory Server With Additional Profiles Using ldapclient

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  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.1 192.168.0.2:386" \
    

    > myprofile.ldif

  3. Upload the new profile to the server.


    # ldapadd -h 192.168.0.1 -D “cn=directory manager” -f myprofile.ldif
    

Configuring the Directory Server to Enable Account Management

Account management can be implemented for clients that use pam_ldap and for clients that use pam_unix.


Caution – Caution –

Do not use both pam_ldap and pam_unix in the same LDAP naming domain. Either all clients use pam_ldap or all clients use pam_unix. This limitation might indicate that you need a dedicated LDAP server.


For Clients That Use pam_ldap

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 account 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 Java System Directory Server that you are using.


Note –

Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

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

Note –

pam_ldap account management relies on Sun Java System 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.


For Clients That Use pam_unix

To enable Solaris LDAP clients to use pam_unix for account management, the server must be set up to enable the updating of shadow data. Unlike pam_ldap account management, pam_unix does not require extra configuration steps. All configuration can be performed by running the idsconfig utility. For a basic idsconfig run, see Example 11–1.

The following shows the output of two idsconfig runs.

The first idsconfig run uses an existing client profile.


# /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 JES Directory Server's  hostname to setup: myserver
Enter the port number for iDS (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]
  Checking LDAP Base DN ...
  Validating LDAP Base DN and Suffix ...
  sasl/GSSAPI is not supported by this LDAP server

Enter the profile name (h=help): [default] WestUserProfile

Profile 'WestUserProfile' already exists, it is possible to enable
shadow update now. idsconfig will exit after shadow update
is enabled. You can also continue to overwrite the profile
or create a new one and be given the chance to enable
shadow update later.

Just enable shadow update (y/n/h)? [n] y
Add the administrator identity (y/n/h)? [y]
Enter DN for the administrator: [cn=admin,ou=profile,dc=west,dc=example,dc=com]
Enter passwd for the administrator: 
Re-enter passwd: 
  ADDED: Administrator identity cn=admin,ou=profile,dc=west,dc=example,dc=com.
         Proxy ACI LDAP_Naming_Services_proxy_password_read does not 
         exist for dc=west,dc=example,dc=com.
  ACI SET: Give cn=admin,ou=profile,dc=west,dc=example,dc=com read/write access 
           to shadow data.
  ACI SET: Non-Admin access to shadow data denied.

  Shadow update has been enabled.

The second idsconfig run creates a new profile for later use. Only partial output is displayed.


# /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 JES Directory Server's  hostname to setup: myserver
Enter the port number for iDS (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]
  Checking LDAP Base DN ...
  Validating LDAP Base DN and Suffix ...
  sasl/GSSAPI is not supported by this LDAP server

Enter the profile name (h=help): [default] WestUserProfile-new
Default server list (h=help): [192.168.0.1]
.
.
.
Do you want to enable shadow update (y/n/h)? [n] y

              Summary of Configuration

  1  Domain to serve               : west.example.com
  2  Base DN to setup              : dc=west,dc=example,dc=com
         Suffix to create          : dc=west,dc=example,dc=com
  3  Profile name to create        : WestUserProfile-new
.
.
.
 19  Enable shadow update          : TRUE
.
.
.
Enter DN for the administrator: [cn=admin,ou=profile,dc=west,dc=example,dc=com]
Enter passwd for the administrator:
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.
.
.
.
  11. ACI for dc=test1,dc=mpklab,dc=sfbay,dc=sun,dc=com modified to 
      disable self modify.
.
.
.
  15. Give cn=admin,ou=profile,dc=west,dc=example,dc=com write permission for shadow.
...

Migrating Your Sun Java System Directory Server

Schema changes were implemented between the release of Sun Java System Directory Server 5.1 (formerly Sun ONE Directory Server) and the release of Sun Java System Directory Server 5.2. The ldapaddent command now adds objectclass: device to the entries of ethers/bootparams. Therefore, if you choose to use the LDAP commands to migrate directory data from Sun Java System Directory Server 5.1 to 5.2, you must use ldapaddent -d to export data and ldapaddent to import data. Otherwise, if you use the Sun Java System Directory Server tools db2ldif and ldif2db to migrate data, you must apply Sun Java System Directory Server 5.2 with all patches before migrating the data, or the data import could fail.

For information about configuring the Sun Java System Directory Server 5.2, see the Sun Java System Directory Server documentation, that is included with the Sun Java Enterprise System.

Chapter 12 Setting Up LDAP Clients (Tasks)

This chapter describes how to set up a Solaris LDAP naming services client. This chapter covers the following topics:

Prerequisites to LDAP Client Setup

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

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 set up an LDAP client and use the various other LDAP utilities to get information about, and check the status of, an LDAP client.

LDAP and the Service Management Facility

The LDAP client service is managed by using the Service Management Facility. For an overview of SMF, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

Initializing an LDAP Client

ldapclient(1M) is a utility used to set up LDAP clients in the Solaris system. 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.


Note –

The Solaris OS does not support a configuration in which an NIS client and a native LDAP client co-exist on the same client system.


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


Note –

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

ProcedureHow to Initialize a Client Using Profiles

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Run ldapclient with init.


    # ldapclient init \
    -a profileName=new \
    -a domainName=west.example.com 192.168.0.1
    System successfully configured

Using Per-User Credentials


Note –

Do not edit either of the client configuration files directly. Use the ldapclient command to create or modify the content of these files.


ProcedureHow to Initialize a Client Using Per-User Credentials

Before You Begin

Before you set up a client with per-user credentials the following items must already be configured:

  1. Run ldapclient init to initialize the client by using the gssapi profile:


    # /usr/sbin/ldapclient init -a profilename=gssapi_SPARKS.COM -a \
    domainname=example.com 9.9.9.50
    
  2. Try to log in as a user:

    Run kinit -p user.

    Run ldaplist -l passwd user in user's login session and you should see “userpassword.”

    But ldaplist -l passwd bar can get the entry without userpassword. By default root can still see userpassword of everybody.

Notes About Using Per-User Credentials

See other references in this guide and in the System Administration Guide: Security Services for details.

Using Proxy Credentials

ProcedureHow to Initialize a Client Using Proxy Credentials


Note –

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


  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Run ldapclient (defining proxy values).


    # ldapclient init \
    -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \
    -a domainName=west.example.com \
    -a profileName=pit1 \
    -a proxyPassword=test1234 192.168.0.1
    System successfully configured

    The -a proxyDN and -a proxyPassword are required if the profile to be used is set up 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.

Enabling Shadow Updating in LDAP

ProcedureHow to Initialize a Client to Enable the Updating of Shadow Data

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. To set the enableShadowUpdate switch and define the admin credential, run the ldapclient command.

    • To update an already running client, run this command:


      # ldapclient mod -a enableShadowUpdate=TRUE \
      -a adminDN=cn=admin,ou=profile,dc=west,dc=example,dc=com \
      -a adminPassword=admin-password
      System successfully configured
    • To initialize a client, run this command:


      # ldapclient init \
      -a adminDN=cn=admin,ou=profile,dc=west,dc=example,dc=com \
      -a adminPassword=admin-password
      -a domainName=west.example.com \
      -a profileName=WestUserProfile \
      -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \
      -a proxyPassword=i<proxy_password> \
      192.168.0.1
      System successfully configured
  3. To verify the configuration, display the contents of the /var/ldap/ldap_client_cred file.

    The output should contain lines similar to the following:


    # cat /var/ldap/ldap_client_cred
    
       NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com
       NS_LDAP_BINDPASSWD= {NS1}4a3788f8eb85de11
       NS_LDAP_ENABLE_SHADOW_UPDATE= TRUE
       NS_LDAP_ADMIN_BINDDN= cn=admin,ou=profile,dc=west,dc=example,dc=com
       NS_LDAP_ADMIN_BINDPASSWD= {NS1}4a3788f8c053434f

Initializing a Client Manually

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

ProcedureHow to Initialize a Client Manually

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Use ldapclient manual to initialize the client.


    # ldapclient manual \
    -a domainName=dc=west.example.com \
    -a credentialLevel=proxy \
    -a defaultSearchBase=dc=west,dc=example,dc=com \ 
    -a proxyDN=cn=proxyagent,ou=profile,dc=west,dc=example,dc=com \ 
    -a proxyPassword=testtest 192.168.0.1
    
  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.1
    NS_LDAP_SEARCH_BASEDN= dc=west,dc=example,dc=com
    NS_LDAP_CREDENTIAL_LEVEL= proxy

Modifying a Manual Client Configuration

ProcedureHow to Modify a Manual Configuration

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

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


    # ldapclient mod -a authenticationMethod=simple
    
  3. Use ldapclient list to verify the change was made.


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

You cannot change some attributes of an LDAP client configuration by using the mod subcommand. For example, you cannot change the profileName and profileTTL attributes. To change these attributes, create a new profile by using the ldapclient init command, as described in Using Profiles to Initialize a Client. Or, run the ldapclient manual command, as described in Initializing a Client Manually.

Uninitializing a Client

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.

ProcedureHow to Uninitialize a Client

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Use ldapclient uninit.


    # ldapclient uninit
    System successfully recovered

Setting Up TLS Security


Note –

The security database files must be readable by everyone. Do not include any private keys in the key3.db.


If using TLS, the necessary security databases must be installed. In particular, the certificate and key database files are needed. For example, if you adopt an older database format from Netscape Communicator, two files, cert7.db and key3.db, are required. Or, if you use a newer database format from Mozilla, three files, cert8.db, key3.db and secmod.db are needed. The cert7.db or cert8.db file contains 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. The secmod.db file contains the security modules such as PKCS#11 module. This file is not required if the older format is used.


Note –

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 Java System 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 CommunicatorTM, 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

Note –

While Netscape manages the cert7.db and key3.db files in the $HOME/.netscape directory, Mozilla has its cert8.db, key3.db and secmod.db files managed in a sub-directory under $HOME/.mozilla. 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

pam_ldap is one authentication and account management PAM module option for LDAP. See the pam_ldap(5) man page for more information about the features currently supported with pam_ldap.

If you have selected both the per-user mode and the self credentials option, then you must also enable the PAM Kerberos pam_krb5(5) pam modules. See pam_krb5(5) and the System Administration Guide: Security Services documentation for further details.

Configuring PAM to Use UNIX policy

To configure PAM to use UNIX policy, follow the sample 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 the pam.conf(4) man page.

Configuring PAM to Use LDAP server_policy

To configure PAM to use LDAP server_policy, follow the sample in Example pam_conf file for pam_ldap Configured for Account Management. 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 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.


Note –

Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

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.


Note –

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 an 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 user1dn: 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

Customizing the LDAP 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. Also, in some cases files may not be set up by default.

Modifying the nsswitch.conf File for LDAP

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 With LDAP

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

The recommended configuration is:

hosts: files dns

ipnodes: files dns

If per-user authentication is used, the sasl/GSSAPI and Kerberos mechanisms expect the dns naming service to be configured and enabled. See the chapters on DNS in this administration guide for further details.

Chapter 13 LDAP Troubleshooting (Reference)

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


Note –

The LDAP service is managed by the Service Management Facility. Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command. See LDAP and the Service Management Facility for more information about using the Facility with LDAP. For an overview of the Facility, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.


Monitoring LDAP 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.

For an overview of the Service Management Facility, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

Verifying ldap_cachemgr Is Running

The ldap_cachemgr daemon must be running and functioning correctly at all times. Otherwise, the system doesn't work. When you start the LDAP client, the client starts ldap_cachemgr daemon automatically. So, if the ldap_cachemgr is not running, the LDAP client will be disabled. Following are two methods for determining if the LDAP client is online.

For more information about the ldap_cachemgr daemon, see the ldap_cachemgr(1M) man page.

Checking the Current Profile Information

Become superuser or assume an equivalent role, and run ldapclient with the list option.


# ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=west,dc=example,dc=com
NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f
NS_LDAP_SERVERS= 192.168.0.1, 192.168.0.10
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.1
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. See the ldapclient(1M) man page for more 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. See the ldaplist(1) man page for more information.

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=*"

In Solaris 9 and earlier releases, the ldapsearch command, by default, produced output in a nonstandard textual representation. The default output for ldapsearch in later Solaris releases is the industry standardized LDIF format that is defined by RFC-2849. All versions of ldapsearch can output LDIF format using the -L option.

LDAP Configuration Problems and Solutions

The following sections describe LDAP configuration problems and suggests solutions to the problems.

Unresolved Hostname

The Solaris platform 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 account 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.

    • The user tried to log in using a nonpassword-based program, such as rsh, rlogin, ssh, or sftp.

  12. If per-user authentication and sasl/GSSAPI are being used, then some component of Kerberos or the pam_krb5 configuration is setup incorrectly. Refer to the System Administration Guide: Security Services for details on resolving these issues.

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 init option with the profileName attribute specified. 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 14 LDAP General Reference (Reference)

This chapter covers the following topics.

  1. Blank Checklists

  2. LDAP Upgrade Information

  3. LDAP Commands

  4. Example pam.conf File for pam_ldap

  5. Example pam_conf file for pam_ldap Configured for Account Management

  6. IETF Schemas for LDAP

  7. Directory User Agent Profile (DUAProfile) Schema

  8. Solaris Schemas

  9. Internet Print Protocol Information for LDAP

  10. Generic Directory Server Requirements for LDAP

  11. Default Filters Used by LDAP Naming Services

Blank Checklists

Table 14–1 Server Variable Definitions

Variable 

Definition for _______ Network 

Port number at which an instance of the directory server is installed (389) 

 

Name of server  

 

Replica server(s) (IP number:port number) 

 

Directory manager [dn: cn=directory manager]

 

Domain name to be served  

 

Maximum time (in seconds) to process client requests before timing out 

 

Maximum number of entries returned for each search request 

 

Table 14–2 Client Profile Variable Definitions

Variable 

Definition for ________ Network 

Profile name 

 

Server list (defaults to the local subnet) 

 

Preferred server list (listed in order of which server to try first, second, and so on) 

 

Search scope (number of levels down through the directory tree. 'One' or 'Sub')

 

Credential used to gain access to server. The default is anonymous

 

Follow Referrals? ( a pointer to another server if the main server is unavailable) The default is no.

 

Search time limit (in seconds, default 30) for waiting for server to return information.

 

Bind time limit (in seconds, default 30) for contacting server. The default is seconds.

 

Authentication method Default is none.

 

LDAP Upgrade Information

This section provides information to consider when upgrading from the Solaris 8 release to a Solaris 9 or later release.

Compatibility

Clients configured on Solaris 9 or later Solaris software releases are fully compatible with directory servers set up to serve Solaris 8 clients, which only support version 1 profiles. However, to take advantage of newer features built into Solaris 9 and later releases, and to use the newer security model, you must use version 2 profiles.

Servers can serve a mix of both old and new clients. 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 with the serviceSearchDescriptors attribute. Obviously if the server is not using the default schema, older clients cannot use that server as Solaris 8 clients cannot arbitrarily map nondefault schema.

Running the ldap_cachemgr Daemon

Beginning with the Solaris 9 release, the ldap_cachemgr daemon must be running at all times. The daemon is required for the client to function properly. When you use the Service Management Facility's svcadm command to start the LDAP client, the ldap_cachemgr daemon is automatically invoked. See the ldap_cachemgr(1M) man page for more information.

New automount Schema

Beginning with the Solaris 9 release, by default the Solaris software uses a new schema for automount entries. This new schema replaces the generic NIS map schema that Solaris 8 clients used. This means that if you set up a server with Solaris 9 or later software tools, Solaris 8 clients cannot see the automount entries. For sites where the server being set up is to serve both Solaris 8 and later Solaris software 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 clients based on Solaris 9 or later software 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

pam_ldap Changes

The Solaris 10 OS release introduced several changes to pam_ldap, identified in the following list. Also, see the pam_ldap(5) man page for more information.

An upgrade to this release will not automatically update the existing pam.conf file to reflect the above changes. If the existing pam.conf file contains a pam_ldap configuration, you will be notified after the upgrade by the CLEANUP file. You will need to examine the pam.conf file and modify it, as needed.

It is not possible to provide a clean automatic update for the changes listed above, primarily password prompting and password update, due to the relevance of other modules used in the same stack and also due to the existence of third party modules.

See pam_passwd_auth(5), pam_authtok_get(5), pam_authtok_store(5), and pam.conf(4) man pages for more information.

LDAP Commands

There are two sets of LDAP-related commands in the Solaris system. 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. The following tools support a common text-based format for representing directory information called the LDAP Data Interchange Format (LDIF). These commands can be used to manipulate directory entries directly.

ldapsearch(1)

ldapmodify(1)

ldapadd(1)

ldapdelete(1)

LDAP Tools Requiring LDAP Naming Services

Table 14–3 LDAP Tools

Tool 

Function 

ldapaddent(1M)

Used to create entries in LDAP containers from the corresponding /etc files. This tool allows populating the directory from files. For example, it reads /etc/passwd format file and populates passwd entries in the directory.

ldaplist(1)

Used to list contents of various services from the directory. 

idsconfig(1M)

Used to set up Sun Java System Directory Server to serve LDAP naming service clients. 

Example pam.conf File for pam_ldap


#
# 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 required		pam_unix_cred.so.1
login	auth sufficient		pam_unix_auth.so.1
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 required		pam_unix_cred.so.1
rlogin	auth sufficient		pam_unix_auth.so.1
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_cred.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 sufficient		pam_unix_auth.so.1
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 required		pam_unix_cred.so.1
other	auth sufficient		pam_unix_auth.so.1
other	auth required		pam_ldap.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd	auth sufficient		pam_passwd_auth.so.1
passwd	auth required		pam_ldap.so.1
#
# cron service (explicit because of non-usage of pam_roles.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_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 requisite	pam_authtok_get.so.1
other	password requisite	pam_authtok_check.so.1
other	password required	pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#

Example pam_conf file for pam_ldap Configured for Account Management


Note –

Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to perform account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:


dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config


#
# 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_unix_cred.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 required         pam_unix_cred.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_cred.so.1
rsh     auth binding          pam_unix_auth.so.1 server_policy
rsh     auth required         pam_ldap.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 required         pam_unix_cred.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_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 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 and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#

IETF Schemas for LDAP

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.


Note –

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 platform are the following.

Solaris Projects Schema

/etc/project is a local source of attributes associated with projects. For more information, see user_attr(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 for LDAP

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 for LDAP

To support LDAP clients based on Solaris 9 or later Solaris versions, 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.

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

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

If using sasl/GSSAPI, the server must support SASL, GSSAPI, Kerberos 5 authentication. Support for GSS encryption over the wire is optional.

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))
--------------
Table 14–4 LDAP Filters Used in getXbyY Calls

Filter 

Definition 

bootparamByName

(&(objectClass=bootableDevice)(cn=%s))

etherByHost

(&(objectClass=ieee802Device)(cn=%s))

etherByEther

(&(objectClass=ieee802Device)(macAddress=%s))

groupByName

(&(objectClass=posixGroup)(cn=%s))

groupByGID

(&(objectClass=posixGroup)(gidNumber=%ld))

groupByMember

(&(objectClass=posixGroup)(memberUid=%s))

hostsByName

(&(objectClass=ipHost)(cn=%s))

hostsByAddr

(&(objectClass=ipHost)(ipHostNumber=%s))

keyByUID

(&(objectClass=nisKeyObject)(uidNumber=%s))

keyByHost

(&(objectClass=nisKeyObject)(cn=%s))

netByName

(&(objectClass=ipNetwork)(cn=%s))

netByAddr

(&(objectClass=ipNetwork)(ipNetworkNumber=%s))

nisgroupMember

(membernisnetgroup=%s)

maskByNet

(&(objectClass=ipNetwork)(ipNetworkNumber=%s))

printerByName

(& (objectClass=sunPrinter)(|(printer-name=%s)(printer-aliases=%s)))

projectByName

(&(objectClass=SolarisProject)(SolarisProjectName=%s))

projectByID

(&(objectClass=SolarisProject)(SolarisProjectID=%ld))

protoByName

(&(objectClass=ipProtocol)(cn=%s))

protoByNumber

(&(objectClass=ipProtocol)(ipProtocolNumber=%d))

passwordByName

(&(objectClass=posixAccount)(uid=%s))

passwordByNumber

(&(objectClass=posixAccount)(uidNumber=%ld))

rpcByName

(&(objectClass=oncRpc)(cn=%s))

rpcByNumber

(&(objectClass=oncRpc)(oncRpcNumber=%d))

serverByName

(&(objectClass=ipService)(cn=%s))

serverByPort

(&(objectClass=ipService)(ipServicePort=%ld))

serverByNameAndProto

(&(objectClass=ipService)(cn=%s)(ipServiceProtocol=%s))

specialByNameserver

(ipServiceProtocol=%s))

ByPortAndProto

(&(objectClass=shadowAccount)(uid=%s))

netgroupByTriple

(&(objectClass=nisNetGroup)(cn=%s))

netgroupByMember

(&(objectClass=nisNetGroup)(cn=%s))

authName

(&(objectClass=SolarisAuthAttr)(cn=%s))

auditUserByName

(&(objectClass=SolarisAuditUser)(uid=%s))

execByName

(&(objectClass=SolarisExecAttr)(cn=%s) (SolarisKernelSecurityPolicy=%s)(SolarisProfileType=%s))

execByPolicy

(&(objectClass=SolarisExecAttr)(SolarisProfileId=%s) (SolarisKernelSecurityPolicy=%s)(SolarisProfileType=%s))

profileByName

(&(objectClass=SolarisProfAttr)(cn=%s))

userByName

(&(objectClass=SolarisUserAttr)(uid=%s))

The following table lists the getent attribute filters.

Table 14–5 getent Attribute Filters

Filter 

Definition 

aliases

(objectClass=rfc822MailGroup)

auth_attr

(objectClass=SolarisAuthAttr)

audit_user

(objectClass=SolarisAuditUser)

exec_attr

(objectClass=SolarisExecAttr)

group

(objectClass=posixGroup)

hosts

(objectClass=ipHost)

networks

(objectClass=ipNetwork)

prof_attr

(objectClass=SolarisProfAttr)

protocols

(objectClass=ipProtocol)

passwd

(objectClass=posixAccount)

printers

(objectClass=sunPrinter)

rpc

(objectClass=oncRpc)

services

(objectClass=ipService)

shadow

(objectclass=shadowAccount)

project

(objectClass=SolarisProject)

usr_attr

(objectClass=SolarisUserAttr)

Chapter 15 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

The NIS–to–LDAP transition service (N2L service) replaces existing NIS daemons on the NIS master server with NIS–to–LDAP transition daemons. The N2L service also creates an NIS–to–LDAP mapping file on that 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:

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 9, LDAP 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:

NIS-to-LDAP Tools and the Service Management Facility

The NIS and LDAP services are managed by the Service Management Facility. Administrative actions on these services, such as enabling, disabling, or restarting, can be performed by using the svcadm command. You can query the status of services by using the svcs command. For more information about using SMF with LDAP and NIS, see LDAP and the Service Management Facility and NIS and the Service Management Facility. For an overview of SMF, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

NIS-to-LDAP 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.

When Not to Use the NIS-to-LDAP Service

Do not use the N2L service in these situations:

Effects of the NIS-to-LDAP 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.

User Type 

Effect of N2L Service 

NIS master server administrators 

The NIS master server is converted to an N2L server. The NISLDAPmapping and ypserv configuration files are installed on the N2L server. After the N2L server is established, you can use LDAP commands to administer your naming information.

NIS slave server administrators 

After the N2L transition, an NIS slave server continues to run NIS in the usual manner. The N2L server pushes updated NIS maps to the slave server when yppush is called by ypmake. See the ypmake(1M) man page.

NIS clients 

NIS read operations are no different than traditional NIS. When a Solaris LDAP naming services client changes information in the DIT, the information is copied into the NIS maps. The copy operation is complete after a configurable timeout expires. Such behavior is similar to the behavior of a normal NIS client when the client is connected to an NIS slave server. 

If an N2L server cannot bind to the LDAP server for a read, the N2L server returns the information from its own cached copy. Alternatively, the N2L server can return an internal server error. You can configure the N2L server to respond either way. See the ypserv(1M) man page for more details.

All users 

When an NIS client makes a password change request, the change is immediately visible on the N2L master server and to native LDAP clients. 

If you attempt to change a password on the NIS client, and the LDAP server is unavailable, then the change is refused and the N2L server returns an internal server error. This behavior prevents incorrect information from being written into the cache. 

NIS-to-LDAP Transition Terminology

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

Table 15–1 Terminology Related to the N2L Transition

Term 

Description 

N2L configuration files 

The /var/yp/NISLDAPmapping and /var/yp/ypserv files that the ypserv daemon uses to start the master server in N2L mode. See the NISLDAPmapping(4) and ypserv(4) man pages for details.

map 

In the context of the N2L service, the term map is used in two ways: 

  • To refer to a database file in which NIS stores a specific type of information

  • To describe the process of mapping NIS information to or from the LDAP DIT

mapping 

The process of converting NIS entries to or from LDAP DIT entries. 

mapping file 

The NISLDAPmapping file that establishes how to map entries between NIS and LDAP files.

standard maps 

Commonly used NIS maps that are supported by the N2L service without requiring manual modification to the mapping file. A list of supported standard maps is provided in Supported Standard Mappings.

nonstandard maps 

Standard NIS maps that are customized to use mappings between NIS and the LDAP DIT other than the mappings identified in RFC 2307 or its successor. 

custom map 

Any map that is not a standard map and therefore requires manual modifications to the mapping file when transitioning from NIS to LDAP. 

LDAP client 

Any traditional LDAP client that reads and writes to any LDAP server. A traditional LDAP client is a system that reads and writes to any LDAP server. A Solaris LDAP naming services client handles a customized subset of naming information. 

LDAP naming services client 

A Solaris LDAP client that handles a customized subset of naming information. 

N2L server 

An NIS master server that has been reconfigured as an N2L server by using the N2L service. Reconfiguration includes replacing NIS daemons and adding new configuration files. 

NIS-to-LDAP Commands, Files, and Maps

There are two utilities, two configuration files, and a mapping that are associated with the N2L transition.

Table 15–2 Descriptions of N2L Commands, Files, and Maps

Command/File/Map 

Description 

/usr/lib/netsvc/yp/inityp2l

A utility that assists with the creation of the NISLDAPmapping and ypserv configuration files. This utility is not a general-purpose tool for the management of these files. An advanced user can maintain the N2L configuration files or create custom mappings by using a text editor to examine and customize the inityp2l output. See the inityp2l(1M) man page.

/usr/lib/netsvc/yp/ypmap2src

A utility that converts standard NIS maps to approximations of the equivalent NIS source files. The primary use for ypmap2src is to convert from an N2L transition server to traditional NIS. See the ypmap2src(1M) man page.

/var/yp/NISLDAPmapping

A configuration file that specifies the mapping between NIS map entries and equivalent Directory Information Tree (DIT) entries in LDAP. See the NISLDAPmapping(4) man page.

/var/yp/ypserv

A file that specifies configuration information for the NIS–to–LDAP transition daemons. See the ypserv(4) man page.

ageing.byname

A mapping used by yppasswdd to read and write password aging information to the DIT when the NIS-to-LDAP transition is implemented.

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

During the NIS-to-LDAP transition, the yppasswdd daemon uses the N2L-specific map, ageing.byname, to read and write password aging information to the DIT. If you are not using password aging, then the ageing.byname mapping is ignored.

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.

Task 

Description 

For Instructions 

Complete all prerequisites. 

Be sure that you have properly configured your NIS server and Sun Java System Directory Server (LDAP server).  

Prerequisites for the NIS-to-LDAP Transition

Set up the N2L service. 

Run inityp2l on the NIS master server to set up one of these mappings:

  

  

Standard mappings 

How to Set Up the N2L Service With Standard Mappings

  

Custom or nonstandard mappings 

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

Customize a map. 

View examples of how to create custom maps for the N2L transition. 

Examples of Custom Maps

Configure Sun Java System Directory Server with N2L. 

Configure and tune Sun Java System Directory Server as your LDAP server for the N2L transition. 

NIS-to-LDAP Best Practices With Sun Java System Directory Server

Troubleshoot the system. 

Identify and resolve common N2L issues. 

NIS-to-LDAP Troubleshooting

Revert to NIS. 

Revert to NIS using the appropriate map: 

  

  

Maps based on old NIS source files 

How to Revert to Maps Based on Old Source Files

  

Maps based on the current DIT 

How to Revert to Maps Based on Current DIT Contents

Prerequisites for the NIS-to-LDAP Transition

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

Setting Up the NIS-to-LDAP 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.


Note –

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


ProcedureHow 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. On the NIS master server, become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

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


    # inityp2l
    

    Run the inityp2l script on the NIS master server and follow the prompts. See Setting Up the NIS-to-LDAP 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.


      # svcadm disable network/nis/server:default
      
    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. Start the NIS daemons to ensure that they use the new maps.


      # svcadm enable network/nis/server:default
      

      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.


      # svcadm disable network/nis/server:default
      
    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. Start the NIS daemons to ensure that they use the new maps.


      # svcadm enable network/nis/server:default
      

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

Use this procedure if the following circumstances apply:

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

  2. On the NIS master server, become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  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 NIS-to-LDAP 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.


      # svcadm disable network/nis/server:default
      
    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. Start the NIS daemons to ensure that they use the new maps.


      # svcadm enable network/nis/server:default
      
    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.


      # svcadm disable network/nis/server:default
      
    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. Start the NIS daemons to ensure that they use the new maps.


      # svcadm enable network/nis/server:default
      
  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 9, LDAP 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), ",")  

NIS-to-LDAP Best Practices With Sun Java System Directory Server

The N2L service supports Sun Java System Directory Server (formerly Sun ONE 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 Java System 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 Java System Directory Server, you can enhance the directory server to improve performance. To make these enhancements, you must have LDAP administrator privileges on the Sun Java System 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 Sun Java System Directory Server (and Sun ONE and iPlanet Directory Server) documentation is available on the Sun Java System Directory Server Enterprise Edition 6.2 web site.

Creating Virtual List View Indexes With Sun Java System 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 Java System Directory Server, see the Sun Java System Directory Server Enterprise Edition 6.2 documentation.

VLV search results use a fixed page size of 50000. If VLVs are used with Sun Java System 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.

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

VLVs for Standard Maps

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

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 Java System Directory Server VLVs for maps, or copy and modify existing VLV indexes, if the following conditions apply:

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 Java System Directory Server

When the N2L server refreshes a map, the result might be a large LDAP directory access. If the Sun Java System Directory Server is not correctly configured, the refresh operation might time out before completion. To avoid directory server timeouts, modify the following Sun Java System 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 Java System Directory Server with LDAP, see Chapter 11, Setting Up Sun Java System Directory Server With LDAP Clients (Tasks) of this book.

Avoiding Buffer Overruns With Sun Java System Directory Server

To avoid buffer overruns, modify the Sun Java System 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 Java System 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 Java System Directory Server with LDAP, see Chapter 11, Setting Up Sun Java System Directory Server With LDAP Clients (Tasks).

NIS-to-LDAP 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.

NIS-to-LDAP Troubleshooting

This section covers two areas of troubleshooting:

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

Invalid DN Syntax

Object class violation

Can't contact LDAP server

Timeout

NIS-to-LDAP 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

NIS Daemon Exits at Startup

Unexpected Results From NIS Operations

Processing Order of NIS Maps


Note –

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

N2L Lock File Issue

N2L Deadlock Issue

Reverting to NIS

A site that has transitioned from NIS to LDAP using the N2L service is expected to 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.


Tip –

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.


ProcedureHow to Revert to Maps Based on Old Source Files

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Stop the NIS daemons.


    # svcadm disable network/nis/server:default
    
  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. Start the NIS daemons.


    # svcadm enable network/nis/server:default
    

ProcedureHow to Revert to Maps Based on Current DIT Contents

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

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Stop the NIS daemons.


    # svcadm disable network/nis/server:default
    
  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. Start the NIS daemons.


    # svcadm enable network/nis/server:default