I have identical symptoms, it appears. I don't have an answer yet, but I do have some more information. And I have a work around that worked for me.
*My Setup:*
• Mac OS X Server 10.6.4 (this was upgraded from 10.5 some time ago)
• iChat Service
• a variety of clients using 10.5/10.6 iChat, Adium, and IM+ on iPhone
• the server's hostname is 'server2.domain.com' (forward and reverse records are present and working)
• there is a CNAME ichat.domain.com that points to serve2.domain.com
• domain.com resolves to the same IP address (A record, without reverse lookup)
• user JID's are 'username@domain.com'
• we have a third-party SSL certificate in place for the CNAME 'ichat.domain.com'
• the iChat Service is configured with our domain name 'domain.com' and the SSL certificate selected
• Federation is enabled (and working, which is cool.)
• this has been working without issues for many months
Problem:
This problem started about 5 days ago, for no reason I can determine. No software had been installed, that I am aware of (although there is another admin who reports that he didn't install anything). The last restart of this server was about one week before this problem occurred, and was necessary to reinstall FileMaker Server (hopefully unrelated to this problem).
iPhone and Adium clients work fine. Some iChat clients work fine, as well. The only clients having this problem are iChat clients, but not all of them; several iChat clients work just fine in both 10.5.8 and 10.6.4. Of the iChat clients that have problems, they are also spread between 10.5.8 and 10.6.4.
iChat clients that have the problem all have one thing in common: the server entered into preferences is 'ichat.domain.com' or 'server2.domain.com'. iChat clients that do NOT have the problem are using 'domain.com'. Note: Adium clients do NOT have the problem, regardless of which hostname we use.
Kerberos authentication works perfectly.
Symptoms:
iChat clients experiencing the problem are asked to prompted to authenticate, even though the password is set in Preferences. Authentication fails. Here is a single event, with entries from two logs:
+iChat Failed Login Attempt+
- The system log shows the error from jabbered:
system.log (filtering for jabberd2/c2s):
10/11/10 4:23:30 PM jabberd/c2s[37607] ODKVerifyClientRequestFixed: Unable to authenticate
- The PasswordServer log shows the authentication attempt:
ApplePasswordServer.Server.log
Oct 11 2010 16:23:30 AUTH2: {0x5216cfda3a7a979c0000000600000006, andrew} WEBDAV-DIGEST authentication failed, SASL error -13 (password incorrect).
*What I've Done*
I have verified that WEBDAV-DIGEST hashes are enabled in Open Directory, and I have reset the password for this account (which ensures that the proper hashes are created/updated in my PasswordServer slot). Furthermore, this same account works fine from Adium (note that the event below actually occurred before the iChat failure logged above):
+Adium Successful Login Attempt+
system.log:
Oct 11 2010 16:19:12 AUTH2: {0x5216cfda3a7a979c0000000600000006, andrew} WEBDAV-DIGEST authentication succeeded.
ApplePasswordServer.Server.log
10/11/10 4:19:12 PM jabberd/c2s[37218] [8] SASL authentication succeeded: mechanism=DIGEST-MD5; authzid=andrew@domain.com, TLS negotiated
I suspected an authreg mismatch, where the chat client was sending the wrong hash. So I checked the c2s.xml file. No errors. I compared my /etc/jabberd/c2s.xml file with several others from 10.6, line by line (using TextWrangler) and found no discrepancies, aside from obvious configuration differences (like the ID, and SSL certificate names).
I disabled SSL and sniffed a session (using tcpflow). The following line appears in all attempts (successful and unsuccessful). This is where the client tells the server which authentication mechanism it will be using:
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="DIGEST-MD5"/>
That's good. And yet for some reason, whenever iChat sends the hash, the Password Server rejects the WEBDAV-DIGEST hash. But when Adium sends it, the Password accepts the WEBDAV-DIGEST.
So I disabled the DIGEST-MD5 authentication mechanism in c2s.xml:
1. Find /etc/jabberd/c2s.xml
2. Open the file for editing (note, you will need root privs)
3. Find the <authreg> section
4. Find the <mechanisms> section under that
5. SKIP the <traditional></traditional> section
6. Find the <sasl> section
7. Comment out the <digest-md5/> mechanism (just like the <anonymous/> mechanism is already)
BEFORE:
<sasl>
<!--
<anonymous/>
-->
<gssapi/>
<plain/>
<digest-md5/>
</sasl>
AFTER:
(I added some notes so that future admins won't be confused.)
<sasl>
<!--
<anonymous/>
-->
<gssapi/>
<plain/>
<!-- Commented out digest-md5 in order to work around a problem -->
<!-- Oct, 11, 2010 - Andrew -->
<!--
<digest-md5/>
-->
</sasl>
Then I restarted the iChat Service. Both iChat and Adium are working great:
Adium Successful Authentication Attempt:
system.log:
10/11/10 5:29:22 PM jabberd/c2s[38182] [18] SASL authentication succeeded: mechanism=PLAIN; authzid=andrew@deeptechinc.com, TLS negotiated
iChat Successful Authentication Attempt:
10/11/10 5:30:40 PM jabberd/c2s[38182] [18] SASL authentication succeeded: mechanism=PLAIN; authzid=andrew@deeptechinc.com, TLS negotiated
+*PLEASE NOTE: This workaround is sufficient for us because we use SSL certificates and either TLS over port 5222 or SSL over port 5223 to encrypt the session. PLAIN authentication without encryption is not secure. I recommend against using this workaround if you are not using SSL.*+
