Integrating Leopard Server With UNIX LDAP
This article will add to Rajeev Karamchedu’s excellent post, “Integrating Mac OS X into Unix LDAP Environment with NFS Home Directories”, only with Leopard Server instead of Tiger. My goals are a bit different from Rajeev’s: I am not interested in automounting home directories with NFS, but rather in augmenting UNIX accounts from Sun’s LDAP directory so that they can be used with Apple’s collaboration services. This information is also relevant for those who are looking for auto-mounting home directories, however.
Rajeev used Tiger server, which has a different apple.schema file from Leopard. It looks like he upgraded his Tiger server to Leopard instead of starting with a clean install of Leopard, so he may not have encountered the same obstacles as those of us who are starting from a non-upgraded Leopard server. The procedure is basically the same, but we need a new schema file (Leopard’s LDAP schema has an additional 400+ lines!), and we’ll need to add some missing attributes to it. Conveniently, I am also integrating with Sun ONE Directory Server 5.2. However, this methodology should apply equally to any LDAPv3 compliant directory server, such as OpenLDAP.
Create the LDAP Schema File
The first step towards integration with the Sun Directory Server is to add the LDAP schema from Leopard. You will find this schema on your Leopard server in
You will note that the script adds five attributes and an objectclass to the top of the file. The first three objects,
Apple accounts support integration with Windows, which is why the Apple server will request the ‘sambaSID’ attribute when it searches your LDAP server for user records. To accommodate this, you will also need to convert the samba.schema file, and append it to the .ldif file for importing.
Assuming that you copied my
$ cd ~
$ chmod +x apple2ldif
$ ./apple2ldif /etc/openldap/schema/apple.schema 92apple.ldif
$ ./apple2ldif /etc/openldap/schema/samba.schema samba.ldif
$ cat samba.ldif >> 92apple.ldif
Import the Schema File
To import the schema file, copy it onto your Solaris (I assume) server, and put it into — as Rajeev pointed out —
It is a good idea to keep a root shell or two open on the server when you are working with the naming service, so switch to root user. It can also be useful to watch the error log while you’re doing this, so in another window/shell, run:
$ sudo bash
# tail -f /var/opt/mps/serverroot/slapd-myserver/logs/errors
Substituting, of course, for the path to the LDAP error log on your server.
Now, restart the LDAP server and cross your fingers:
# /usr/sbin/directoryserver stop
(wait until it is fully stopped)
# /usr/sbin/directoryserver start
If the schema import works, you won’t see any errors on start up. Assuming that schema checking is enabled — as it should be, and as is by default — then if there are problems with the schema file, it will tell you what the problem is, and fail to start. If this happens, remove the 92apple.ldif file from the schema directory, and try again. Fix the problem in the ldif file, let others know about it by posting a comment below, and try again. Good luck!
One problem I encountered was with one replica server that was running Sun DS6 instead of 5.x. This server already had one of the object classes in the 92apple.ldif file. I think it was the
sambaAccount objectclass, but I didn’t write it down (wups). The result was that replication stopped working on this server. Removing the offending object class from the 92apple.ldif file for that server fixed the problem.
In my next post on this topic, I will describe the addition of a new LDAP partition to SunDS, ou=macox (as Rajeev recommends), and the addition of the necessary objects from Leopard server.
April 9th, 2010 at 12:44
Thanks for your article, I’m trying to integrate exactly SUN ONE 5.2, was trying to access to the script to convert the schema to ldif, unfortunately it’s not working, would you mind re-posting it?
Thanks so much.!
April 9th, 2010 at 13:33
Thanks for pointing that out, Carlos. Fixed!
April 13th, 2010 at 12:37
Works great!
Thanks for your help. I had troubles with pwdMustChange from samba.schema since moved to SUN ONE 6.3 and it’s defined for the password policy. Renaming the attribute fixed it.
Also had to remove the altSecurityIdentities from apple-user object class since the attribute it’s not defined.
I’m also automounting NFS home directories everything is good to go!
Carlos.
October 14th, 2010 at 06:56
Brent,
Thanks for the post! I have been searching google for days now and finally came across your instructions. I am attempting the same here at our college but with Snow Leopard server. Do you know if the schema has changed between the two? Also another quick question. Can extending the schema on the Sun side be skipped if we decide just to authenticate against it and just handle MCX on the OD side?
October 16th, 2010 at 13:52
Hi Don,
I don’t know whether the schema has changed in 10.6. The only thing I’ve set up in 10.6 server is Podcast Producer 2, but I will be looking into more of it soon.
I’d highly recommend that you get the PeachPit book, Apple Training Series: Mac OS X Directory Services v10.6. It contains all of the information you’ll need to integrate OD with RFC 2307 LDAP directories, plus a lot of useful tips. For example, if you intend to provide OS X logins to your 3rd party LDAP, a sticking point is the homeDirectory attribute. Apple’s implementation requires that the attribute to which homeDirectory is mapped must support UTF-8 text in XML format.
It sounds like what you’re after is a “magic triangle” configuration. Here is an excerpt from the book describing the magic triangle:
Basically you drag a group from LDAP into a group in OD, using WGM. Then apply OS X preferences to the OD group. However, the book is a little confusing as it says in Chapter 8 that this only works with Active Directory, but in other places refers to augmenting accounts in standard LDAP. So I think the only way to find out is to try it.
Good luck with the project! I’d appreciate it if you could follow up here and let me know how it goes.
Cheers,
Brent
October 16th, 2010 at 14:40
The User Management v10.6 PDF has instructions for setting up augmented user accounts from a 3rd party LDAP server. Page 57-58:
October 18th, 2010 at 09:20
Brent,
I have followed the set up per my Sun’s directory admins instructions where I am now able to to see lists of users from the external directory in WGM. This all looks fine and dandy until I either try to add an external user to an OD group, or try to augment a user record and select an external user.
Actually WGM will crash if I try to augment. If I try to add an external user to an OD group by clicking the members tab for the group and hitting the plus icon then using the globe to select the external DS, I see the list of users but when I drag a user over to the group I get a green plus icon while dragging but when I release the mouse in the members pane that user just never shows up at all.
I was wondering, do I need higher privileges to the external DS other than read only when binding to it? I wouldn’t think that the case but as of now that is all I have and thought that might be an issue.
Thanks,
Don
October 19th, 2010 at 14:35
Hi Don,
The members tab + globe icon is the right way to do it. You don’t need write privileges on the external LDAP server.
Are you running WGM on a client computer instead of on the OS X Server? That is the recommended way to do it for this purpose. Have you tried dragging a group, instead of user records, from the external LDAP into a group on your OD master? Also, in Workgroup Manager, under the Server menu, there is a new option, “New Augmented User Records”. Try that.
The book is ambiguous about support for augmenting user records from external LDAP servers which are not Active Directory or OD. Surely there is away; what’s so special about AD? Kerberos?
Brent
October 20th, 2010 at 07:05
Brent,
Yes I have tried WGM on a client computer as well as the server. I get the same results on both when trying to use the Server menu “New Augmented User Records” where WGM crashes or if I try to use the plus to add LDAP external user to and OD group.
In the testing environment I am connecting to of the Sun Directory there are no groups set for me to test that I can see. Maybe this is part of the problem? I will check with diradmin for the S.D. and see if I don’t have read access to every attribute. Also since we were going to use the external directory to only authenticate and not store data for MCX I did not have him extend his schema.
Is that absolutely necessary if trying to attempt this?
Thanks,
Don
October 20th, 2010 at 11:05
According to the book, it is not necessary to extend the schema to create augmented user records. But then again, the book also mentions that augmented records are only supported with Active Directory.
The best way to figure out what is going wrong is probably to increase the logging verbosity on the Sun DS, and watch the query logs as you try to add users to OD. I bet it’s looking for some authentication related attribute which it’s not finding. Possibly something relating to Kerberos.
Brent
October 20th, 2010 at 13:10
Brent,
I will follow up on that and keep you posted. Thanks!
Don
October 27th, 2010 at 11:30
So to follow up Brent there seems to be an issue between 10.6 compared to 10.5 server. I can create augmented records fine on 10.5 without to much problem. Still looking into what may be the issue on a 10.6 server.
November 2nd, 2010 at 13:18
Brent,
Actually I am finally getting the Sun diradmin to extend his schema just to test out further. I gave him the 92ldif file but he ran into this issue when trying to extend:
Bootstrap config – conn=-1 op=-1 msgId=-1 – System error The entry cn=schema in file /var/Sun/mps/slapd-vorik_test/config/schema/92apple.ldif is invalid (error 21: Invalid syntax) – object class apple-user: Unknown allowed attribute type “altSecurityIdentities”.
Have you come across this at all?
Thanks,
Don
November 2nd, 2010 at 13:30
No, I haven’t. A quick search suggests that the altSecurityIdentities attribute is a Windows attribute, so perhaps your server does not load the Samba schemas…
January 14th, 2011 at 21:28
[...] what would be necessary to make SLS talk to OpenDS, I came across Brent Kearney’s excellent Integrating Leopard Server With UNIX LDAP blog posts. His work is built on top of a previous post by Rajeev Karamchedu that does something [...]