powered by Jive Software

Apple Open Directory lessons 10.6

I apologize if all this has been covered elsewhere…

I’ve spent the last day setting up OpenFire in our Mac environment. I’ve learned a few things that might come in handy for others in my shoes. Some of this I’ve learned from others and I will try to give credit insofar as my notes and memory allow. I hope this helps fellow Mac users get their OpenFire servers up and running more quickly than I did.


Open Directory Server: Mac OS X Server 10.6.3 (MacMini Server)

OpenFire Server: Mac OS X Server 10.5.8 (Intel Xserve)

Clients: Various Mac OS X 10.4.11 - 10.6.3 - iChat

First, I couldn’t stand that OpenFire was using 32bit Java 1.5. It wasn’t honoring my settings in Java Preferences, so I modified /usr/local/openfire/bin/extra/openfire-launchd-wrapper.sh . It wasn’t the first thing I did, but knowing what I know now, I would have done it right after running the install pkg.




$JAVA_HOME/bin/java -server -jar “$OPENFIRE_HOME/lib/startup.jar” -Dopenfire.lib.dir=/usr/local/openfire/lib&

(Credit to Wolf Gilbert : Link to thread)

I did the basics when running through the initial setup:

Language= English

Domain= The FQDN of the server (automatically entered)

Admin Console ports=

Database= Embedded

Profile Settings= Directory Server (LDAP)

LDAP Server…

Server Type= OpenLDAP

Host= The FQDN of my Open Directory server

Port= 636

Base DN= dc=subdomain,dc=domain,dc=lan (obviously, you’ll put your base dn here)

Authentication: I don’t believe this is necessary for OD.

Advanced Settings= Enable ‘Use SSL’

User Mapping…

Username Field= uid

Advanced Settings…

Search Fields=

User Filter= (&(uid={0})(apple-imhandle=Jabber*)) <— I’ll explain this later. If you need to add this after the initial setup do the following:

From the web admin console:

Path: Server:Server Manager:System Properties:

Property Name= ldap.searchFilter

Property Value= (&(uid={0})(apple-imhandle=Jabber*))

IMPORTANT: Before you continue, add a Jabber address to the Open Directory user that will be administering OpenFire. This is easily done in Workgroup Manager under the Info tab. In the Chat field, add a record, and select ‘Jabber’ from the popup menu. If you don’t do this, the above user filter will keep your admin user from registering.

User Profiles (vCard)=

Group Mapping…

Group Field= apple-group-realname

Member Field= memberUid

Description Field= description

Advanced Settings…

Posix Mode= Yes

Continuing to the Admin Console, I did the following…

  1. In System Properties, I added

Property Name= sasl.mechs

Property Value= CRAM-MD5

which allowed my iChat clients to send their passwords securely.

  1. Under Users/Groups:Groups:Group Summary, I selected an OD group that contained all my users. I then clicked ‘Enable contact list group sharing,’ named it, clicked ‘Share group…’ and ‘All users.’

Before you click ‘Save,’ take a look at the listed group members. Except for the admin user, they should all be black with a red asterisk. This is the result of the User Filter. Without the user filter, all these users appeared in the shared buddy list AND all could log in. I used the filter because I couldn’t see a way to limit user access by OD group.

Now, if I want to enable a user’s access to OpenFire AND simultaneously add them to the shared buddy list, I just add a Jabber address to their Open Directory account in Workgroup Manager.

My next endeavor will be to get my GoDaddy cert to work. I’ll be checking out this page with high hopes…


Lyle Millander

1 Like

Wow. I had no luck following those instructions for getting GoDaddy certs to work.

I did come up with this solution…

  1. In the web console, go to: Server : Server Settings : Server Certificates

  2. Open your .key file and copy all the text contents (including the BEGIN and END CERTIFICATE markers). Paste the text into the “Content of Private Key File” box.

  3. Open your .crt file and copy all the text contents. Paste the text into the “Content of Certificate file” box.

  4. Open your gd_intermediate.crt file and copy all the text contents. Paste the text into the “Content of Certificate file” box immediately following the existing crt content.

  5. Click ‘save’

OpenFire accepted this and I am now able to both connect with the iChat client and login using the SSL web console. However, when I go back to the Server Certificates page, I see this message:

One or more certificates are missing. Click here to generate self-signed certificates or here to import a signed certificate and its private key.

The certificate IS listed and is marked as CA SIGNED / RSA and Safari lists the cert as valid. I’m not thrilled about the warning message, but I seem to have the results I wanted.

Feedback welcome!


Lyle Millander

1 Like

The next step is to find out why I can’t do iChat to iChat video/audio sessions. When one client invites another, the target doesn’t receive the invitation pop-up.


many thanks for your post which was really helpful, I have my server up and running, connected to OD on the same computer.

Just a question, did you find the solution for audio and video sessions ? I have the same problem, the target nerver receives any invitation…

