http://www.linuxjournal.com/article/8119
Samba 3 offers new capabilites for a unified directory for all clients.
Get mail, file sharing and more all working together with the latest
software.
Many readers have used our December 2002 article,
“OpenLDAP Everywhere”, to achieve unified login
company-wide. Since then, OpenLDAP and Linux
have progressed. Here, we demonstrate the use of
OpenLDAP as the core directory service for a mixed
environment. The LDAP server provides a shared e-mail
directory, login for Linux and Microsoft Windows
clients, automount of home directories and file
sharing for all clients. A simple mixed environment
used in the examples in this article is shown in (Figure 1).
Figure 1. In the mixed environment, both Linux and
Windows clients use a common LDAP infrastructure.
The LDAP server we discuss was installed using RPM
binary packages and openldap-2.2.13-2 on Fedora
Core 3. The nss_ldap package also is required.
For the most recent source from openldap.org, see
the on-line
Resources. Edit the server configuration
file, /etc/openldap/slapd.conf, as shown in Listing 1.
Lines beginning with whitespace are interpreted
as a continuation of the previous line, so it's
not necessary to use a backslash at the end of a
long line.
The LDAP schema defines object classes and attributes that make up the
directory entries. Red Hat's autofs schema fits our needs and was packaged
with the RPM installation. If you find that you need to add an objectClass
or an attribute to your directory, see the OpenLDAP admin guide.
We use the default database type ldbm. Our example uses the LDAP domain component. So, foo.com becomes dc=foo,dc=com.
The Manager has full write access to LDAP entries. Create the manager's password using /usr/sbin/slappasswd. Paste the encrypted password into the rootpw entry in slapd.conf.
The index lines enhance performance for attributes queried often. Access control restricts access to the userPassword entry. The user and manager may modify the entry. For all other entries, the manager has write access, and everyone else is granted read access.
We use the default database type ldbm. Our example uses the LDAP domain component. So, foo.com becomes dc=foo,dc=com.
The Manager has full write access to LDAP entries. Create the manager's password using /usr/sbin/slappasswd. Paste the encrypted password into the rootpw entry in slapd.conf.
The index lines enhance performance for attributes queried often. Access control restricts access to the userPassword entry. The user and manager may modify the entry. For all other entries, the manager has write access, and everyone else is granted read access.
Each entry in the directory is identified uniquely with a
distinguished name (dn). The dn for foo.com is dn: dc=foo, dc=com.
The organizationalUnit (ou) provides a method for grouping entries. The
directory structure is shown in Listing 2.
We create the top level entries in LDAP Interchange Format (LDIF) and
save them to top.ldif, as shown in Listing 3.
Next, we configure Mozilla Thunderbird to use the new LDAP server
(Figure 2). From the Tools menu in Thunderbird, select Options. In the Composition
tab, select Directory Server, Edit Directories and then
Add. Fill in the Directory Server Properties with:
In the Advanced tab, increase the number of results returned to fit your directory size. For foo.com, we selected 1,000 results.
Test your settings by composing a message to one of your contacts in your LDAP directory. The address should auto-complete as you type. Another test is to search the LDAP directory from within the Thunderbird Mail Address Book. Search in the FOO address book for “Name or Email contains: *”. That should return all of the contacts entries.
The full entry contains attributes that are needed to control account access, as shown in Listing 4. The full entry also includes attributes needed by the Samba configuration that is discussed below.
Verify that /etc/nsswitch.conf has the following entries:
Verify that /etc/ldap.conf has these entries:
Verify that /etc/openldap/ldap.conf has these entries:
Add the top-level entries to the directory with ldapadd:
Then, test your work with an ldapsearch command that retrieves all entries:
ldapadd -x -D 'cn=manager,dc=foo,dc=com' \ -W -f top.ldif
Then, test your work with an ldapsearch command that retrieves all entries:
ldapsearch -x -b 'dc=foo,dc=com'
At this point, we have enough structure in LDAP to put it to real
use. We start by sharing our e-mail contacts. To simplify the process, you may be able to export your e-mail address
book in LDIF format. For example, in Mozilla Thunderbird, you can export
in LDIF from the Tools menu on the Address Book window. You do need to
process the resulting file so it looks like our contacts example below. We
suggest using Perl for the task.
Contacts are identified uniquely by their e-mail addresses. Here is the dn for a contact:
With all of the attributes, the full entry for a contact looks like:
Separate each contact entry with a blank line and save it to a file called contacts.ldif. Add the contacts to the directory with ldapadd:
Then, test with an ldapsearch command, as shown above.
Contacts are identified uniquely by their e-mail addresses. Here is the dn for a contact:
dn: uid=someone@somewhere.com,ou=contacts, ↪ou=people,dc=foo,dc=com.
With all of the attributes, the full entry for a contact looks like:
dn: uid=someone@somewhere.com,ou=contacts, ↪ou=people,dc=foo,dc=com mail: someone@somewhere.com uid: someone@somewhere.com givenName: Someone sn: Youknow cn: Someone Youknow objectClass: person objectClass: top objectClass: inetOrgPerson
Separate each contact entry with a blank line and save it to a file called contacts.ldif. Add the contacts to the directory with ldapadd:
ldapadd -x -D 'cn=manager,dc=foo,dc=com' \ -W -f contacts.ldif
Then, test with an ldapsearch command, as shown above.
Figure 2. To use the company address book, fill in the
information on your server in Thunderbird's Directory
Server Properties.
Name: FOO Server: ldapserver.foo.com base DN: ou=people,dc=foo,dc=com
In the Advanced tab, increase the number of results returned to fit your directory size. For foo.com, we selected 1,000 results.
Test your settings by composing a message to one of your contacts in your LDAP directory. The address should auto-complete as you type. Another test is to search the LDAP directory from within the Thunderbird Mail Address Book. Search in the FOO address book for “Name or Email contains: *”. That should return all of the contacts entries.
By storing user account information in LDAP,
you can use the same user
name and password at any Linux console. To start, you must decide
which user names should be entered in LDAP. Table 1 shows our user scheme
for UID/GIDs.
This user scheme allows for 9,000 LDAP unified login
entries, while also allowing local users and groups that
do not interfere with LDAP UIDs and GIDs. The user
scheme also allows for the accounts required
by the Samba Primary Domain Controller.
Create LDAP User Login Entries
A user login entry is identified by the login name as uid.
Login users are members of ou=people, resulting in this dn:
dn: uid=gomerp,ou=people,dc=foo,dc=com
The full entry contains attributes that are needed to control account access, as shown in Listing 4. The full entry also includes attributes needed by the Samba configuration that is discussed below.
OpenLDAP ships with migration utilities that
can extract the user account information; see
/usr/share/openldap/migration. To convert an existing
/etc/passwd file to LDIF, start by checking migrate_common.ph.
Edit the file to include your domain name, default
base and enable extended schema:
Extract the user account information from /etc/passwd:
Review the resulting LDIF file. You should remove entries for system accounts such as root and for local users' private groups that do not need to appear in LDAP.
Add the user entries to LDAP and test with an ldapsearch command, as discussed above:
Because the login users belong to ou=people, you now may look up their e-mail addresses within your e-mail client.
# Default DNS domain $DEFAULT_MAIL_DOMAIN = "foo.com"; # Default base $DEFAULT_BASE = "dc=foo,dc=com"; # turn this on to support more general object classes # such as person. $EXTENDED_SCHEMA = 1;
Extract the user account information from /etc/passwd:
/usr/share/openldap/migration/migrate_passwd.pl \ /etc/passwd > people.ldif
Review the resulting LDIF file. You should remove entries for system accounts such as root and for local users' private groups that do not need to appear in LDAP.
Add the user entries to LDAP and test with an ldapsearch command, as discussed above:
ldapadd -x -D 'cn=manager,dc=foo,dc=com' -W \ -f people.ldif
Because the login users belong to ou=people, you now may look up their e-mail addresses within your e-mail client.
You need to make a group entry for each group to be shared between
multiple Linux computers. Each user also needs a group entry for the
user private group. A group entry is identified by cn, and each group
belongs to ou=Groups. For example:
A user private group would look like this:
A shared group would look like:
Extract the group information from /etc/group:
Review the resulting LDIF file. You should remove entries for system groups and for local system users that do not need to appear in LDAP.
Add the group entries to LDAP and test with an ldapsearch command:
dn: cn=gomerp,ou=Groups,dc=foo,dc=com
A user private group would look like this:
dn: cn=gomerp,ou=Groups,dc=foo,dc=com
objectclass: posixGroup
objectclass: top
cn: gomerp
userPassword: {crypt}x
gidNumber: 5223
A shared group would look like:
dn: cn=web_dev,ou=Groups,dc=foo,dc=com objectclass: posixGroup objectclass: top cn: web_dev gidNumber: 5019 memberUid: gomerp memberUid: goober memberUid: barneyf
Extract the group information from /etc/group:
/usr/share/openldap/migration/migrate_passwd.pl \ /etc/group > group.ldif
Review the resulting LDIF file. You should remove entries for system groups and for local system users that do not need to appear in LDAP.
Add the group entries to LDAP and test with an ldapsearch command:
ldapadd -x -D 'cn=manager,dc=foo,dc=com' -W \ -f group.ldif
With unified login, users have a single
home directory that is shared by way of the Network File
System (NFS). We host our home directories from
ldapserver.foo.com and share /home, but the file
server and OpenLDAP do not need to run on the same
machine. Details on NFS are outside the scope of
this article, but here is the line from /etc/exports
that works to export home directories:
Linux LDAP clients mount the user's home directory at login, using automount and NFS. The LDAP use of automount is a replacement for NIS (network information service) automount maps. Replace the automount maps for auto.master, auto.home and auto.misc. To do so, we create a new organizational unit for auto.master:
An auto.master entry is identified by cn. The automountInformation attribute instructs automount to look for the map in LDAP:
While we're at it, let's create an auto.master entry for other NFS shared directories:
Create the automount entries in LDIF format, save as auto.master.ldif and add the entries to LDAP:
Next, we create a new organizational unit for auto.home:
A home directory entry is identified by cn:
Create auto.home entries for each user in ldif format, save as auto.home.ldif and add the entries to LDAP:
When automounted from a Linux LDAP client, your home directory, ldapserver.foo.com:/home/gomerp, is mounted on /h/gomerp. Other NFS shares may be entered in LDAP and automounted as needed. The auto.misc organizational unit holds these automount maps, which have the form ou=auto.misc.
We've already created an auto.master entry for /share, as shown above. Now, we create the ou=auto.misc entry:
Create entries for the NFS shares under ou=auto.misc:
Save the entries as auto.misc.ldif and add the entries to LDAP:
When automounted from a Linux LDAP client, your shared directory
bigdisk.foo.com:/data/engineering is mounted on /share/engineering./home *.foo.com(rw)
Linux LDAP clients mount the user's home directory at login, using automount and NFS. The LDAP use of automount is a replacement for NIS (network information service) automount maps. Replace the automount maps for auto.master, auto.home and auto.misc. To do so, we create a new organizational unit for auto.master:
dn: ou=auto.master,dc=foo,dc=com objectClass: top objectClass: automountMap ou: auto.master
An auto.master entry is identified by cn. The automountInformation attribute instructs automount to look for the map in LDAP:
dn: cn=/h,ou=auto.master,dc=foo,dc=com objectClass: automount automountInformation: ldap:ou=auto.home,dc=foo,dc=com cn: /h
While we're at it, let's create an auto.master entry for other NFS shared directories:
dn: cn=/share,ou=auto.master,dc=foo,dc=com objectClass: automount automountInformation: ldap:ou=auto.misc,dc=foo,dc=com cn: /share
Create the automount entries in LDIF format, save as auto.master.ldif and add the entries to LDAP:
ldapadd -x -D 'cn=manager,dc=foo,dc=com' -W -f auto.master.ldif
Next, we create a new organizational unit for auto.home:
dn:ou=auto.home,dc=foo,dc=com objectClass: top objectClass: automountMap ou: auto.home
A home directory entry is identified by cn:
dn: cn=gomerp,ou=auto.home,dc=foo,dc=com objectClass: automount automountInformation: ldapserver.foo.com:/home/gomerp cn: gomerp
Create auto.home entries for each user in ldif format, save as auto.home.ldif and add the entries to LDAP:
ldapadd -x -D 'cn=manager,dc=foo,dc=com' -W \ -f auto.home.ldif
When automounted from a Linux LDAP client, your home directory, ldapserver.foo.com:/home/gomerp, is mounted on /h/gomerp. Other NFS shares may be entered in LDAP and automounted as needed. The auto.misc organizational unit holds these automount maps, which have the form ou=auto.misc.
We've already created an auto.master entry for /share, as shown above. Now, we create the ou=auto.misc entry:
dn:ou=auto.misc,dc=foo,dc=com ou: auto.misc objectClass: top objectClass: automountMap
Create entries for the NFS shares under ou=auto.misc:
dn:cn=redhat,ou=auto.misc,dc=foo,dc=com objectClass: automount automountInformation: bigdisk.foo.com:/pub/redhat cn: redhat dn:cn=engineering,ou=auto.misc,dc=foo,dc=com objectClass: automount automountInformation: bigdisk.foo.com:/data/engineering cn: engineering
Save the entries as auto.misc.ldif and add the entries to LDAP:
ldapadd -x -D 'cn=manager,dc=foo,dc=com' -W -f auto.misc.ldif
Configure the Linux LDAP Client
To begin configuring the Linux LDAP client, you need to install the
name switch service package, nss_ldap. The Red Hat
tool /usr/bin/authconfig is handy for configuring the client. Select
Use LDAP and fill in the fields so that they read Server:
ldapserver.foo.com and Base DN: dc=foo,dc=com. Authconfig writes to these files: /etc/ldap.conf,
/etc/openldap/ldap.conf and /etc/nsswitch.conf.
Verify that /etc/nsswitch.conf has the following entries:
passwd: files ldap shadow: files ldap group: files ldap automount: files ldap
Verify that /etc/ldap.conf has these entries:
host ldapserver.foo.com base dc=foo,dc=com
Verify that /etc/openldap/ldap.conf has these entries:
HOST ldapserver.foo.com BASE dc=foo,dc=com
The user's password and group entries must be removed
from the password and group files on the NFS server
where home directories live. Create backups and then edit
/etc/passwd, /etc/shadow, /etc/group and /etc/gshadow
to remove the LDAP real people entries. In our case,
/etc/passwd should have no accounts left with a UID
from 1000 to 9999.
To test, log in to a Linux LDAP client using an LDAP user name. You should see the appropriate login shell and home directory for the user. To test auto.misc shares, you must access the share by name, for example:
Automount only mounts NFS shares as they are used, so the directory /share/redhat is not visible until it has been accessed.
To test, log in to a Linux LDAP client using an LDAP user name. You should see the appropriate login shell and home directory for the user. To test auto.misc shares, you must access the share by name, for example:
cd /share/redhat
Automount only mounts NFS shares as they are used, so the directory /share/redhat is not visible until it has been accessed.
The main purpose of using Samba and LDAP together is to achieve unified
login for Microsoft Windows clients. What this means to your organization
is a user will be able to log on to your network from any workstation
and have access to all shared folders, files and printers.
The first step to unified login starts by configuring Samba as a primary domain controller (PDC). The full configuration details on how to set up Samba as your PDC are outside the scope of this article. Please visit the Idealx Web site for a great HOWTO (see Resources). The folks at Idealx have made great contributions to the Samba Project, and you should become familiar with their tools if you plan on using Samba.
Assuming you already have experience with setting up Samba domain controllers, this Samba configuration file should get you up and running with our directory example in the article (Listing 5). The full file is available from the Linux Journal FTP site (see Resources).
The first step to unified login starts by configuring Samba as a primary domain controller (PDC). The full configuration details on how to set up Samba as your PDC are outside the scope of this article. Please visit the Idealx Web site for a great HOWTO (see Resources). The folks at Idealx have made great contributions to the Samba Project, and you should become familiar with their tools if you plan on using Samba.
Assuming you already have experience with setting up Samba domain controllers, this Samba configuration file should get you up and running with our directory example in the article (Listing 5). The full file is available from the Linux Journal FTP site (see Resources).
The remaining piece of the puzzle involves setting up LDAP to take
advantage of Samba's advancements made in the past couple of years. This
should be similar to the LDAP setup above, but with updated features added
in for Samba. With the new Samba 3 version, we now are able to store
all Samba account information inside the LDAP directory. This is
beneficial because now all the information is stored in a centralized
location.
One difference in the LDAP/Samba combination setup is
the additional accounts and LDAP entries that need
to be populated for the two to work together. Several well-known Windows
domain user accounts and domain group accounts are required for
your unified login server to function. Special
LDAP OU entries also are required for the server
to store domain account information. Fortunately,
a script called smbldap-populate is available that does all of this for you. This script is part of the
Idealx smbldap-tools package that can aid you in
setting up both your PDC and your Samba Enabled LDAP
directory. Listing 6 is sample output of what you
should see when you run the smbldap-populate script.
If you examine the sample output of this populate script, you should notice
that it has added several new users, groups and OUs to the directory. For
example, the script adds the well-known Domain Admins and Domain Users
groups to the directory. The NT-based versions of Microsoft Windows all
are preconfigured with specific user and group entries. Each one of those has
a relative identifier (RID) associated with it. What this means to LDAP is
the corresponding LDAP user or group entry must be assigned to the
respective RID of the Windows user or group. Using the smbldap-populate
script takes care of making the relation for you. The well-known user
and groups RIDs that are required are:
Aside from the new user and group entries, several new OU entries can provide further domain functionality. The first of these is ou=Computers, which is used to store all machine accounts for member servers and workstations on the domain. Second, the ou=Idmap is used if Samba is being used as a domain member server of a Windows server controlled domain. The last new entry is ou=NextFreeUnixId. This entry is used to defined the next UID and GID available for creating new users and groups.
Name RID ----------------- Domain Admins 512 Domain Users 513 Domain Guests 514
Aside from the new user and group entries, several new OU entries can provide further domain functionality. The first of these is ou=Computers, which is used to store all machine accounts for member servers and workstations on the domain. Second, the ou=Idmap is used if Samba is being used as a domain member server of a Windows server controlled domain. The last new entry is ou=NextFreeUnixId. This entry is used to defined the next UID and GID available for creating new users and groups.
After your LDAP directory is populated and Samba is set up correctly,
you are ready to start adding users and groups to populate your
directory. The Idealx command-line utilities can take care of this job
nicely for you. Some PHP-based directory managers are available that
can be useful here as well. Consider using phpLDAPadmin and/or the LDAP
Account Manager (LAM) to take on this task. Both are helpful, providing
a graphical view of your directory. Each also provides the ability to
view and edit LDAP entries in a user-friendly graphical environment
(Figure 3). The LDAP browser, which is Java-based, is another option
for viewing and editing your directory.
Since the December 2002 article, we have seen much improvement in Samba
with the 3.x releases. Moving to the new version should mean greater
control over accounts and improved group mapping functionality, thus
giving you greater control over your domain.
Congratulations! Your LDAP server is up and running
with shared e-mail contacts, unified login and shared
file storage that is accessible from any client. 
Figure 3. Get a Web view of your directory with phpLDAPadmin.
Figure 1. An Overall View of Core Network Services, Including
LDAP (Note: the image of the hard disk icon in this figure was taken from the Open Icon
Library
Project: 
