Implementation Environment
While this document’s steps are specific to the following products, since all of them are standards-based, only product-specific knowledge would be needed to adopt this methodology to other environments (for e.g. OpenLDAP, Novell etc)
- Directory Server: Sun ONE Directory Server 5.2
- Home Directories: Hosted on a central Network Appliance file server, accessible via NFS
Preparing the Directory Server
Preparing the Directory Server for Apple’s use involves two steps: Extending the Schema and Populating the server with objects. Extending the schema, though it is quite simple a Sun ONE Directory Server or an OpenLDAP server, should only be performed by administrators who understand the DS operations very well and know how to back out the schema if necessary.
Extending the Directory Server Schema
In order for a Mac Server or Workstation to use an LDAP server for authentication and authorization services, it needs to find users, groups, computers, access policies and such data in ldap servers. Apple’s OD uses standard objectclasses such as posixAccount, shadowAccount, posixGroup etc to store and find user, group and computer information. In addition, it uses apple’s native (custom) attributes to store apple-specific information (e.g AFP homedir location, user’s icon, apple’s generated UID etc). The table below provides a list of the objects that Apple uses and the objectclasses they comprise of. For a full list of mappings including the objectclasses and attributes, please consult the Mac OS X Server Open Directory Administration Guide
| LDAP Object Class Name | Schema | |
|---|---|---|
| Users | ||
| inetOrgPerson | RFC 2798 | |
| posixAccount | RFC 2307 | |
| shadowAccount | RFC 2307 | |
| apple-user | Apple Extended Schema | |
| Groups | ||
| posixGroup | RFC 2307 | |
| apple-group | Apple Extended Schema | |
| People | inetOrgPerson | RFC 2798 |
| Mounts | mount | Apple Extended Schema |
| Computer | apple-computer | Apple Extended Schema |
| Computer Lists | apple-computer-list | Apple Extended Schema |
| Config | apple-configuration | Apple Extended Schema |
| Preset Computer Lists | apple-preset-computer-list | Apple Extended Schema |
| Preset Groups | apple-preset-group | Apple Extended Schema |
| Preset Users | apple-preset-user | Apple Extended Schema |
| Printers | ||
| apple-printer | Apple Extended Schema | |
| printerIPP | IETF-Draft-IPP-LDAP | |
| AutoServerSetup | apple-serverassistant-config | Apple Extended Schema |
| Locations | apple-locations | Apple Extended Schema |
There are couple of ways to get this native apple data into our LDAP server.
- Using Unused Attributes
One approach is to employ the unused attributes that are found in LDAP configuration to host this information. However, if the original vendor who is assigned those attributes decides to start using these attributes, then you will risk breaking the implementation and future upgrades can turn messy. Not Recommended
- Import Apple Specific Schema
Extending the LDAP Schema to include apple schema will allow us to store all of the Macintosh data in ldap servers in their own objectclasses and attributes. Schema extensions are a lot easier to perform and maintain in Sun ONE LDAP Servers and OpenLDAP servers than Active Directory. Recommended
In order to realize the full functionality of Work Group Manager, it is best if you extend the LDAP Server with apple schema, which is what we have decided to do.
Note Of Caution: Apple’s schema is a work-in-progress. Apple declares that it may extend the schema to support the future version of Mac OS X and Mac OS X Server. The latest version of the schema can be found in the file
/etc/openldap/schema/apple.schema
of any Mac OS X Server running the latest version of the OS.
The schema file, as it is, however, needs some formatting before it can be imported into Sun ONE Directory Server. The schema files for Directory Server are stored in
ServerRoot/slapd-serverId/config/schema
directory. These schema files are read once at start up time by the DS and are stored in
cn=schema entryduring runtime. The schema files are prefixed by a number and are read in alphanumerical order, since the order in which these schema files are read is critical.
The file
99user.ldif
contains additional ACIs for the DS that may have been added using the console or via the command line. Also note that in a replicated environment, any changes made on the replicas’
99user.ldif
file will be overwritten the next time the schema is replicated from the Master server. Schema modifications must always be made on the master server and they should be stored in separate files. For more information on Extending Sun ONE Directory Server Schema, please consult the Sun ONE Administration Guide.
We will store our apple schema in a file called
92apple.ldif
on the master server. This will ensure that this file will get read before the
99user.ldif
. Also note that on the replica servers, you will NOT find a
92apple.ldif
after performing a schema replication. Instead, all of the new schema should be found merged in
99user.ldif
on the replicas.
Hi Rajeev
Thanks for this tutorial.
I’m very new in MacOS world and we are trying to integrate a couples of iMac into our network.
We are running Sun ONE Directory Server 5.2 and I want to authenticate mac user versus our ladp servers. Are there anything in the Mac side that can parse information from solaris schema to apple.schema? something like “NS_LDAP_SERVICE_SEARCH_DESC” in solaris or “nss_map_attribute” in linux?. I’m a bit afraid to change anything in the schema.
Another thing is I can’t access to this link “http://www.tigr.org/%7Erajeev/92apple_schema.html”
Thanks again
Juan
I used this information to set up an ODS clone on Ubuntu 9.04 using OpenLDAP and was able to access it without problem from my Leopard clients up to 10.5.8. Thanks!
However, a machine that I have upgraded to Snow Leopard (10.6.2) – although able to see the ODS clone – seems to ignore it completely. WGM 10.6.2 won’t let me log in with the credentials which work for Leopard. The shell “id” command doesn’t return any information from the ODS clone.
I presume that Apple has changed the schemas for ODS, though the only change I have been able to identify is the introduction of apple_auxillary.schema. Adding that to my ODS clone has not solved the problem though.
Do you have any insight into what needs to be done to get an ODS clone running for Snow Leopard clients?
Steve
Have not had a chance to experiment with 10.6 for a while but may be this link might be of help.
http://images.apple.com/business/solutions/it/docs/Modifying_the_Active_Directory_Schema.pdf
The link to apple.schema ldif is broken. does anyone have a copy?
Hi,
your article help a lot. But I still encounter some problems. I’m trying to use NFS + Kerberos + LDAP. I’m using OS X 10.5. The LDAP users can login, but they won’t get their home directories. It seams as if the mac system isn’t even trying to mount the NFS share. The Kerberos configuration seams to be fine, because the user gets a valid ticket. Perhaps you could explain the apple-user-homeurl, homeDirectory values. I don’t quiet get it if i need the apple-user-homeurl value for nfs. Is it possible that 10.5 changed the way how you mount the home directory?
Best reagrds,
Ulrich
Greetings. I found this article very informative. The article mentions: “On an OS X Server, we started the Open Directory Server and created one admin user. We then dumped the directory tree contents to a file…”. Would you please email me this file, or post a link to it?
I don’t have access to those files anymore – but something you can do quite easily if you have access to an Open Directory Server.. Just issue a ldapsearch command at the root of the suffix as an admin user..
Here are some example entries that might help you..
apple-user-homeurl:nfs://fas3170.myco.com/vol/homes
/users/rajeev
homeDirectory: /home/rajeev
To understand exactly what the client is requesting from the server, my suggestion is to turn up the debug logging on the OSX LDAP server and watch the access logs.
Rajeev,
Ben is not alone; 10.6 does indeed do nothing when you click “write to server”. I have run tcpdump on the client, and it does not even try to make a network connection. So sadly, I don’t think this works for 10.6, so I’ve had to resort to passing around the .plist configuration to the clients, which kinda stinks. For reference, I use SSL with my configuration and the ACL’s are correct, because if I manually update the mappings on the clients, everything works just fine.