Volume Number: 25
Issue Number: 03
Column Tag: Networking

Integrating OS X With OpenLDAP/Samba, Part 3

Configuring Your Mac To Work With Linux Samba and LDAP Servers

by Noah Gift

In the last two articles, we got familiar with using virtualization to build a Samba /LDAP environment that our Macs could talk to. For many people those two articles would be enough to setup a simple home file sharing and authentication system. And because our Ubuntu virtual machine is just a file, it is simple to keep copies of this configuration laying around in case something goes wrong.

In part two we reached a stopping point after we got basic authentication working with OpenLDAP. In this article we tackle how to fully configure and tweak OS X to work with OpenLDAP, and Samba, including automounting a network home directory via Samba or NFS served out from the virtual machine. It is almost a little too science fiction to talk about without seeing some examples, so I have included quite a few.

In the first two articles, we downloaded a pre-configured Ubuntu virtual machine here: http://examples.oreilly.com/9780596515829/vm/

All of the following steps will be based on the assumption that you have been continuing to work from either this Samba/OpenLDAP server, or a similar one you configured.

OS X has been around for almost a decade, with first version OS X server coming out in 1999. Many Systems Administrators have wrestled with trying to get OS X to behave more like Unix and Linux for all of this time. With 10.4 Tiger, a few changes brought OS X very close to acting like traditional Unix machines, and finally with Leopard becoming POSIX and SUSv3 compliant.

One of the new, and welcome, changes is a working automounting system just like your favorite Unix or Linux system. To demonstrate how useful this is, we are going to go back to our virtual machine to create an NFS exported file system, and then automount it on our Mac.

Step 1: Install NFS on the Ubuntu virtual machine:

sudo apt-get install nfs-kernel

(Note, if you are not familiar with the apt-get command on Ubuntu, it is a package installer, that works a lot like Fink or Mac Ports on the Mac)

Step 2: Add an entry into /etc/exports (again, on the virtualized server)

#directory exported      host(options)
/usr/export         *(rw,sync,insecure)

(Note, we are using * instead of specifying a host or range of IP addresses. This is insecure and exports the volume to the world. This is not recommended unless you are testing a configuration behind a firewall. Also, note that we use the option "insecure". This is because OS X uses a different port than Linux to communicate over NFS. If this option is not set on the server, an OS X client will not be able to mount a NFS volume without a special client side NFS configuration.)

Step 3: Back on the OS X machine, browse to /net/192.168.1.200/usr/export (or whatever the IP address is)

# cd /net/192.168.1.200/usr/export/

This is the beauty of automounting. You simply browse to a hostname/ip address, and the shares just mount. We can see this in action by looking at the output of the df command:

# df -h
Filesystem                  Size   Used  Avail Capacity  Mounted on
/dev/disk0s2                93Gi   81Gi   12Gi    88%    /
devfs                      110Ki  110Ki    0Bi   100%    /dev
fdesc                      1.0Ki  1.0Ki    0Bi   100%    /dev
map -hosts                   0Bi    0Bi    0Bi   100%    /net
map auto_home                0Bi    0Bi    0Bi   100%    /home
trigger                      0Bi    0Bi    0Bi   100%    /net/192.168.1.200/usr
trigger                      0Bi    0Bi    0Bi   100%    /net/192.168.1.200/usr/export
192.168.1.200:/usr/export  2.0Gi  461Mi  1.4Gi    25%    /net/192.168.1.200/usr/export

Step 4: Try to create a file

# touch foo
touch: foo: Permission denied

We get permission denied because NFS uses two levels of security. The first layer of security is host/ip based. We passed that layer of security, and were able to mount the volume. The reason we can't write to the file though, is that owner/group permissions are not set to allow my user account to write. Let's fix this now.

In the last section we were able to setup a NFS server and mount it on our client, but we weren't able to write to it yet because we didn't have proper permission. Let's fix this, by creating a LDAP/Samba User account, and then changing permissions so we write to on when we automount it on the Mac.

Step 1: Use the smbldap-useradd command to create a mactech account

$ sudo smbldap-useradd mactech

Step 2: Use the smbldap-passwd command to set the password

$ sudo smbldap-passwd mactech
Changing UNIX password for mactech
New password: 
Retype new password: 

Step 3: Verify the account works

py4sa@py4sa:~$ su - mactech
Password: 
mactech@py4sa:~$ pwd
/home/mactech
mactech@py4sa:~$ id
uid=30003(mactech) gid=513(Domain Users) groups=513(Domain Users)

This command-line tool creates an account that simultaneously is able to authenticate to Samba, and LDAP. Now, we can go back to our exported volume, and change the ownership to reflect a uid(user id) of 30003, and a gid(group user id) of 513. Note, that the group is called Domain Users, which is a default Samba/LDAP group. All new user accounts get added to this account.

