OpenLDAP Everywhere Revisited
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.
Listing 4. A user login entry contains the password information needed to log in, along with Samba configuration.
dn:uid=gomerp,ou=People,dc=foo,dc=com
uid: gomerp
cn: Gomer Pyle
sn: Pyle
givenname: Gomer
mail: gomer.pyle@foo.com
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sambaSAMAccount
uidNumber: 5000
homeDirectory: /h/gomerp
loginShell: /bin/bash
description: Gomer Pyle
displayName: Gomer Pyle
gecos: Gomer Pyle
gidNumber: 513
userPassword: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxx
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
sambaSID: S-1-5-21-1400792368-3813960858-1703501993-11000
sambaPrimaryGroupSID: S-1-5-21-1400792368-3813960858-1703501993-513
sambaLogonScript: gomerp.cmd
sambaHomeDrive: H:
sambaHomePath: \\LDAPSERVER\gomerp
sambaLMPassword: XXXXXXXXXX
sambaAcctFlags: [U]
sambaNTPassword: XXXXXXXXXX
sambaPwdLastSet: 1097240543
sambaPwdMustChange: 1105016543
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:
# 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:
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:
/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
When automounted from a Linux LDAP client, your shared directory bigdisk.foo.com:/data/engineering is mounted on /share/engineering.
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
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Bought photoshop CS5 for developing a website :(
1 hour 31 min ago - What the author describes
2 hours 57 min ago - Reply to comment | Linux Journal
7 hours 7 min ago - Reply to comment | Linux Journal
7 hours 53 min ago - Didn't read
8 hours 3 min ago - Reply to comment | Linux Journal
8 hours 8 min ago - Poul-Henning Kamp: welcome to
10 hours 18 min ago - This has already been done
10 hours 19 min ago - Reply to comment | Linux Journal
11 hours 4 min ago - Welcome to 1998
11 hours 53 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.