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.
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.
I’ve got most of this working but I can’t get a user’s groups to come across. Only the primary group is associated with the user on login. Any ideas?
I can’t for the life of me get Workgroup Manager working with my CentOS openldap server. It just can’t or won’t connect. Logs don’t seem to give any clues. Is there something specific in the ldap setup that identifies an OD master as OD instead of LDAP? Is this the problem? I can’t authenticate at all yet so sticking to Apache Directory Studio.