Step 4: Changing ownership of /usr/export to our new mactech user

mactech@py4sa:~$ exit logout py4sa@py4sa:~$ sudo chown -R 30003:513 /usr/export/ [sudo] password for py4sa:

Now, let's test this out on the Mac by changing to our newly created mactech user, and attempting to write to this automounted volume.

Step 5: Authenticating, Mounting, and Writing as an Samba/LDAP user. This takes place on your client OS X machine.

Change to the mactech user:

# su mactech
Password:
bash: /home/mactech/.bashrc: Input/output error

Enter the export directory and set off the automount:

bash-3.2$ cd /net/192.168.1.200/broadcasthost/localhost/
bash-3.2$ cd /net/192.168.1.200/usr/export/

List the contents of the directory:

bash-3.2$ ls
foo

Create a new file in this directory:

bash-3.2$ touch test.txt

No error, so list the contents again:

bash-3.2$ ls -la
total 31
drwxr-xr-x  3 mactech  Domain Users  4096 Nov  5 13:34 .
dr-xr-xr-x  3 root     wheel            2 Nov  5 12:21 ..
-rwxrw-rw-  1 mactech  Domain Users  6148 Oct 14 02:40 .DS_Store
drwxr-xr-x  2 mactech  Domain Users  4096 Oct 14 02:06 foo
-rw-r--r--  1 mactech  Domain Users     0 Nov  5 13:34 test.txt

There are a couple of things to point out. First, our shell complained when we logged into the mactech user, because there is no home directory path that matches /home/mactech on our Mac, like it does on the Ubuntu machine. We are going to fix that in the next section, but for now, if we move past this, we can see that yes, we can create a test file. And, if we look at the permissions, they are set to the username and group that we would expect. Ok, on to fixing the home directory.

In both the last article, and this article, we ran into problems when using LDAP user accounts, because when we created a user account in LDAP on the linux machine, the path to mount the home directory didn't exist on our Macs. In addition, it makes sense that we would want to share common network mounted home directories between the two platforms.

Fortunately, with a little help from symbolic links, it is quite easy to accomplish a cross platform home directory.

Step 1: Create a home directory in /net/192.168.1.200/usr/export/

While still logged in as the mactech user:

$ mkdir -p /net/192.168.1.200/usr/export/home/mactech

Step 2: On the Ubuntu server create symbolic link from /usr/export to /export

py4sa@py4sa:/$ sudo ln -s /usr/export/ /export

This allows us to create a common path to a home directory that we can also symbolically link on the Mac when it is mounted.

Step 3: Change the LDAP record for mactech to reflect the new location

py4sa@py4sa:/$ sudo smbldap-usermod -d /export/home/mactech mactech

Step 4: Create a symbolic link on OS X from the automount directory to /export

# sudo ln -s /net/192.168.1.200/usr/export /export

Step 5: Log in via the command line to the mactech account on OS X to verify it works, and verify the mount point.

# su - mactech
Password:
$
$ pwd
/export/home/mactech
$ df -h
Filesystem                  Size   Used  Avail Capacity  Mounted on
/dev/disk0s2                93Gi   80Gi   13Gi    87%    /
devfs                      111Ki  111Ki    0Bi   100%    /dev
fdesc                      1.0Ki  1.0Ki    0Bi   100%    /dev
map -hosts                   0Bi    0Bi    0Bi   100%    /net
map auto_home                0Bi    0Bi    0Bi   100%    /home
trigger                      0Bi    0Bi    0Bi   100%    /net/192.168.1.200/usr
trigger                      0Bi    0Bi    0Bi   100%    /net/192.168.1.200/usr/export
192.168.1.200:/usr/export  2.0Gi  461Mi  1.4Gi    25%    /net/192.168.1.200/usr/export

Ah, everything works this time. Now, let's make a test file just to be sure.

Step 6: Creating a test file

$ touch mycommondir.txt
$ ls -lan   
total 16
drwxr-xr-x  2 30003  513  4096 Nov  5 14:50 .
drwxr-xr-x  3 30003  513  4096 Nov  5 13:36 ..
-rw-r--r--  1 30003  513     0 Nov  5 15:10 mycommondir.txt

When we login to the Linux machine, we should see this same file and have access to it because the uid/gid are the same between the systems. Before we do that though, let's use fast user switching to login to this NFS mounted network account. After all this is a Mac, not just a command line only Operating System.

Step 7: Use fast user switching to login to the mactech account, and verify it works. (Note, using fast user switching is important because you need to keep your virtual machine running).

Your Mac should take a few seconds, and then you should get a home directory that looks like this:

