Recipe 5.8 Reading the virtusertable via LDAP

Problem

You must configure sendmail to read the virtusertable from an LDAP server.

Solution

On the LDAP server, include the sendmail.schema file in the LDAP configuration and restart LDAP. Recipe 1.3 provides a detailed example of doing this on a system running OpenLDAP.

On the LDAP server, create an LDIF file containing the virtusertable data and use the ldapadd command to add it to the LDAP database. The virtusertable data should be entered as sendmailMTAMap object class type data. The $={VirtHost} class can also be loaded from an LDAP server. Again, the data is first entered into an LDIF file and then added to the LDAP database using ldapadd . The $={VirtHost} data is entered using the sendmailMTAClass object class format.

On the sendmail system, create a configuration that contains a virtusertable FEATURE command that tells sendmail to read the virtusertable via LDAP, and a VIRTUSER_DOMAIN_FILE macro that loads class $={VirtHost} from the LDAP server. Set the confLDAP_CLUSTER define to the LDAP cluster name used in the sendmailMTACluster attribute of the virtusertable LDAP records. The lines that would be added to our sample sendmail configuration are:

 dnl Define the LDAP cluster to which this host belongs define(`confLDAP_CLUSTER', `wrotethebook.com') dnl Read the virtusertable via LDAP FEATURE(`virtusertable', `LDAP') dnl Load $={VirtHost} from the LDAP server VIRTUSER_DOMAIN_FILE(`@LDAP') 

Using Recipe 1.8 as a guide, rebuild and install the sendmail.cf file, then restart sendmail.

Discussion

This recipe illustrates how the virtusertable data is stored in and retrieved from an LDAP server. The details of your configuration will naturally be different, but the configuration concepts will be the same. The examples in this recipe use information from an LDAP server to duplicate the configuration used in Recipe 5.6. Why and how the virtusertable is used, and the role of the $={VirtHost} class, is covered in that recipe.

The LDAP administrator first enters the data into an LDIF file structured in a manner compatible with the sendmail schema. This example uses three of the virtusertable entries from Recipe 5.6 and adds them to the LDAP database:

 #  cat > ldap-virtuser   dn: sendmailMTAMapName=virtuser, dc=wrotethebook, dc=com   objectClass: sendmailMTA   objectClass: sendmailMTAMap   sendmailMTACluster: wrotethebook.com   sendmailMTAMapName: virtuser   dn: sendmailMTAKey=@mall.shop.wrotethebook.org, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com   objectClass: sendmailMTA   objectClass: sendmailMTAMap   objectClass: sendmailMTAMapObject   sendmailMTAMapName: virtuser   sendmailMTACluster: wrotethebook.com   sendmailMTAKey: @mall.shop.wrotethebook.org   sendmailMTAMapValue: pat   dn: sendmailMTAKey=@sales.school.ora.com, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com   objectClass: sendmailMTA   objectClass: sendmailMTAMap   objectClass: sendmailMTAMapObject   sendmailMTAMapName: virtuser   sendmailMTACluster: wrotethebook.com   sendmailMTAKey: @sales.school.ora.com   sendmailMTAMapValue: [e-mail]   dn: sendmailMTAKey=@lodge.hotel.example.com, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com   objectClass: sendmailMTA   objectClass: sendmailMTAMap   objectClass: sendmailMTAMapObject   sendmailMTAMapName: virtuser   sendmailMTACluster: wrotethebook.com   sendmailMTAKey: @lodge.hotel.example.com   sendmailMTAMapValue: [e-mail]   Ctrl-D  #  ldapadd -x -D "cn=Manager,dc=wrotethebook,dc=com" \   > -W -f ldap-virtuser  Enter LDAP Password:  SecretLDAPpassword  adding new entry "sendmailMTAMapName=virtuser, dc=wrotethebook, dc=com" adding new entry "sendmailMTAKey=@mall.shop.wrotethebook.org,  sendmailMTAMapName=virtuser, dc=wrotethebook, dc=com" adding new entry "sendmailMTAKey=@sales.school.ora.com, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com" adding new entry "sendmailMTAKey=@lodge.hotel.example.com,  sendmailMTAMapName=virtuser, dc=wrotethebook, dc=com" 

The virtusertable map name, which is virtuser , is defined in the first entry. Subsequent data entries for that map associate themselves with the map by referencing the map name using the sendmailMTAMapName attribute. virtusertable data are key/value pairs. The key is defined by the sendmailMTAKey attribute, and the return value is defined by the sendmailMTAMapValue attribute. Thus, the following virtusertable entry from Recipe 5.6:

 @mall.shop.wrotethebook.org      pat 

becomes the following record when entered into the LDAP database:

 dn: sendmailMTAKey=@mall.shop.wrotethebook.org, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com objectClass: sendmailMTA objectClass: sendmailMTAMap objectClass: sendmailMTAMapObject sendmailMTAMapName: virtuser sendmailMTACluster: wrotethebook.com sendmailMTAKey: @mall.shop.wrotethebook.org sendmailMTAMapValue: pat 

This recipe also uses LDAP to load class $={VirtHost} . The following example stores the data for the $={VirtHost} class on the LDAP server:

 #  cat > ldap-virtuser-domains   dn: sendmailMTAClassName=VirtHost, dc=wrotethebook, dc=com   objectClass: sendmailMTA   objectClass: sendmailMTAClass   sendmailMTACluster: wrotethebook.com   sendmailMTAClassName: VirtHost   sendmailMTAClassValue: shop.wrotethebook.org   sendmailMTAClassValue: school.ora.com   sendmailMTAClassValue: hotel.example.com   Ctrl-D  #  ldapadd -x -D "cn=Manager,dc=wrotethebook,dc=com" \   > -W -f ldap-virtuser-domains  Enter LDAP Password:  SecretLDAPpassword  adding new entry "sendmailMTAClassName=VirtHost, dc=wrotethebook, dc=com" 

The sendmailMTAClassName attribute identifies the class as VirtHost . ^[5] The individual class values are defined by the sendmailMTAClassValue attributes in the LDAP record. This LDAP record defines the same values as did the virtuser-domains file used in Recipe 5.6.

^[5] Notice that the class name is written without the enclosing curly braces ( {} ).

ldapadd loads the data into the LDAP database. Use ldapsearch to check the data:

 #  ldapsearch -LLL -x '(sendmailMTAMapName=virtuser)' sendmailMTAMapValue  dn: sendmailMTAMapName=virtuser, dc=wrotethebook, dc=com dn: sendmailMTAKey=@mall.shop.wrotethebook.org, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com sendmailMTAMapValue: pat dn: sendmailMTAKey=@sales.school.ora.com, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com sendmailMTAMapValue: [e-mail] dn: sendmailMTAKey=@lodge.hotel.example.com, sendmailMTAMapName=virtuser,  dc=wrotethebook, dc=com sendmailMTAMapValue: [e-mail] #  ldapsearch -LLL -x '(sendmailMTAClassName=VirtHost)' sendmailMTAClassValue  dn: sendmailMTAClassName=VirtHost, dc=wrotethebook, dc=com sendmailMTAClassValue: shop.wrotethebook.org sendmailMTAClassValue: school.ora.com sendmailMTAClassValue: hotel.example.com 

The ldapsearch test shows that the LDAP server is ready for sendmail. If the ldapsearch command on your sendmail system requires -h and -b arguments, those same arguments must be configured for sendmail using the confLDAP_DEFAULT_SPEC define described in Recipe Recipe 5.9.

Now, the sendmail configuration must be modified to make sendmail ready for LDAP. This recipe reimplements Recipe 5.6 in an LDAP environment. It does that by adding the string LDAP (which tells sendmail to read data from LDAP) to the virtusertable FEATURE command. This modification is essential to our goal of reading the virtusertable from an LDAP server, but it is not the only important modification.

Given the specifics of the data loaded into the server, the confLDAP_CLUSTER define is also essential. The cluster name used by sendmail must match the sendmailMTACluster attribute used in the LDAP records. If a cluster name is not defined, sendmail attempts to retrieve LDAP records using the fully qualified hostname of the sendmail host, which only works if the LDAP records have that value set with a sendmailMTAHost attribute.

This recipe also uses the @LDAP string in the VIRTUSER_DOMAIN_FILE macro to load class $={VirtHost} from the LDAP server. This is not specifically required for the goal of reading virtusertable data from an LDAP server, but it is required in order to duplicate Recipe 5.6 configuration, and it illustrates that classes can be loaded from an LDAP server. The point here is not really to duplicate the configuration of Recipe 5.6 ”the point is to demonstrate that any virtusertable configuration can be duplicated using an LDAP server.

After this recipe is installed on the system, a few quick tests show that the LDAP data is now available to sendmail. Here sendmail -bt is used to examine the LDAP data:

 #  sendmail -bt  ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> >  $={VirtHost}  school.ora.com shop.wrotethebook.org hotel.example.com >  /map virtuser @mall.shop.wrotethebook.org  map_lookup: virtuser (@mall.shop.wrotethebook.org) returns pat (0) >  /quit  

The $={VirtHost} command displays the content of the $={VirtHost} class. It shows that the data defined for $={VirtHost} in the LDAP database has been loaded. The /map command is used to search the virtuser map using @mall.shop.wrotethebook.org as the key. The search returns the value pat . This is exactly what is expected given the records added to the LDAP database in this recipe. Clearly, LDAP data is being used for class $={VirtHost} and for the vitrusertable . In fact, the data for any sendmail database and for any sendmail class can be defined centrally through an LDAP server. sendmail treats the data the same, regardless of the source.

See Also

Recipe 5.6 covers the virtusertable and the class $={VirtHost} . The sendmail book covers the VIRTUSER_DOMAIN_FILE macro in Section 4.8.51.2, the virtusertable in Section 4.8.51, and the confLDAP_CLUSTER define in Section 21.9.82. LDAP is covered in the Using LDAP for Aliases, Maps, and Classes section of the cf/README file.