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).
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).
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.”
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.
LDAP Information Model (entries, object classes, attributes, types, values)
LDAP Naming Model (Directory Information Tree (DIT) structure)
LDAP Functional Model (search parameters: base object (DN), scope, size limit, time limit, filters (browsing indexes for the Sun Java System Directory Server), attribute list)
LDAP Security Model (authentication methods, access control models)
Overall planning and design of an LDAP directory service, including how to plan the data and how to design the DIT, topology, replication, and security
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:
Understanding and Deploying LDAP Directory Services by Timothy A. Howes, Ph.D. and Mark C. Smith
In addition to providing a thorough treatment of LDAP directory services, this book includes useful case studies on deploying LDAP. Examples of deployments include a large university, a large multinational enterprise, and an enterprise with an extranet.
Sun Java System Directory Server Deployment Guide, which is included with the Sun Java Enterprise System documentation
This guide provides a foundation for planning your directory, including directory design, schema design, the directory tree, topology, replication, and security. The last chapter provides sample deployment scenarios to help you plan both simple, smaller-scale deployments and complex worldwide deployments.
Sun Java System Directory Server Administration Guide, which is included with the Sun Java Enterprise System documentation
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.
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 |
LDAP enables you to consolidate information by replacing application-specific databases, which reduces the number of distinct databases to be managed.
LDAP allows data to be shared by different naming services.
LDAP provides a central repository for data.
LDAP allows for more frequent data synchronization between masters and replicas.
LDAP is multi-platform and multi-vendor compatible.
Following are some restrictions associated with LDAP naming services:
Clients prior to Solaris 8 are not supported.
An LDAP server cannot be its own client.
Setting up and managing an LDAP naming services is more complex and requires careful planning.
A NIS client and a Native LDAP client cannot co-exist on the same client machine.
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.
Task |
For Instructions |
---|---|
Confirm that patch is installed |
|
Plan the network model | |
Plan the DIT |
Chapter 10, Planning Requirements for LDAP Naming Services (Tasks) |
Set up replica servers | |
Plan the security model | |
Choose client profiles and default attribute values |
Planning Client Profiles and Default Attribute Values for LDAP |
Plan the 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 | |
Initialize an LDAP client | |
Initialize a client by using profiles | |
Initialize a client manually | |
Uninitialize 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 | |
Customize a client environment |
This chapter covers the following topics.
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 |
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.
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_* |
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.
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.
The serviceSearchDescriptor attribute defines how and where an LDAP naming service client should search for information for a particular service. The serviceSearchDescriptor contains a service name, followed by one or more semicolon-separated base-scope-filter triples. These base-scope-filter triples are used to define searches only for the specific service and are searched in order. If multiple base-scope-filters are specified for a given service, then when that service looks for a particular entry, it will search in each base with the specified scope and filter.
The default location is not searched for a service (database) with an SSD unless it is included in the SSD. Unpredictable behavior will result if multiple SSDs are given for a service.
In the following example, the Solaris LDAP naming service client performs a one-level search in ou=west,dc=example,dc=com followed by a one-level search in ou=east,dc=example,dc=com for the passwd service. To look up the passwd data for a user's username, the default LDAP filter (&(objectClass=posixAccount)(uid=username)) is used for each BaseDN.
serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east, dc=example,dc=com |
In the following example, the Solaris LDAP naming service client would perform a subtree search in ou=west,dc=example,dc=com for the passwd service. To look up the passwd data for user username, the subtree ou=west,dc=example,dc=com would be searched with the LDAP filter (&(fulltimeEmployee=TRUE)(uid=username)).
serviceSearchDescriptor: passwd:ou=west,dc=example, dc=com?sub?fulltimeEmployee=TRUE |
It is also possible to associate multiple containers with a particular service type. 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 |
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.
You want to map attributes in an existing directory server
If you have user names that differ only in case, you must map the uid attribute, which ignores case, to an attribute that does not ignore case
The format for this attribute is service:attribute-name=mapped-attribute-name.
If you want to map more than one attribute for a given service, you can define multiple attributeMap attributes.
In the following example, the employeeName and home attributes would be used whenever the uid and homeDirectory attributes would be used for the passwd service.
attributeMap: passwd:uid=employeeName attributeMap: passwd:homeDirectory=home |
There exists one special case where you can map the passwd service's gecos attribute to several attributes. The following is an example.
attributemap: gecos=cn sn title |
This maps the gecos values to a space separated list of the cn, sn, and title attribute values.
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 |
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.
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. |
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. |
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 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.
Refreshes the client configuration information stored in the profiles on the server and pulls this data from the clients
Maintains a sorted list of active LDAP servers to use
Improves lookup efficiency by caching some common lookup requests submitted by various clients
Improves the efficiency of host lookups
If the enableShadowUpdate switch is set to true, gains access to the configured administrator credential and performs updates to the shadow data.
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.
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.
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 |
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.
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.
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.
Allowing anonymous write to a directory should never be done, as anyone could change information in the DIT to which they have write access, including another user's password, or their own identity.
Sun 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.
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 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 (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.
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.
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.
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.
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.
none
The client does not authenticate to the directory. This is equivalent to the anonymous credential level.
If the client system uses the simple authentication method, it binds to the server by sending the user's password in the clear. The password is thus subject to snooping unless the session is protected by IPsec. The primary advantages of using the simple authentication method are that all directory servers support it and that it is easy to set up.
The client's password is protected during authentication, but the session is not encrypted. Some directory servers, including Sun Java System Directory Server, also support the sasl/digest-MD5 authentication method. The primary advantage of digest-MD5 is that the password does not go over the wire in the clear during authentication and therefore is more secure than the simple authentication method. See RFC 2831 for information on digest-MD5. digest-MD5 is considered an improvement over cram-MD5 for its improved security.
When using sasl/digest-MD5, the authentication is secure, but the session is not protected.
If you are using Sun Java System Directory Server, the password must be stored in the clear in the directory.
sasl/cram-MD5
In this case, the LDAP session is not encrypted, but the client's password is protected during authentication, as authentication is performed by using sasl/cram-MD5.
See RFC 2195 for information on the cram-MD5 authentication method. cram-MD5 is only supported by some directory servers. For instance, Sun Java System Directory Server does not support cram-MD5.
sasl/GSSAPI
This authentication method is used in conjunction with the self credential mode to enable per-user lookups. A per-user nscd assigned to use the client's credentials binds to the directory server using the sasl/GSSAPI method and the client's Kerberos credentials. Access can be controlled in the directory server on a per-user basis.
tls:simple
The client binds using the simple method and the session is encrypted. The password is protected.
tls:sasl/cram-MD5
The LDAP session is encrypted and the client authenticates to the directory server using sasl/cram-MD5.
tls:sasl/digest-MD5
The LDAP session is encrypted and the client authenticates to the directory server using sasl/digest-MD5.
Sun 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 |
The authentication method can be specified for a given service in the serviceAuthenticationMethod attribute. The following services currently support this.
passwd-cmd
This service is used by passwd(1) to change the login password and password attributes.
keyserv
This service is used by the chkey(1) and newkey(1M) utilities to create and change a user's Diffie-Hellman key pair.
pam_ldap
This service is used for authenticating users with pam_ldap(5).
pam_ldap supports account management.
If the service does not have a serviceAuthenticationMethod set, it will default to the value of the authenticationMethod attribute.
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.
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 |
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.
If you have not changed the pam.conf(4) file, pam_unix functionality is enabled by default.
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_unix follows the traditional model of UNIX authentication, as described in the following list.
The client retrieves the user's encrypted password from the name service.
The user is prompted for the user's password.
The user's password is encrypted.
The client compares the two encrypted passwords to determine whether the user should be authenticated.
Additionally, there are two restrictions when using pam_unix.
The password must be stored in UNIX crypt format and not in any other encryption methods, including clear.
The userPassword attribute must be readable by the name service.
For example, if you set the credential level to anonymous, then anyone must be able to read the userPassword attribute. Similarly, if you set the credential level to proxy, then the proxy user must be able to read the userPassword attribute.
pam_unix is not compatible with the sasl authentication method digest-MD5, since Sun 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.
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.
Refer to pam_krb5(5) and the System Administration Guide: Security Services.
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.
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.
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. |
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.
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.
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.
Password aging and expiration notification
Users must change their passwords according to a schedule. A password expires if it is not changed within the time configured. An expired password causes user authentication to fail.
Users see a warning message whenever they log in within the expiration warning period. The message specifies the number of hours or days until the password expires.
Password syntax checking
New passwords must meet the minimum password length requirements. In addition, a password cannot match the value of the uid, cn, sn, or mail attributes in the user's directory entry.
Password in history checking
Users cannot reuse passwords. If a user attempts to change the password to one that was previously used, passwd(1) fails. LDAP administrators can configure the number of passwords kept in the server's history list.
User account lockout
A user account can be locked out after a given number of repeated authentication failures. A user can also be locked out if his account is inactivated by an administrator. Authentication will continue to fail until the account lockout time is passed or the administrator reactivates the account.
The preceding 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.
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 |
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.
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.
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.
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.
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.
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 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.
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.
See the Sun Java System Directory Server (formerly Sun ONE Directory Server) documentation for information about how to choose an appropriate directory suffix.
There are three different strategies to employ when setting up replica servers.
Single-master replication
Floating-master replication
Multi-master replication
Single-master
With single-master replication, only one master server for any given partition or non-partitioned network holds writable copies of directory entries. Any replica servers have read-only copies of the directory entries. While both replicas and masters can perform searches, compares, and bind operations, only the master server can perform write operations.
The potential disadvantage to the single-master replication strategy is that the master server is a single point of failure. If the master server goes down, none of the replicas can process write operations.
Floating-master
The floating-master strategy is similar to the single-master strategy in that there is only one master server with write capabilities at any given time for a given partitioned or non-partitioned network. However, when implementing the floating-master strategy, when the master server goes down, a replica is automatically transformed into a master server by way of an algorithm.
One potential disadvantage to the floating-master replication strategy is that if your network becomes partitioned and replicas on either side of the partition become masters, the process of reconciling the new masters can be very complicated if the network is rejoined.
Multi-master
With multi-master replication, there are multiple master servers with their own read-write copies of the directory entry data. While the multi-master strategy eliminates the problem of having a single point of failure, update conflicts can occur between servers. In other words, if an entry's attribute is modified around the same time on two masters, an update conflict resolution policy, such as “last writer wins,” must be in place.
For information about how to set up replica servers, refer to the Administration Guide for the version of Sun Java System Directory Server that you are using.
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.
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 |
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.
Will you use Kerberos and per-user authentication?
What credential level and authentication methods will LDAP clients use?
Will you use TLS?
Do you need to be backward compatible with NIS? In other words, will clients use pam_unix or pam_ldap?
What will the servers' passwordStorageScheme attribute settings be?
How will you set up the Access Control Information?
For more information about ACIs, consult the Administration Guide for the version of Sun Java System Directory Server that you are using.
Will clients use pam_unix or pam_ldap to perform account management?
By going through the previous planning steps (network model, DIT, and security model), you should have some idea of the values for the following profile attributes.
cn
defaultServerList
preferredServerList
bindTimeLimit
searchTimeLimit
profileTTL
defaultSearchBase
defaultSearchScope
serviceSearchDescriptor
attributeMap
objectclassMap
followReferrals
credentialLevel
authenticationMethod
serviceCredentialLevel
serviceAuthenticationMethod
Of the preceding attributes, only cn, defaultServerList, and defaultSearchBase are required. They have no default values. The rest are optional, and some have default values.
See Chapter 12, Setting Up LDAP Clients (Tasks) for more information about setting up LDAP clients.
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:
passwd database followed by shadow database
networks database followed by netmasks database
bootparams database followed by ethers database
Note that when adding automounter entries, the database name is in the form of auto_* (for example, auto_home).
If you have /etc files from different hosts to add to the LDAP server, you can either merge all of them into the same /etc file and then use ldapaddent on one host to add the files, or perform ldapaddent on the different hosts one by one, with the expectation that each host is already configured as a LDAP client.
If your naming service data is already in an NIS server, and you want to move the data to the LDAP server for LDAP naming services, use the ypcat (or niscat) command to dump the NIS map into files. Then, run ldapaddent against these files to add the data to the LDAP server.
ldapaddent can only be run on an LDAP client.
The following procedure assumes that the tables are to be extracted from a yp client.
Make sure that Sun Java System Directory Server was set up using idsconfig.
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.
Make the machine an LDAP client.
# ldapclient init -a profileName=new -a domainName=west.example.com \ 192.168.0.1 |
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.
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.
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.
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
Using Service Search Descriptors to Modify Client Access to Various Services
Configuring the Directory Server to Enable Account Management
During the server installation process, you will have defined crucial variables, with which you should create a checklist similar to the one below before launching idsconfig. You can use the blank checklist provided in Blank Checklists.
The information included below will serve as the basis for all examples that follow in the LDAP related chapters. The example domain is of an widget company, Example, Inc. with stores nationwide. The examples will deal with the West Coast Division, with the domain west.example.com
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- |
If you are using hostnames in defining defaultServerList or preferredServerList, you MUST ensure LDAP is not used for hosts lookup. This means ldap must not be in /etc/nsswitch.conf hosts line.
Client profiles are defined per domain. At least one profile must be defined for a given domain.
idsconfig indexes the following list of attributes for improved performance.
pres,eq,sub
pres,eq,sub
pres,eq,sub
pres,eq
pres,eq
pres,eq
pres,eq
pres,eq
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.
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.
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.
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 |
You do not need special rights to run idsconfig, nor do you need to be an LDAP naming client. Remember to create a checklist as mentioned in Creating a Checklist Based on Your Server Installation in preparation for running idsconfig. You do not have to run idsconfig from a server or an LDAP naming service client machine. You can run idsconfig from any Solaris machine on the network.
idsconfig sends the Directory Manager's password in the clear. If you do not want this to happen, you must run idsconfig on the directory server itself, not on a client.
Make sure the target Sun Java System Directory Server is up and running.
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.
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.
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.
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.
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 |
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.
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.
See ldapaddent(1M). See Chapter 9, LDAP Basic Components and Concepts (Overview) for information about LDAP security and write-access to the directory server.
Use the ldapaddent command to add /etc/passwd entries to the server.
# ldapaddent -D "cn=directory manager" -f /etc/passwd passwd |
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 |
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) |
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.
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.
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
Upload the new profile to the server.
# ldapadd -h 192.168.0.1 -D “cn=directory manager” -f myprofile.ldif |
Account management can be implemented for clients that use pam_ldap and for clients that use pam_unix.
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.
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.
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 |
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.
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. ... |
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.
This chapter describes how to set up a Solaris LDAP naming services client. This chapter covers the following topics:
In order for a Solaris client to use LDAP as a naming service the following needs to be in place.
The client's domain name must be served by the LDAP server
The nsswitch.conf file needs to point to LDAP for the required services
The client needs to be configured with all the given parameters that define its behavior
ldap_cachemgr needs to be running on the client
At least one server for which a client is configured must be up and running
The ldapclient utility is the key to setting up an LDAP client, as it performs all of the above steps, except for starting the server. The rest of this chapter will show examples of how to use the ldapclient utility to set up an LDAP client and use the various other LDAP utilities to get information about, and check the status of, an LDAP client.
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.
Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command.
Temporarily disabling a service by using the -t option provides some protection for the service configuration. If the service is disabled with the -t option, the original settings would be restored for the service after a reboot. If the service is disabled without -t, the service will remain disabled after reboot.
The Fault Managed Resource Identifier (FMRI) for the LDAP client service is svc:/network/ldap/client:<instance>.
You can query the status of the LDAP client and ldap_cachemgr by using the svcs command.
Example of svcs command and output.
# svcs \*ldap\* STATE STIME FMRI online 15:43:46 svc:/network/ldap/client:default |
Example of svcs -l command and output. To get the output shown below, you must use the instance name in the FMRI.
# svcs -l network/ldap/client:default fmri svc:/network/ldap/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 1598 dependency require_all/none file://localhost/var/ldap/ldap_client_file (-) dependency require_all/none svc:/network/initial (online) dependency require_all/none svc:/system/filesystem/minimal (online) |
You can check a daemon's presence by using the ps command.
# ps -e | grep slapd root 23320 1 0 Aug 27 ? 16:30 ./ns-slapd -D \ /usr/iplanet/ds5/slapd-lastrev -i /usr/iplanet/ds5/slapd-lastrev/ root 25367 25353 0 15:35:19 pts/1 0:00 grep slapd |
Do not use the -f option with ps because this option attempts to translate user IDs to names, which causes more naming service lookups that might not succeed.
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.
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.
Profile
At a minimum, you need to specify the server address containing the profile and domain you want to use. If no profile is specified, then the “default” profile is assumed. The server will provide the rest of the required information, except for proxy and certificate database information. If a client's credential level is proxy or proxy anonymous, you must supply the proxy bind DN and password. See Assigning Client Credential Levels for more information.
To enable shadow data update, you must provide the admin credential (adminDN plus adminPassword).
Manual
You configure the profile on the client itself, which means that you define all parameters from the command line. Thus, the profile information is stored in cache files and is never refreshed by the server.
Though you can manually configure clients, it is not recommended. Using the configuration profiles decreases the complexity and cost of managing clients.
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.
Run ldapclient with init.
# ldapclient init \ -a profileName=new \ -a domainName=west.example.com 192.168.0.1 System successfully configured |
Do not edit either of the client configuration files directly. Use the ldapclient command to create or modify the content of these files.
Before you set up a client with per-user credentials the following items must already be configured:
One or more Kerberos KDC servers must be configured and running.
DNS, client access to a DNS server, and at least one DNS server, must be configured and running.
Kerberos on the client machine must be configured and enabled.
A Kerberos client installation profile must exist. Such a profile might be:
# cat /usr/tmp/krb5.profile REALM SPARKS.COM KDC kdc.example.com ADMIN super/admin FILEPATH /usr/tmp/krb5.conf NFS 1 DNSLOOKUP none |
The LDAP server must be installed and configured to support the sasl/GSSAPI.
Appropriate identity mapping configurations must exist.
Kerberos host principals for the directory server and the KDC must be set up in the KDC.
idsconfig must have been run on the directory server DIT to be used.
An appropriate per-user gssapi profile (such as gssapi_EXAMPLE.COM) must have been created.
An illustration of a per-user profile in idsconfig is shown in the following partial example:
# /usr/lib/ldap/idsconfig Do you wish to continue with server setup (y/n/h)? [n] y Enter the iPlanet Directory Server's (iDS) hostname to setup: kdc.example.com Enter the port number for iDS (h=help): [389] <Enter your port> Enter the directory manager DN: [cn=Directory Manager] <Enter your DN> Enter passwd for cn=Directory Manager : <Enter your password> Enter the domainname to be served (h=help): [example.com] <Enter your domain> Enter LDAP Base DN (h=help): [dc=example,dc=com] <Enter your DN> GSSAPI is supported. Do you want to set up gssapi:(y/n) [n] y Enter Kerberos Realm: [EXAMPLE.COM] EXAMPLE.COM |
In addition, for a gssapi profile, you must supply a credential level of 4 self and the authentication method of 6 sasl/GSSAPI.
The necessary user principals must exist in the Key Distribution Center (KDC).
On the client machine, Kerberos must be initialized using the client profile with a command such as:
# /usr/sbin/kclient -p /usr/tmp/krb5.profile |
/etc/nsswitch.ldap must be configured to use dns for hosts and ipnodes. Modify this file with an editor as necessary, as in the following:
host: files dns ipnodes: files dns |
/etc/resolv.conf must be configured and the dns service must be running. See the DNS chapters in this document for details.
The directory server DIT must be pre-loaded with (at a minimum) the users of this client machine, the client host and necessary auto_home LDAP entries. See other sections of this manual for details on how to add entries using ldapaddent.
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 |
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.
If the syslog has messages: libsldap: Status: 7 Mesg: openConnection: GSSAPI bind failed - 82 Local error, it is likely that Kerberos is not initialized or its ticket is expired. Run klist to browse it. Run kinit -p foo or kinit -R -p foo and try again.
If you want to, you can add pam_krb5.so.1 to /etc/pam.conf so it will automatically kinit when you log in.
For example:
login auth optional pam_krb5.so.1 rlogin auth optional pam_krb5.so.1 other auth optional pam_krb5.so.1 |
If a user is kinited and the syslog message indicates Invalid credential, then the problem could be the host entry (root) or user entry is not in LDAP directory or mapping rules are not correct.
When ldapclient init is executed, it makes some checks if the LDAP profile contains self/ sasl/GSSAPI configuration. If it fails at /etc/nsswitch.ldap check, then the usual reason is that dns was not added to host: and ipnodes:.
If it fails because the DNS client not enabled, run svcs -l dns/client to see if /etc/resolv.conf is missing or it is just disabled. Run svcadm enable dns/client to enable it.
If the check fails because of sasl/GSSAPI bind, check syslog to find out what went wrong.
See other references in this guide and in the System Administration Guide: Security Services for details.
Do not edit either of the client configuration files directly. Use ldapclient to create or modify the content of these files.
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.
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.
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.
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 |
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 |
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.
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.
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 |
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 |
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.
Use the ldapclient mod command to change the authentication method to simple.
# ldapclient mod -a authenticationMethod=simple |
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 |
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.
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.
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.
Use ldapclient uninit.
# ldapclient uninit System successfully recovered |
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.
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 |
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.
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.
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.
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.
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 |
The binding control flag
Using the binding control flag allows a local password override of a remote (LDAP) password. For example, if a user account is found on both the local files and the LDAP namespace, the password associated with the local account takes precedence over the remote password. Thus, if the local password expires, authentication fails even if the remote LDAP password is still valid.
The server_policy option
The server_policy option instructs pam_unix_auth, pam_unix_account, and pam_passwd_auth to ignore a user found in the LDAP namespace and to allow pam_ldap to perform authentication or account validation. In the case of pam_authtok_store, a new password is passed to the LDAP server without encryption. The password is thereby stored in the directory according to the password encryption scheme configured on the server. For more information, see pam.conf(4) and pam_ldap(5).
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.
ldaplist displays its output with a blank line separating records, which is helpful for big multiline records.
The output of ldaplist depends upon the client configuration. For example, if the value of ns_ldap_search is sub rather than one, ldaplist lists all the entries under the current search baseDN.
The following is 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 |
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 |
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.
You can modify your /etc/nsswitch.conf file to customize where each service gets its information. The default settings are stored in /etc/nsswitch.ldap and ldapclient uses this file to create your /etc/nsswitch.conf file when the client is initialized.
If you want to enable DNS by setting up a /etc/resolv.conf file, 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.
This chapter describes configuration problems and suggests solutions for resolving them.
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.
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.
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.
Use the svcs command.
# svcs \*ldap\* STATE STIME FMRI disabled Aug_24 svc:/network/ldap/client:default |
or
# svcs -l network/ldap/client:default fmri svc:/network/ldap/client:default enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 1598 dependency require_all/none file://localhost/var/ldap/ldap_client_file (-) dependency require_all/none svc:/network/initial (online) dependency require_all/none svc:/system/filesystem/minimal (online) |
Pass the -g option to ldap_cachemgr.
This option provides more extensive status information, which is useful when you diagnose a problem.
# /usr/lib/ldap/ldap_cachemgr -g cachemgr configuration: server debug level 0 server log file "/var/ldap/cachemgr.log" number of calls to ldapcachemgr 19 cachemgr cache data statistics: Configuration refresh information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:43:28 Server information: Previous refresh time: 2001/11/16 18:33:28 Next refresh time: 2001/11/16 18:36:08 server: 192.168.0.0, status: UP server: 192.168.0.1, status: ERROR error message: Can't connect to the LDAP server Cache data information: Maximum cache entries: 256 Number of cache entries: 2 |
For more information about the ldap_cachemgr daemon, see the ldap_cachemgr(1M) man page.
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.
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.
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.
The following sections describe LDAP configuration problems and suggests solutions to the problems.
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.
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.
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:
ldap is not used by the passwd service in the /etc/nsswitch.conf file.
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.
The proxy agent might not have the correct password.
The entry does not have the shadowAccount object class.
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.
No LDAP servers are reachable.
Check the status of the servers.
# /usr/lib/ldap/ldap_cachemgr -g |
pam.conf is configured incorrectly.
The user is not defined in the LDAP namespace.
NS_LDAP_CREDENTIAL_LEVEL is set to anonymous for pam_unix, and userPassword is not available to anonymous users.
The password is not stored in crypt format.
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.
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.
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 failed to initialize the client when using the init option with the profileName attribute specified. Possible reasons for failure include the following:
The incorrect domain name was specified on the command line.
The nisDomain attribute is not set in the DIT to represent the entry point for the specified client domain.
Access control information is not set up properly on the server, thus disallowing anonymous search in the LDAP database.
An incorrect server address passed to the ldapclient command. Use ldapsearch to verify the server address.
An incorrect profile name passed to the ldapclient command. Use ldapsearch to verify the profile name in the DIT.
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 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.
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.
This chapter covers the following topics.
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. |
This section provides information to consider when upgrading from the Solaris 8 release to a Solaris 9 or later release.
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.
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.
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 |
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.
The previously supported use_first_pass and try_first_pass options are obsolete as of the Solaris 10 software release. These options are no longer needed, may safely be removed from pam.conf, and are silently ignored. They may be removed in a future release.
Password prompting must be provided for by stacking pam_authtok_get before pam_ldap in the authentication and password module stacks, and by including pam_passwd_auth in the passwd service auth stack.
The previously supported password update function is replaced in this release by the previously recommended use of pam_authtok_store with the server_policy option.
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.
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.
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.
Tool |
Function |
---|---|
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. |
|
Used to list contents of various services from the directory. |
|
Used to set up Sun Java System Directory Server to serve LDAP naming service clients. |
# # 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. # |
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. # |
Schemas are definitions that describe what types of information can be stored as entries in a server's directory.
For a directory server to support Solaris LDAP naming clients, schemas defined in this chapter must be configured in the server unless schema is mapped using the schema mapping feature of the clients.
There are three required LDAP schemas defined by IETF: the RFC 2307 Network Information Service schema, the LDAP Mailgroups Internet draft, and the LDAP Internet Print Protocol (IPP) draft schema. To support the Naming Information Service, the definition of these schemas must be added to the directory server. The various RFCs can also be accessed on the IETF Web site http://www.ietf.org.
Internet drafts are draft documents valid for a maximum of six months and might be updated, or rendered obsolete, by other documents at any time.
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 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 )) |
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 ) ) |
The schemas required for the Solaris platform are the following.
Solaris Projects schema
Role-based access control and execution profile schemas
Printer schemas
/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 ) ) |
/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 ) ) |
The following sections provide information about the attributes and ObjectClasses for the internet print protocol and the Sun printer.
( 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' ) |
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)) |
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 ) |
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 )) |
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.
Simple paged-mode (RFC 2696)
Virtual List View controls
The server must support at least one of the following authentication methods.
anonymous |
simple |
sasl/cram-MD5 |
sasl/digest-MD5 |
sasl/GSSAPI |
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.
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)) -------------- |
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) |
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.
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:
Import of NIS maps into the LDAP Directory Information Tree (DIT)
Client access to DIT information with the speed and extensibility of NIS
In any naming system, only one source of information can be the authoritative source. In traditional NIS, NIS sources are the authoritative information. When using the N2L service, the source of authoritative data is the LDAP directory. The directory is managed by using directory management tools, as described in Chapter 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:
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.
You need to be familiar with NIS and LDAP concepts, terminology, and IDs to perform the procedures in this chapter. For more information about the NIS and LDAP naming services, see the following sections of this book.
Chapter 4, Network Information Service (NIS) (Overview), for an overview of NIS
Chapter 8, Introduction to LDAP Naming Services (Overview/Reference), for an overview of LDAP
Do not use the N2L service in these situations:
In an environment where there is no plan to share data between NIS and LDAP naming services clients
In such an environment, an N2L server would serve as an excessively complex NIS master server.
In an environment where NIS maps are managed by tools that modify the NIS source files (other than yppasswd)
Regeneration of NIS sources from DIT maps is an imprecise task that requires manual checking of the resulting maps. Once the N2L service is used, regeneration of NIS sources is provided only for backout or reverting to NIS.
In an environment with no NIS clients
In such an environment, use Solaris LDAP naming services clients and their corresponding tools.
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. |
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:
|
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. |
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. |
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.
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). | |
Set up the N2L service. |
Run inityp2l on the NIS master server to set up one of these mappings: |
|
|
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. | |
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. | |
Revert to NIS. |
Revert to NIS using the appropriate map: |
|
|
Maps based on old NIS source files | |
|
Maps based on the current DIT |
Before implementing the N2L service, you must check or complete the following items.
Make sure that the system is set up as a working traditional NIS server before running the inityp2l script to enable N2L mode.
Configure the LDAP directory server on your system.
Sun Java System Directory Server (formerly Sun ONE Directory Server) and compatible versions of directory servers offered by Sun Microsystems, Inc., are supported with the NIS-to-LDAP migration tools. If you use Sun Java System Directory Server, configure the server by using the idsconfig command before you set up the N2L service. For more information about idsconfig, see Chapter 11, Setting Up Sun Java System Directory Server With LDAP Clients (Tasks) and the idsconfig(1M) man page.
Other (third party) LDAP servers might work with the N2L service, but they are not supported by Sun. If you are using an LDAP server other than the Sun Java System Directory Server or compatible Sun servers, you must manually configure the server to support RFC 2307, or its successors', schemas before you set up the N2L service.
Make sure that the nsswitch.conf file lists files before nis for the lookup order, at least for the hosts and ipnodes entries.
Ensure that the addresses of the N2L master server and the LDAP server are present in the hosts or ipnodes files on the N2L master server. Whether the server addresses must be listed in hosts, ipnodes, or both files depends on how your system is configured to resolve local host names.
An alternative solution is to list the LDAP server address, not its host name, in ypserv. This means that the LDAP server address is listed in another place, so changing the address of either the LDAP server or the N2L master server requires additional file modifications.
You can set up the N2L service either by using standard mappings or by using custom mappings, as described in the next two procedures.
As part of the NIS-to -LDAP conversion, you need to run the inityp2l command. This command runs an interactive script for which you must provide configuration information. The following list shows the type of information you need to provide. See the ypserv(1M) man page for explanations of these attributes.
The name of the configuration file being created (default = /etc/default/ypserv)
The DN that stores configuration information in LDAP (default = ypserv)
Preferred server list for mapping data to/from LDAP
Authentication method for mapping data to/from LDAP
Transport Layer Security (TLS) method for mapping data to/from LDAP
Proxy user bind DN to read/write data from/to LDAP
Proxy user password to read/write data from/to LDAP
Timeout value (in seconds) for LDAP bind operation
Timeout value (in seconds) for LDAP search operation
Timeout value (in seconds) for LDAP modify operation
Timeout value (in seconds) for LDAP add operation
Timeout value (in seconds) for LDAP delete operation
Time limit (in seconds) for search operation on LDAP server
Size limit (in bytes) for search operation on LDAP server
Whether N2L should follow LDAP referrals
LDAP retrieval error action, number of retrieval attempts, and timeout (in seconds) between each attempt
Store error action, number of attempts, and timeout (in seconds) between each attempt
Mapping file name
Whether to generate mapping information for auto_direct map
The script places relevant information regarding custom maps at appropriate places in the mapping file.
The naming context
Whether to enable password changes
Whether to change the default TTL values for any map
sasl/cram-md5 authentication is not supported by most LDAP servers, including Sun Java System Directory Server.
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.
Complete the prerequisite steps that are listed in Prerequisites for the NIS-to-LDAP Transition.
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.
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.
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.
Initialize the DIT for the transition from the NIS source files.
Perform these steps only if the DIT has not been fully initialized.
Make sure that the old NIS maps are up-to-date.
# cd /var/yp # make |
For more information, see the ypmake(1M) man page.
Stop the NIS daemons.
# svcadm disable network/nis/server:default |
Copy the old maps to the DIT, then initialize N2L support for the maps.
# ypserv -Ir |
Wait for ypserv to exit.
The original NIS dbm files are not overwritten. You can recover these files, if needed.
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.
Initialize the NIS maps.
Perform these steps only if the DIT is fully initialized and you skipped Step 5.
Stop the NIS daemons.
# svcadm disable network/nis/server:default |
Initialize the NIS maps from information in the DIT.
# ypserv -r |
Wait for ypserv to exit.
The original NIS dbm files are not overwritten. You can recover these files, if needed.
Start the NIS daemons to ensure that they use the new maps.
# svcadm enable network/nis/server:default |
Use this procedure if the following circumstances apply:
You have maps that are not listed in Supported Standard Mappings.
You have standard NIS maps that you want to map to non-RFC 2307 LDAP mappings.
Complete the prerequisite steps that are listed in Prerequisites for the NIS-to-LDAP Transition.
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.
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.
Modify the /var/yp/NISLDAPmapping file.
See Examples of Custom Maps for examples of how to modify the mapping file.
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.
Initialize the DIT for the transition from the NIS source files.
Make sure that the old NIS maps are up-to-date.
# cd /var/yp # make |
For more information, see the ypmake(1M) man page.
Stop the NIS daemons.
# svcadm disable network/nis/server:default |
Copy the old maps to the DIT, then initialize N2L support for the maps.
# ypserv -Ir |
Wait for ypserv to exit.
The original NIS dbm files are not overwritten. You can recover these files, if needed.
Start the NIS daemons to ensure that they use the new maps.
# svcadm enable network/nis/server:default |
Skip Step 7 and continue with Step 8.
Initialize the NIS maps.
Perform this step only if the DIT is fully initialized.
Stop the NIS daemons.
# svcadm disable network/nis/server:default |
Initialize the NIS maps from information in the DIT.
# ypserv -r |
Wait for ypserv to exit.
The original NIS dbm files are not overwritten. You can recover these files, if needed.
Start the NIS daemons to ensure that they use the new maps.
# svcadm enable network/nis/server:default |
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" |
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.
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).
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.
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), ",") |
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.
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.
On the Sun Java System Directory Server: nsslapd-sizelimit attribute must be set greater than or equal to 50000 or -1. See the idsconfig(1M) man page.
On the N2L server: nisLDAPsearchSizelimit attribute must be set greater than or equal to 50000 or zero. For more information, see the NISLDAPmapping(4) man page.
Once VLV indexes have been created, activate them by running directoryserver with the vlvindex option on the Sun Java System Directory Server. See the directoryserver(1M) man page for more information.
Use the Sun Java System Directory Server idsconfig command to set up VLVs if the following conditions apply:
You are using the Sun Java System Directory Server.
You are mapping standard maps to RFC 2307 LDAP entries.
VLVs are domain specific, so each time idsconfig is run, VLVs are created for one NIS domain. Therefore, during the NIS–to–LDAP transition, you must run idsconfig once for each nisLDAPdomainContext attribute included in the NISLDAPmapping file.
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:
You are using the Sun Java System Directory Server.
You have large custom maps or have standard maps that are mapped to nonstandard DIT locations.
To view existing VLV indexes, type the following:
# ldapsearch -h hostname -s sub -b "cn=ldbm database,cn=plugins,cn=config" \ "objectClass=vlvSearch" |
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.
To avoid buffer overruns, modify the Sun Java System Directory Server attributes manually or by running the idsconfig command.
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 |
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).
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.
This section covers two areas of troubleshooting:
Sometimes the N2L server logs errors that relate to internal LDAP problems, resulting in LDAP-related error messages. Although the errors are nonfatal, they indicate problems to investigate. For example, the N2L server might continue to operate, but provide out-of-date or incomplete results.
The following list includes some of the common LDAP error messages that you might encounter when implementing the N2L service. Error descriptions, and possible causes and solutions for the errors, are included.
Administrative limit exceeded
Error Number: 11
Cause: An LDAP search was made that was larger than allowed by the directory server's nsslapd-sizelimit attribute. Only partial information will be returned.
Solution: Increase the value of the nsslapd-sizelimit attribute, or implement a VLV index for the failing search.
Invalid DN Syntax
Error Number: 34
Cause: An attempt has been made to write an LDAP entry with a DN that contains illegal characters. The N2L server attempts to escape illegal characters, such as the + symbol, that are generated in DNs.
Solution: Check the LDAP server error log to find out which illegal DNs were written, then modify the NISLDAPmapping file that generated the illegal DNs.
Object class violation
Error Number: 65
Cause: An attempt has been made to write an LDAP entry that is invalid. Generally, this error is due to missing MUST attributes that can be caused by either of the following circumstances.
Bugs in the NISLDAPmapping file that create entries with missing attributes
Attempts to add an AUXILIARY attribute to an object that does not exist
For example, if a user name has not yet been created from the passwd.byxxx map, an attempt to add auxiliary information to that user will fail.
Solution: For bugs in the NISLDAPmapping file, check what was written in the server error log to determine the nature of the problem.
Can't contact LDAP server
Error Number: 81
Cause: The ypserv file might be incorrectly configured to point to the wrong LDAP directory server. Alternatively, the directory server might not be running.
Solution:
Reconfigure the ypserv file to point to the correct LDAP directory server.
To confirm that the LDAP server is running, become superuser, or assume an equivalent role, on the directory server and type:
# pgrep -l slapd |
Timeout
Error Number: 85
Cause: An LDAP operation timed out, typically while updating a map from the DIT. The map might now contain out-of-date information.
Solution: Increase the nisLDAPxxxTimeout attributes in the ypserv configuration file.
The following problems could occur while running the N2L server. Possible causes and solutions are provided.
The mapping file, NISLDAPmapping, is complex. Many potential errors might cause the mapping to behave in unexpected ways. Use the following techniques to resolve such problems.
Console Message Displays When ypserv -ir (or -Ir) Runs
Problem: A simple message is displayed on the console and the server exits (a detailed description is written to syslog).
Cause: The syntax of the mapping file might be incorrect.
Solution: Check and correct the syntax in the NISLDAPmapping file.
NIS Daemon Exits at Startup
Problem: When ypserv or other NIS daemons run, an LDAP-related error message is logged and the daemon exits.
Cause: The cause might be one of the following:
The LDAP server cannot be contacted.
An entry found in an NIS map or in the DIT is incompatible with the mapping specified.
An attempt to read or write to the LDAP server returns an error.
Solution: Examine the error log on the LDAP server. See the LDAP errors that are listed in Common LDAP Error Messages.
Unexpected Results From NIS Operations
Problem: NIS operations do not return the expected results, but no errors are logged.
Cause: Incorrect entries might exist in the LDAP or NIS maps, which results in mappings not completing as intended.
Solution: Check and correct entries in the LDAP DIT and in the N2L versions of the NIS maps.
Check that the correct entries exist in the LDAP DIT, and correct the entries as needed.
If you are using the Sun Java System Directory Server, start the management console by running directoryserver startconsole.
Check that the N2L versions of the NIS maps in the /var/yp directory contain the expected entries by comparing the newly generated map to the original map. Correct entries as needed.
# cd /var/yp/domainname # makedbm -u test.byname # makedbm -u LDAP_test.byname |
Be aware of the following when checking the output for the maps:
The order of entries might not be the same in both files.
Use the sort command before comparing output.
The use of white space might not be the same in both files.
Use the diff -b command when comparing output.
Processing Order of NIS Maps
Problem: Object class violations occur.
Cause: When the ypserv -i command is run, each NIS map is read and its contents are written into the DIT. Several maps might contribute attributes to the same DIT object. Generally, one map creates most of the object, including all the object's MUST attributes. Other maps contribute additional MAY attributes.
Maps are processed in the same order that nisLDAPobjectDN attributes appear in the NISLDAPmapping file. If maps containing MAY attributes get processed before maps containing MUST attributes, then object class violations occur. See Error 65 in Common LDAP Error Messages for more information about this error.
Solution: Reorder the nisLDAPobjectDN attributes so that maps are processed in the correct order.
As a temporary fix, rerun the ypserv -i command several times. Each time the command is executed, more of the LDAP entry is built up.
Mapping in such a way that all of an object's MUST attributes cannot be created from at least one map is not supported.
Problem: The server times out.
Cause: When the N2L server refreshes a map, the result might be a large LDAP directory access. If the Sun Java System Directory Server is not correctly configured, this operation might time out before completion.
Solution: To avoid directory server timeouts, modify the Sun Java System Directory Server attributes manually or by running the idsconfig command. See Common LDAP Error Messages and NIS-to-LDAP Best Practices With Sun Java System Directory Server for details.
Problem: The ypserv command starts but does not respond to NIS requests.
Cause: The N2L server lock files are not correctly synchronizing access to the NIS maps. This should never happen.
Solution: Type the following commands on the N2L server.
# svcadm disable network/nis/server:default # rm /var/run/yp_maplock /var/run/yp_mapupdate # svcadm enable network/nis/server:default |
Problem: The N2L server deadlocks.
Cause: If the addresses of the N2L master server and the LDAP server are not listed properly in the hosts, ipnodes, or ypserv files, a deadlock might result. See Prerequisites for the NIS-to-LDAP Transition for details about proper address configuration for N2L.
For an example of a deadlock scenario, consider the following sequence of events:
An NIS client tries to look up an IP address.
The N2L server finds that the hosts entry is out-of-date.
The N2L server tries to update the hosts entry from LDAP.
The N2L server gets the name of its LDAP server from ypserv, then does a search by using libldap.
libldap tries to convert the LDAP server's name to an IP address by making a call to the name service switch.
The name service switch might make an NIS call to the N2L server, which deadlocks.
Solution: List the addresses of the N2L master server and the LDAP server in the hosts or ipnodes files on the N2L master server. Whether the server addresses must be listed in hosts, ipnodes, or both files depends on how these files are configured to resolve local host names. Also, check that the hosts and ipnodes entries in the nsswitch.conf file list files before nis in the lookup order.
An alternative solution to this deadlock problem is to list the LDAP server address, not its host name, in the ypserv file. This means that the LDAP server address would be listed in another place. Therefore, changing the address of either the LDAP server or the N2L server would require slightly more effort.
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.
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.
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.
Stop the NIS daemons.
# svcadm disable network/nis/server:default |
Disable N2L.
This command backs up and moves the N2L mapping file.
# mv /var/yp/NISLDAPmapping backup_filename |
Set the NOPUSH environment variable so the new maps are not pushed by ypmake.
# NOPUSH=1 |
Make a new set of NIS maps that are based on the old sources.
# cd /var/yp # make |
(Optional) Remove N2L versions of the NIS maps.
# rm /var/yp/domainname/LDAP_* |
Start the NIS daemons.
# svcadm enable network/nis/server:default |
Back up the old NIS source files before performing this procedure.
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.
Stop the NIS daemons.
# svcadm disable network/nis/server:default |
Update the maps from the DIT.
# ypserv -r |
Wait for ypserv to exit.
Disable N2L.
This command backs up and moves the N2L mapping file.
# mv /var/yp/NISLDAPmapping backup_filename |
Regenerate the NIS source files.
# ypmap2src |
Manually check that regenerated NIS source files have the correct content and structure.
Move the regenerated NIS source files to the appropriate directories.
(Optional) Remove the N2L versions of the mapping files.
# rm /var/yp/domainname/LDAP_* |
Start the NIS daemons.
# svcadm enable network/nis/server:default |