This article is one part in a multi-part series about how to have centralized logins and home directories with Mac OS 10.6 using an Ubuntu 9.10 server, LDAP & Automounter. You can find the parent article here.
Important Note: Unless stated otherwise, all the commands in this procedure should be run as root. To become root from a typical admin user, just type sudo su and enter your password. You can also just stay the regular user and put the word sudo in front of every command. I’m using to a root prompt and that drives me crazy, so I just su to root.
This part of the proess was adapted and updated from this web page.
The web page that I referenced above uses a much simpler approach than others I saw out there. It works by first creating a unix user (using typical Unix commands), then importing it into LDAP. I plan to import other users that are already in /etc/passwd, so this seems like a nice way to do that. I also think it’s pretty straightforward and requires no knowledge of LDAP LDIF syntax. (Works for me!)
1. Create a unix user called testuser1 in a group called testgroup1 by first creating the group, then the user, then setting a passwd.
# groupadd testgroup1
# useradd -g testgroup1 testuser1
# passwd testuser1
2. Create text files of the user and group entries from the password file
# grep testuser1 /etc/passwd >/tmp/testuser1.txt
# grep testgroup1 /etc/group >/tmp/testgroup1.txt
3. Edit the testuser1.txt file and make sure the home directory is set to /home/testuser1.
4. Use the migrationtools (installed above) to convert this unix entry to ldap format. The migration tools are installed into /usr/share/migrationtools
Remember to replace “home” below with whatever you’re using for your domain. (“home” in my example.)
a. Remember the migratiointools package we installed when we installed slapd? Here it comes! (If you didn’t follow that procedure, you can get these tools by typing apt-get install migrationtools.) Now go to the migration tools directory
# cd /usr/share/migrationtools
5. In order for the migration tools to work, you have substitute the padl.com domain with yours. I’m using home.com, so all I have to do is change all references to padl to home. To do that, I ran these commands. (You will have to edit it if you’re using something other than home.com as your domain.)
# sed ‘s/padl/home/g’ migrate_common.ph >mig.tmp
# mv mig.tmp migrate_common.ph
# chmod 644 migrate_common.ph
6. Use the migration tool to create .ldif files from your passwd & group text files
Note: This command must be run from the directory where these tools are located.
# ./migrate_passwd.pl /tmp/testuser1.txt /tmp/testuser1.ldif
# ./migrate_group.pl /tmp/testgroup1.txt /tmp/testgroup1.ldif
7. Import the test group and user into LDAP
# ldapadd -x -D cn=admin,dc=home,dc=com -w 1234 -f /tmp/testgroup1.ldif
# ldapadd -x -D cn=admin,dc=home,dc=com -w 1234 -f /tmp/testuser1.ldif
8. Test that everything went alright.
Run this query again (substituting your values for home and com)
ldapsearch -xLLL -b dc=home,dc=com
In addition to the People and groups organizational units, you should now see the “testuser1” user and the “testgroup1” group.
9. Make sure there is a directory called testuser1 that is owned by testuser1 and testgroup1 in the directory that will be mounted as /home. For example, in my configuration, I’m mounting /biglun/smbhome as /home. Here’s what I did in that directory for this user (on the Ubuntu server).
# cd /biglun/smbhome
# mkdir testuser1
# chmod -R testuser1.testgroup1 testuser1
This tells it to create a directory called testuser1, then assign its owner to be testuser1 and its group to be testgroup1.
You’ve now setup and configured everything to allow Mac OS 10.6 to authenticate against an Ubuntu 9.10 server using LDAP & automounter. Go back to the parent post to see what to do next.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.