See the introduction to this post.

Now I had belsunce and maling configured so that Rebecca and I could log on at either machine and get the same UID and GID for our accounts. Additionally, maling was set up so that users could have NFS home directories. Rebecca’s account was set up to take advantage of this.

The next step is to do away with local accounts on maling altogether (remember that for the moment I’m keeping local details on the laptop; it could be an LDAP secondary I suppose). Users there will authenticate against LDAP instead.

I’m going to deviate a little from the "this is how to do it on the command line" side of things this time because these steps are a bit of a hassle to do at the terminal. You can put the configuration in DHCP, apparently, so maybe there will be further episodes with an easier way of doing this stuff.

And in fact I’m going to deviate a little from the client side altogether. The stuff below will make more sense with the correct Apple schema installed on our LDAP server. Any Mac has the latest schema installed in /etc/openldap/schema/apple.schema which just happens to be the default OpenLDAP schema directory. Copy the schema file into the right place on your LDAP server. Beware that you might need to edit the file to keep slapd happy. Perhaps Apple turn off schema checking because the version on belsunce didn’t actually work. This was because the apple-user objectclass which it defines referenced some attributes which were commented out or defined later in the file (and hence strictly unavailable). After sorting all the objectclass definitions to the end of the file and uncommenting attributes I was able to satisfy slapd. Don’t forget to check your configuration with slaptest!

Back on the client, the first thing to do is to open Directory Access.app and enable LDAPv3. Click the Configure button and authenticate. You’ll need to click New to tell the tool about the new LDAP server. At this point a box pops up for you to enter the server details. With my setup this just hangs forever after entering the LDAP address so I would hit Manual.

You then have the chance to enter a Configuration Name which can be anything. Use your domain name or something. The Server Name or IP Address is the name or IP of the LDAP server. The LDAP Mappings is interesting. Choose RFC2307 for now. You’re prompted for your search base which you should now enter. If you don’t know what to put here you shouldn’t be reading this post.

Click OK and fire up a terminal to see what we’ve done so far.

Readers who’ve been following this series might expect that the details of the server you just added will be visible to dscl. In the output below I’m going to substitute the actual names with the headings from the Directory Access.app configuration to show how they’re mapped.

    $ dscl localhost -read LDAPv3/Server Name or IP Address
    TrustInformation: Anonymous Encryption
    AuthMethod: dsAuthCrypt dsAuthClearText dsAuthNodeNativeCanUseClearText dsAuthNodeNativeCannotUseClearText
    AccountName: No Account Name
    NodePath: LDAPv3 Server Name or IP Address
    ReadOnlyNode: ReadWrite
    RecordType: Groups CertificateAuthorities Mounts Users People
    RealName: Configuration Name

You can now also search for LDAP users. Let’s assume from now on that my LDAPv3 Server Name or IP Address was ldap.iain.cx.

    $ dscl localhost -list /LDAPv3/ldap.iain.cx/Users
    iain
    maling
    ...

These users are, however, not yet accessible to DirectoryService and hence cannot authenticate. Back in Directory Access.app you can select the Authentication pane, set Search to Custom path and Add the NetInfo path /LDAPv3/ldap.iain.cx.

By the way the file changed is /Library/Preferences/DirectoryService/SearchNodeConfig.plist.

After applying the configuration you should be able to see the users.

    $ dscl localhost -read /Search/Users/maling
    cn: maling
    description: Rebecca Ma
    displayName: Rebecca Ma
    gecos: Rebecca Ma
    gidNumber: 100
    homeDirectory: /home/maling
    loginShell: /bin/bash
    objectClass: person inetOrgPerson posixAccount shadowAccount sambaSamAccount
    sn: Ma
    uid: maling
    uidNumber: 314
    AppleMetaNodeLocation: /LDAPv3/ldap.iain.cx
    Comment: Rebecca Ma
    NFSHomeDirectory: /home/maling
    PasswordPlus: ********
    PrimaryGroupID: 100
    RealName: maling
    RecordName: maling
    RecordType: dsRecTypeStandard:Users
    UniqueID: 314
    UserShell: /bin/bash

    $ id maling
    uid=314(maling) gid=100(users) groups=100(users)

This looks mostly OK but if you read Part 2 you might guess what’s bad about the following:

    NFSHomeDirectory: /home/maling

NFSHomeDirectory is actually the local mountpoint, not the server export of the home directory. This isn’t going to work because there is no /home/maling on the Mac.

    ls ~maling
    ls: /home/maling: No such file or directory

The fix for this is to set up an attribute mapping which will translate attributes in the LDAP schema to key names as understood by DirectoryService.

Back in Directory Access.app, Edit the LDAPv3 you added and open the Search & Mappings pane. It should still say Access this LDAPv3 server using RFC2307 (Unix) because no changes have been made.

Below are two columns. On the left, Record Types and Attributes; these are the DirectoryService names for things. On the right, the items Map to their LDAP equivalents.

Expand Users and find NFSHomeDirectory. This maps to homeDirectory in LDAP. Well it shouldn’t do. According to the Apple documentation, the correct attribute in their schema is apple-user-homeDirectory. We Delete homeDirectory from the mapping and Add apple-user-homeDirectory in its stead. Notice that RFC2307 is now Custom after making the change.

Incidentally the file that is edited by playing with this graphical tool is /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist.

Of course we still need to add this information to Rebecca’s user information in LDAP. This means adding the following attributes.

    dn: cn=maling,ou=users,dc=iain,dc=cx
    objectclass: apple-user
    apple-user-homeDirectory: /Network/Servers/files/home/maling

Go back and read Part 2 if you are wondering where I got the path from.

Now things look better.

    $ dscl localhost -read /Search/Users/maling NFSHomeDirectory
    NFSHomeDirectory: /Network/Servers/files/home/maling

Rebecca should be able to log on. But note that the Mac will attempt to verify her password by making a SASL bind to the LDAP server using the CRAM-MD5 mech. This means you need a line in slapd.conf:

    sasl-regexp ^uid=(.*),cn=cram-md5,cn=auth$ cn=$1,ou=users,dc=iain,dc=cx

And since CRAM-MD5 requires a plaintext password in the directory, she needs a userPassword in clear text.

Some more tricks

You can set a user picture in LDAP. This is used in the fast user switching menu and for the default Mail, Address Book and iChat avatar. The picture must be in TIFF format and the attribute to set is apple-user-picture. It should be mapped to the Picture attribute. Because Rebecca had previously set a user picture for her NetInfo account, I was able to copy it from maling:/Library/Caches/com.apple.user501pictureCache.tiff to files:/home/shared/maling.tiff and set:

    dn: cn=maling,ou=users,dc=iain,dc=cx
    apple-user-picture: /Network/Servers/files/home/shared/maling.tiff

Kerberos works more or less out of the box. Copy your UNIX /etc/krb5.conf to /Library/Preferences/edu.mit.Kerberos (the file is called edu.mit.Kerberos). If DNS works the file can be as simple as:

    [libdefaults]
      default_realm = IAIN.CX

And install a server keytab in /etc/krb5.keytab as usual.

sshd works with no changes needed. I haven’t looked at LoginWindow yet (/etc/authorization).

Assuming I get it working, I’ll post about DHCP and LDAP automounts next time.