OS X and Friends - Linux as a Server

Getting OS X to play nice with directory services hosted by a Linux system.

Part 1 in a series on getting OS X fully integrated with other operating systems. In this part will discuss using Red Hat Fedora Core 6 to host users and passwords for OS X clients.

Since Open Directory on OS X Server is very similar to what we'll be setting up on Red Hat, this is also a rather interesting exercising in how other operating systems handle the need for authentication and to give you a bit more of an idea on what all the Apple-supplied bits do.



These are my notes from doing all of this with Red Hat Fedora Core 6. Other distros might vary some. If you get a "server" distro you might even get GUIs to do some of this. Also, keep in mind that this is an ideal scenario, one where you control the whole piece. In many cases you don't have this luxury at all.

Keep in mind that a lot of the setup on Red Hat is glossed over. It's not hard to do, but it's subtley different with many of the Linux distros, so your mileage may vary.

1. Get yourself a box with OpenLDAP, Cyrus SASL and the MIT KDC.

I used the Fedora package manager to get all the SASL bits and the KDC server bits. Then I downloaded OpenLDAP and compiled by source. That's mostly because I like playing with some of the more recent and intersting bits like LDAP overlays. I imagine you should be able to just use the latest package with it and you should be fine.

2. Set up the LDAP database.

I tend to cheat a lot in this step and just pull a setup database from a working OD server at this point. However, if you're doing this by yourself and don't have an OS X server it will be harder. Google around a bit and you'll find a number of different ldif files to start up a database.

This is the stage where you're going to have to start making some decisions. You can just go plain vanilla Linux, or you can add in the Apple-specific schema to your setup. Using the Apple schema will allow you to fully manage all of the users, as if it was OD. You can even go so far as to use Workgroup Manager.

To add the full schema, you can copy /etc/openldap/schema/apple.schema from any OS X system to the Red Hat box. Then add the schema to your slapd.conf file that you're using for OpenLDAP. Note that for RHFC6 I had to also add the samba.schema files and gently massage the apple.schema file to uncomment the authenticationAuthority attribute, move it early on in the file, and move up an apple-acl attribute to earlier on in the apple.schema file. Then it was all happy.

You'll also want to being setting up the SASL auth options. For SASL to work it needs to be able to take a user's shortname and convert it into the full LDAP DN of the user. For example it needs to turn "mactroll" into "uid=mactroll,ou=users,dc=afp548,dc=com". To do this you can add the SASL regular expressions to slapd.conf.

sasl-regexp
uid=host/(.*),cn=.*,cn=gssapi,cn=auth
"uid=$1,ou=computers,dc=afp548,dc=com"
sasl-regexp
uid=(.*),cn=.*,cn=.*,cn=auth
"uid=$1,ou=users,dc=afp548,dc=com"
sasl-regexp
uid=(.*),cn=.*,cn=auth
"uid=$1,ou=users,dc=afp548,dc=com"

3. Set up your KDC.

Typically on Linux directory servers passwords are kept in the LDAP user record itself. Ideally this is with a SHA hash of the password in the directory. Even better though, is to not put your passwords into LDAP at all. You can leverage the SASL libraries to add full Kerberos functionality to OpenLDAP such that you can require a Kerberos ticket to read the LDAP directory. We'll do that here since it's our dream Linux directory service. Practically though, you need to ensure that all of your network services can handle Kerberos authentication and don't require another password format. The major one to keep in mind here is VPN and mail. Precious few VPN servers allow Kerberos authentication. Most modern mail servers will handle Kerberos, but then you need to decide about other questions such as allowing Kerberos authentication transactions from beyond your firewall.

Before engaging in the next step, ensure that all of your DNS is groovy forward and reverse. Then you can create the KDC database with the kdb5_util command.

/usr/kerberos/sbin/kdb5_util -r YOUR.KERBEROS.REALM -s

Obviously swap out the fake realm in that with your real one.

Then you'll need to use kadmin.local to start populating your KDC's database and then export a keytab. Make sure to create a principle for both "host" and "ldap" for your server. Without this you won't be able to Kerberize OpenLDAP. Here's a decent page from the Red Hat docs about setting up the KDC.

After creating the keytab for the server you'll need to use kadmin.local again to add principles for your users.

Then you'll need to create a /etc/krb5.conf file. It's pretty easy and is essentially just listing your server as your KDC.

Once you've done this you can use kinit to test this from the CLI to make sure it works.

4. Check your time!

This kept killing me when playing with this in Parallels on OS X. It was constantly getting out of whack, so whack it back into shape with /usr/sbin/ntpdate. I won't matter if you're doing all of your testing on the Red Hat box, but as soon as you attempt to involve an OS X client you need the time to be right.

5. Start up OpenLDAP.

