OpenLDAP Everywhere Revisited
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).
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.
Listing 1. The slapd.conf file includes important settings for running LDAP securely.
# slapd.conf
# schemas to use
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/redhat/autofs.schema
# database definition
database ldbm
suffix "dc=foo,dc=com"
rootdn "cn=Manager,dc=foo,dc=com"
# Cleartext passwords, especially for the rootdn,
# should be avoided. Use strong authentication.
#rootpw secret
rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxx
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass,uid,uidNumber,gidNumber,
memberUid eq
index cn,mail,surname,givenname eq,subinitial
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
# Users can authenticate and change their password
access to attrs=userPassword,sambaNTPassword,
sambaLMPassword
by dn="cn=Manager,dc=foo,dc=com" write
by self write
by anonymous auth
by * none
# All other attributes are readable to everybody
access to *
by self write
by dn="cn=Manager,dc=foo,dc=com" write
by * read
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.
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.
Listing 2. LDAP distinguished names are organized into a tree of organizational units.
+ dc=foo,dc=com |- ou=People Persons | |- ou=contacts,ou=people Email contacts |- ou=Groups System groups |- ou=auto.master Automount master map |- ou=auto.home Automount map |- ou=auto.misc Automount map |- ou=Computers Samba domain members |- cn=NextFreeUnixId Samba Next Free ID |- SambaDomainName Samba domain info object class
We create the top level entries in LDAP Interchange Format (LDIF) and save them to top.ldif, as shown in Listing 3.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Validate an E-Mail Address with PHP, the Right Way
- Technical Support Rep
- Senior Perl Developer
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- Web & UI Developer (JavaScript & j Query)
- Cari Uang
3 min 1 sec ago - user namespaces
2 hours 56 min ago - yea
3 hours 22 min ago - One advantage with VMs
5 hours 50 min ago - about info
6 hours 24 min ago - info
6 hours 25 min ago - info
6 hours 25 min ago - info
6 hours 28 min ago - info
6 hours 29 min ago - abut info
6 hours 30 min ago





Comments
IT IS VERY USEFUL TO SOLVE PROBLEM
GOOD. It was very useful to solve the problem,
Thank you very much
LDBM and RedHat OpenLDAP Version
There are two things wrong with this article:
(1) It shows a setup using the LDBM databse. This is very unfortunate, since LDBM is not "data safe" and will happily corrupt or lose data without informing you. See http://www.openldap.org/faq/data/cache/756.html for more information on the problems with LDBM.
(2) It shows usage of the RedHat distributed version of OpenLDAP. RedHat traditionally does a very poor job of packaging OpenLDAP, and this remains the case to this day. In addition, 2.2.13 is a very old release at this point, on a historic version of OpenLDAP. 2.3 is the current release branch, with 2.3.20 the current stable release. There are at least 2 DOS vulnerabilities in the 2.2.13 OpenLDAP release, as well as hundreds of bugs that were fixed since then.
If you are using RedHat, and want to use OpenLDAP without updating the local RedHat OpenLDAP libraries, I suggest using CDS3 silver, available for *free* from Symas.com. CDS3 is a packaged version of OpenLDAP 2.3 with *additional* features over OpenLDAP.
--Quanah
--
Quanah Gibson-Mount
Product Engineer
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
So long and thanks for all the spam?
We appreciate the spam disguised as useful info, really.
Since CDS silver free
Since CDS silver is a free packaging of OpenLDAP 2.3, I don't see this as spam, any more than me posting to let you know that I provide my own packages of OpenLDAP 2.3
Of course, both Quanah and I have vested interests in recommending that users (1) don't use ldbm, and (2) use 2.3 ... because we both end up helping the unfortunate users who get stuck after following advice like in this article on the openldap-software mailing list.
Since you don't ... well you can say whatever you like about both of these posts and we won't care.
Although you do help people
Although you do help people Buchan and provide great packages, Quanah is more likely to insult people for not paying for support if the post actually makes it to the OpenLDAP list. It is extremely difficult to get any helpful support for OpenLDAP if you're not a guru or the topic is not absolutely, strictly limited to only OpenLDAP of the latest release.
Samba Schema
I can't seem to find Samba Schema mentioned in "include /etc/openldap/schema/samba.schema" line. Can someone explain a little more on whether I really need samba schema and where I can download it? Thanks.
Location of samba schema
In Debian this schema can be found in /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz, you can copy and extract this file into the schema directory. Samba doc's have to be installed of course.
You do need it. Try
You do need it. Try googling for "samba.schema", or on your server "locate samba.schema"
automountMap vs. nisMap
Very useful article. I used their earlier articles as a guide to setting up OpenLDAP in my area, along with ones by Mick Bauer, and I couldn't have done it without them.
I only have one comment: the use of the automountMap objectClass. If you use the migrate_automount.pl script in recent versions of OpenLDAP, it uses the nisMap objectClass and nisMapName to describe automounts. I am not sure if one or the other is deprecated or both are supported.