All the best,


Hi Jerome,

Sorry for the delayed response. I still don’t have 3.6.4 working with OS X iChat’s audio/video chat. I upgraded from 3.6.4 to 3.7.0 on my test server and it DOES work. However, my test server is PPC, running a different version of Java, isn’t using SSL, and is on my LAN with only one IP address.

I hope to run the 3.7.0 upgrade on my live server this weekend. I’m still going through release notes and log files to ensure I’m not going to shoot myself in the foot. So far, there doesn’t appear to be any problems that will affect my deployment.

I’ll post back with the results.

On a related note, running the 3.7.0 upgrade on my test server was fairly painless. Just downloaded the OS X package installer and ran it. I did have some problems with the Preference Pane throwing an error when starting OF. I worked around the pref pane issue by rebooting the server, or executing in the Terminal (from /usr/local/openfire/bin/, may need to be root):

sh openfire.sh

Comparing my configuration before and after, I didn’t see anything that was altered by the upgrade. All my message archives were still intact and searchable. I updated my plug-ins when prompted - again, no issues. If it matters to anyone, I’m happy to list which plug-ins I have.

Hopefully, the upgrade of our production server will be as smooth.



Another update on the base install on OS X with Open Directory:

I saw a bunch of these errors in /var/log/slapd.log on my OD server. The error occurred reliably whenever an iChat user logged into their jabber account.

slap_global_control: unrecognized control: 1.2.840.113556.1.4.473

A Google search on the error indicates that it relates to an inability of the LDAP server to perform server-side sorting of search results. According to this page:

http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ldap-gui de.html

server-side sorting can be disabled by setting the following parameter in the OF config:

  • ldap.clientSideSorting = true

This is easily done in the web terminal:

  1. Click on “Server” tab

  2. Click on “Server Manager” sub tab.

  3. Click on “System Properties”

  4. Scroll to bottom and enter “ldap.clientSideSorting” to the “Property Name” field.

  5. Enter “true” in the “Property Value” field.

  6. Click “Save Property.”

The effect should be immediate. iChat appeared unaffected. It’s likely a good idea to check the list of properties to verify this one isn’t already in the list.

The next slapd.log error I want to tackle is:

connection_read(76): no connection!

I’ll wait until after the 3.7 update in case the error just goes away.



Well, I’m on 3.7 now. A couple of quick follow-up items:

  1. Custom JAVA settings in /usr/local/openfire/bin/extra/openfire-launchd-wrapper.sh were replaced by defaults.

  2. Still seeing connection_read(76): no connection! notices in slapd.log.

  3. Still cannot get iChat to accept video invitation from other users on the LAN.

  4. After the 3.7 update. these entries stopped flooding the OpenFire error.log:

org.jivesoftware.openfire.roster.Roster.(Roster.java:179)] Groups ([All Employees]) include non-existent username (someuser)

  1. Had to visit plug-in tab a couple of times before all the available updates were displayed.

All-in-all, pretty painless update for us (YMMV).

Bizarre stuff. I just set openfire to use Java 1.6. For giggles I tested a LAN-to-LAN video chat invite and it worked. I haven’t changed any other settings since upgrading to 3.7, which is when I last tested video chat and failed.

Off hours I may go back to Java 1.5 to see how video chat behaves.

I’m happy to share my settings if anyone needs to compare. Just note it may take a few days for me to respond.


i know this is an old Post but i was just wondering if you had any

issues with automatic population of ichat clients buddy lists ?

I followed you instructions which worked to a tee, but i seem to need

to restart openfire to get ichat users to see new news i have just added.



Hi Rhet,

The post isn’t so old as I.

To verify your issue, you’re saying that new users added to Open Directory don’t immediately appear in the iChat/Jabber user list?

This issue relates to caching of user lists on the OpenFire server. If you wait long enough, the user changes will ultimately appear. If you do not wish to wait, you may manually clear those caches using the OpenFire web admin interface:

  1. Log into the OpenFire web admin interface (typically https://yourserver.com:9091).

  2. Click on Server / Server Manager / Cache Summary

  3. Place check marks in: Group; Group Metadata Cache; Roster; and User

  4. Click the “Clear Selected” button at the bottom of the list.

If I recall correctly, iChat users may briefly see the chat user list hiccup. Don’t panic if that occurs.

Please note that most of my seeming knowledge comes in the form of wild guesses. So, please follow my advice with caution and take whatever precautions you feel are applicable.

If this does work for you, feel free to respond so that others may benefit from your experience.



I guess while I’m here…

Video and audio chats invites do indeed work for us. However, it only works when both users are on the same LAN segment. With our prior testing, we often had one user on our wireless segment.

I’d wager there’s some way to work around this, but I doubt I’ll be taking the time to play with that.

Hi Lyle,

Worked perfectly.