Figure 1: NFS Mounted Mac Home Directory

What is cool about this, is that it automatically created "Mac stuff" for us, including the Desktop, Pictures, Downloads, and Library folder, yet kept the test file we created mycommondir.txt. Now when you are ready to log out of this account, we can test what happens when we ssh into our virtual machine as the mactech user. Want to guess what we see?

Step 8: ssh into Virtual Machine as mactech user

$ ssh mactech@192.168.1.200
mactech@py4sa:~$ pwd
/export/home/mactech
mactech@py4sa:~$ ls -lan
total 144
drwxr-xr-x  8 30003 513  4096 2008-11-05 15:28 .
drwxr-xr-x  3 30003 513  4096 2008-11-05 13:36 ..
drwx------  2 30003 513  4096 2008-11-05 15:14 Desktop
drwx------  2 30003 513  4096 2008-11-05 15:12 Downloads
-rw-r--r--  1 30003 513  6148 2008-11-05 15:14 .DS_Store
drwx------ 12 30003 513  4096 2008-11-05 15:15 Library
-rw-r--r--  1 30003 513  4096 2008-11-05 15:14 ._mactech_home_dir.png
-rw-r--r--  1 30003 513 98015 2008-11-05 15:14 mactech_home_dir.png
-rw-r--r--  1 30003 513     0 2008-11-05 15:10 mycommondir.txt
drwxr-xr-x  3 30003 513  4096 2008-11-05 15:13 Pictures
drwx------  3 30003 513  4096 2008-11-05 15:12 .Spotlight-V100
drwx------  2 30003 513  4096 2008-11-05 15:28 .ssh
mactech@py4sa:~$ 

Awesome! We have a common NFS mounted home directory that "just works" on OS X and Linux, and we did it all with a virtual machine.

In this third of a four-part series, we created a common NFS mounted home directory by leveraging the power of LDAP, Linux, NFS and the automount daemon. As a result, we now have a recipe for a complete cross platform authentication and network home directories.

Because we used an LDAP/Samba configuration that was configured to work together, we are able to create Samba shares that work with Linux, OS X, or Windows. These could be home directories, and common mount points via Samba, or you could do as we demonstrated in this article, and share out the same directory via Samba and NFS.

The beauty of this configuration is its flexibility, as we can use this one virtual machine to accomplish several different, yet robust configurations. In addition, due to the use of symbolic links, and the automounter, we didn't need to touch LDAP on OS X, other then our initial work in the second article. One thing we didn't cover in detail that bares a mention though, is that NFS requires a thorough understanding of Unix permissions. If you run into problems deploying this in a wider environment, remember to review that you have intentionally configured a proper umask, and group and user permissions. This is the most common problem when first dealing with common NFS home directories for first-timers.

In the final article, we will close the gaps of dealing with LDAP and Samba on OS X. We will briefly talk about OS X's extended attributes and Managed Preferences, and then get into configuring a project management and version control tool, trac, to work with LDAP. We will also briefly talk about how LDAP works with Apache authentication, and how the PHP LDAP admin tool can make dealing with LDAP much easier. Remember, all of this works with the exact same username and password, too, and that is the fun part of setting up centralized authentication.

Noah Gift. "How To Build A Dirt Easy NAS with Samba". Red Hat Magazine, http://www.redhatmagazine.com/2007/06/26/how-to-build-a-dirt-easy-home-nas-server-using-samba/.

Noah Gift and Grig Gheorghiu "LDAP Crud". IBM Developerworks, http://www.ibm.com/developerworks/aix/library/au-ldap_crud/.

Noah Gift. "Getting Started With Open Directory". O'Reilly. http://www.macdevcenter.com/pub/a/mac/2007/06/01/discover-the-power-of-open-directory.html

Noah Gift and Jeremy Jones. "Python For Unix and Linux Systems Administration". O'Reilly . ISBN: 0596515820

Noah Gift has been a Mac user since his family bought a Macintosh Performa 6300 in 1992, and started connected to BBS networks immediately and then eventually the World Wide Web in 1993 when it become open to the public. He is the co-author of "Python For Unix and Linux System Administration" by O'Reilly, and the upcoming "Google App Engine In Action" by Manning.

Noah has a couple of decades of experience in the Television and Film industry starting off as an editor for ABC Network News as a teenager. He contributed to the first feature animated film for Disney Feature Animation and Sony Imageworks. He also had stints at Turner Studios and Caltech, where he worked for the Nobel Prize-winning President as a Mac expert. He has a Master's degree in CIS, and is LPI and ACSA certified. He currently works for WetaDigital in New Zealand. Many of his projects and writing are available at www.noahgift.com. He can be contacted at noah.gift@giftcs.com