We’ve found that Adium and Pidgin work very well with our pilot setup – Openfire server, DNS SRV records so that people can use @stanford.edu Jabber IDs, using TLS on port 5222 and SASL/GSSAPI (Kerberos) authentication. iChat worked fine in the test setup, but doesn’t work on the pilot setup – the main difference being the DNS SRV records.

I spent some time this afternoon trying different settings with iChat, certificates, Kerberos and Openfire, using itlab.stanford.edu and im.itlab.stanford.edu.
Read more »

The following are the instructions for setting up a MS Windows computer to connect to the IT Services test/pilot Jabber Instant Messaging server for the purposes of Group Chat for the IEC (Zimbra) calendar migration effort. Pidgin is an IM client that supports the

• Jabber XMPP protocol
• SSL encryption on the network
• Kerberos authentication

Read more »

The following are the instructions for setting up a Mac to connect to the IT Services test/pilot Jabber Instant Messaging server for the purposes of Group Chat for the IEC (Zimbra) calendar migration effort. Adium is an IM client that supports the

• Jabber XMPP protocol
• SSL encryption on the network
• Kerberos authentication

Read more »

The following at the instructions for setting up a Mac to connect to the IT Services test/pilot Jabber Instant Messaging server for the purposes of Group Chat for the IEC (Zimbra) calendar migration effort. OS X includes iChat which is an IM client that supports the

• Jabber XMPP protocol
• SSL encryption on the network
• Kerberos authentication

Read more »

When the Shibboleth IdP redirects a browser back to the SP, it does it via a form that is auto-submitted (if javascript is enabled). The default form is very basic, so I decided to spruce up the page for idp-dev.

The original IdP.jsp page source is in this attachment, and the updated version is in this one.

You should also update the other JSP files (IdPError.jsp, IdPErrorBlameSP.jsp and IdPStale.jsp).

To see the new page, just log in to this blog.

When I set up the test Clearspace server, I wrote a plugin for authenticating users via the web server. The plugin was developed for Clearspace 2.5 with Shibboleth, but should work for SBS 3.0 and WebAuth (+WebAuthLDAP to get mail and displayName attributes), since the authentication interface is unchanged, and the HTTP header variables that the plugin uses can be configured for different authentication systems.

To use it, first configure some system properties via the admin console:

Upload the clearspace-remoteuser plugin through the ‘Add Plugin’ admin page.

Ensure you have users registered that match the REMOTE_USER settings – for Shibboleth, usernames are username@domain (e.g. sunetid@stanford.edu), for WebAuth they should be just username.

Finally, restart Clearspace / SBS.

I’ve been playing around with a KDC and LDAP server in the test lab, and decided to try and get authentication working both with GSSAPI (Kerberos 5) and username/password authenticated against the KDC. It’s pretty straightforward, and a little bit of googling went a long way.
Read more »

Inquiring minds wanted to know more about the setup and configuration of the Openfire Jabber / XMPP server to work with GSSAPI / Kerberos, cross-realm authentication with Active Directory and user registration. Read on for the details
Read more »

People have been asking for more information about the test jabber server – itlab-im.stanford.edu, so here’s a quick overview.

The server is a small virtual machine (single CPU, 512MB RAM) running in the test lab. The server is running Debian 4.0 (etch), built from the Unix Group’s build system. It’s running Openfire 3.6.3, using Ignite Realtime’s official Debian package. Openfire is an open source XMPP server, written in Java.

It has been configured to use GSSAPI for authentication using the xmpp/itlab-im.stanford.edu service principal. I’ve added a couple of extensions, based on code from MIT (see previous articles) that enables cross-realm authentication to allow users to use their @WIN.STANFORD.EDU credentials, and to enable admins to log into the web console using their SUNetID and password (I’ll be taking a look at adding support for WebAuth in the near future).

Openfire has support for the usual XMPP server features – conference chats (with multiple conference services), with optional logging, server-to-server (can be disabled), file transfer proxying (can be disabled), gateways to other protocols, web-based presence/status service. It also has plugins to enable packet and content filtering, gateways to other IM protocols, broadcast IM, and minor integration with Asterisk / SIP.

Current user list, and their status, is online for registered users. Registration is currently limited to Stanford staff and faculty.

Video / Audio Chat

There is no standard for video or audio chat via XMPP. Some extensions have been proposed for negotiating RTP or SRTP connections between XMPP and RTP/STP aware clients, but they have not yet been finalized or implemented in most clients.

Got more questions? Send them to me, and I’ll add the answers to this article.

I’ve made a few changes to the test Jabber server:

• I’ve changed the SSL certificate to one issued by the IT Lab CA. On Macs, downloading the IT Lab Root Certificate and importing it into KeyChain should stop all the invalid certificate warnings for itlab services.
• Adam and Bill have access to the Openfire Admin Console using their SUNetID and password.
• Cross-realm support should be working. You should now be able to log in with AD tickets (principal@WIN.STANFORD.EDU) as well as tickets from the main KDC (principal@stanford.edu).

For the curious, the admin access and cross-realm are based on MIT’s Openfire extensions.