The LDAP naming service can use the DIT only if it is structured in a certain way. If required you can use SSDs to enable the LDAP naming service to search in locations other than the default location. Additionally, you can define attributes and object classes in place of the ones specified by the default schema. Use the ldaplist -v command to list the default filters.
If you use schema mapping, you must make sure that the syntax of the mapped attribute is consistent with the attribute it is mapped to. For example, the single-valued attributes must map to single-valued attributes and the attributes must have the same syntax. Also, ensure that the mapped object classes have the correct mandatory attributes.
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, when that service looks for a particular entry, it will search in each base with the specified scope and filter.
In the following example, the LDAP naming service client performs a single-level search in ou=west,dc=example,dc=com followed by a single-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 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
You can also 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.
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 LDAP naming service enables one or more attribute names to be remapped for any of its services. 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.
Consider using schema mappings in situations where 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
You can map the passwd service's gecos attribute to several attributes, as shown in the following example.
attributeMap: gecos=cn sn title
This example maps the gecos values to a space separated list of the cn, sn, and title attribute values.
The LDAP naming service enables 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
If you do not 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 the ldaplist command 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))
The ldaplist command generates the following list of default filters, where %s signifies a string and %d, a number.
hosts (&(objectclass=iphost)(cn=%s)) -------------- passwd (&(objectclass=posixaccount)(uid=%s)) -------------- services (&(objectclass=ipservice)(cn=%s)) -------------- group (&(objectclass=posixgroup)(cn=%s)) -------------- netgroup (&(objectclass=nisnetgroup)(cn=%s)) -------------- networks (&(objectclass=ipnetwork)(ipnetworknumber=%s)) -------------- netmasks (&(objectclass=ipnetwork)(ipnetworknumber=%s)) -------------- rpc (&(objectclass=oncrpc)(cn=%s)) -------------- protocols (&(objectclass=ipprotocol)(cn=%s)) -------------- bootparams (&(objectclass=bootableDevice)(cn=%s)) -------------- ethers (&(objectclass=ieee802Device)(cn=%s)) -------------- publickey (&(objectclass=niskeyobject)(cn=%s)) or (&(objectclass=niskeyobject)(uidnumber=%d)) -------------- aliases (&(objectclass=mailGroup)(cn=%s)) --------------
The following table lists the LDAP filters used in the getXbyY call.
|
The following table lists the getent attribute filters.
|