You should now be ready to do some testing with all of this. Start up slapd in debug mode (the -d option followed by a high number like -d 99) and see if it yells at you. Get a ticket with kinit and then use ldapsearch against your database, without the -x so you don't just do an anonymous browse. If you get results back you've done a Kerberos auth to OpenLDAP. Using klist you should see that you have a ticket for your LDAP server.

6. Now for OS X.

Using Directory Access on the OS X side you can add your Red Hat LDAP server. I had to do this manually, and I just used the RFC 2307 mappings which works to get you up and running. If you've added in the Apple schema you can use the OD mappings.

For Kerberos to work you'll need to hand create a /Library/Preferences/edu.mit.Kerberos file. This is exactly the same as the /etc/krb5.conf file on the Red Hat box so feel free to cut and paste.

Test things out again. See if you can id a user. Then su to that user. Then attempt a full blown GUI login.

7. Lock it down

If things are still going well you can force Kerberos-only authentication. Right now you're doing a lot of simple binds to the LDAP server. Your passwords are going across in plaintext which is something you don't want. Traditionally you need to do some munging with /etc/authorization on OS X to get Kerberos-only logins, but we can do something slightly sneaky here.

If you set the minimum SASL security options in slapd.conf to Kerberos or better you don't have to touch the OS X client. It works something like this:

• You login to the loginwindow on OS X as an LDAP user.
• OS X looks up your username via LDAP to the Red Hat box.
  
• OS X can't find an authentication authority attribute, so it starts to do a simple LDAP bind to test for authentication.
• OpenLDAP tells OS X that it won't take a simple bind, it has to be Kerberos or better.
• OS X does a kinit on the behalf of the user, gets a Kerberos TGT in the process, then authenticates the user via LDAP with the Kerberos ticket.

The only missing bit is that you won't actually keep the TGT after you've logged in. So if authentication alone is enough, you don't need to go further. Most organizations will want to keep the TGT. To do this you need to add a single line to /etc/authorization.

Look for this line in /etc/authorization

and add this line underneath the "array" section a few lines below that key

Now to lock down your LDAP servers. This is actually pretty easy. In your slapd.conf file you'll need to add this set of directives.

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
by users read
by anonymous auth

sasl-secprops minssf=56

Put them underneath your database definition.

The first block restricts anonymous access to your database. If you just use "disallow bind_anon" it's for all acces to LDAP. The problem is that you want clients to still be able to access your rootDSE which describes things like which authentication methods your database will accept. With the example above you're just limiting access to bits that you care about.

Then the sasl-secprops bit ups your security level a bit so that plaintext binds aren't allowed anymore, forcing the client in Kerberos authentication.

8. Machine accounts.

Just a brief word about machine accounts.

You now need them since you've locked down your LDAP database.

So, set up accounts within a machines ou in your LDAP database. Generate passwords for the machines in your KDC and then use that in Directory Access on the OS X client to authenticate the DirectoryService connection to the LDAP database. Almost exactly like a user account. Then feel free to click all the boxes under the Security Policy heading of the Security tab in the LDAP setup in Directory Access. OS X will use the machine account to get a Kerberos ticket and then use the ticket to encrypt the LDAP traffic. Just like it would with an OD machine account.

9. Replicas...

The one thing this all begins to miss out on is how to alert your client systems to replicas. There's a few options on how to do this.

1. Use a hardware load balancer and cluster LDAP servers behind it. Point the OS X clients to the load balancer's virtual IP and be done with it.
2. If you've fully extended the schema to include the Apple schema you should be able to actually recreate the client config records that Open Directory normally includes to show the clients where the replicas live. I've had mixed success with this, plus it requires a reasonable amount of care and feeding to get it to work.
3. The cheapest and easiest setup is to use the "altServer" directive with OpenLDAP.

Option 1 is something for another article. Option 2 is very involved and only for the strong of heart and LDAP knowledge. However option 3 takes about 3 seconds, so let's talk about that.

The altServer is used by Novell and Sun to describe replicas to their clients, so it's not just Apple using it.

Two simple steps to make this work.

First you need to add a line to your slapd.conf file that points to an LDIF file where the list of replicas will live.

rootDSE /etc/openldap/rootDSE.ldif

Put the file wherever you want. Populate the file with something like this.

dn:
altServer: ldap://10.0.37.108/dc=afp548,dc=com
altServer: ldap://10.0.37.109/dc=afp548,dc=com

That will inform the OS X client that there is a replica at 10.0.37.108 and another one at 10.0.37.109. Once the client is set up for this it should work exactly like an OD replica list would. Just make sure that your edu.mit.kerberos file also lists the other KDCs on your network.

Beer Time!

That should be more than enough to get you dangerous. By no means is the above a full step by step on how to do this. However, each section is easily google-able so you shouldn't have any trouble if you get stuck.

Since many of you will be looking to integrate with an existing LDAP, and hopefully Kerberos, setup pick and choose a bit through these steps to see what applies to you.