Verwendete Komponenten:
• Server OS: Debian 4.0
• Server-Software: Openfire Server v3.5.1
• Client-Software: Spark IM Client v2.5.8 (alternativ jeden anderen Jabber-Client)

Hinweis: Diese Anleitung sollte an und für sich ebenso für die Windows-Versionen sowie alle nachfolgenden bzw. vorherigen Releases für Openfire (der frühere Name der Software war "Wildfire") gelten.

Warum einen Instant-Messanging-Server:
Die Anforderung war, die Kommunikation unter den Mitarbeitern zu verbessern bzw. zu vereinfachen, ohne die vorhandene Infrastruktur extrem aufzubohren.

Warum Openfire:
Sicherlich gibt es zig Implementationen von Jabber Servern. Ich habe mich für den Openfire Server entschieden, da die Installation und Konfiguration der Software sehr einfach ist, kostenlos und lässt sich durch Plugins nahezu grenzenlos erweitern. Ansonsten kann der Openfire IM Server alles, was auch ein anderer IM Server kann. Ohne allerdings erst noch viel Arbeit zu haben. Denn normalerweise ist alles drin, was man zum Jabbern braucht.
 
Konfiguration des IM Servers:
Die ersten Schritte sind im Web-Interface zu tun. Da werde ich jetzt mal nicht weiter drauf eingehen. Es sollte klar sein, dass das Produkt nach erfolgreicher Installation erst noch konfiguriert werden muss. Das, was ich dazu sagen möchte ist, dass es sinnvoll ist die MySQL Datenbank zu nutzen. Die eigentliche Verwaltung der Benutzer selbst geschieht im Active-Directory. Nachdem dann das geschehen ist sollte der Jabber Server heruntergefahren werden. Also der Dienst beendet. Normalerweise passiert das im Openfire-Verzeichnis mittels der Commandline ./bin/openfire stop

Die Konfigurationsdatei ist unter ./conf/openfire.xml zu finden. Und genau diese ist interessant. Geöffnet wird die mit dem Editor der Wahl. Ich bevorzuge den VI.

In dieser Datei gibt es bereits eine Section LDAP. Diese ist allerdings auskommentiert. Die Kommentare einfach entfernen. Hier mal ein Beispiel für LDAP mit kompletter vCard nach XEP-0054 gefüllt aus dem Active-Directory (die Home-Teile aus der vCard wurden ausgelassen, da das AD hierfür keine Felder bereitstellt - wenn man es dennoch pflegen will bieten sich meiner Meinung nach die customAttributes an):

<?xml version="1.0" encoding="UTF-8"?>
<jive>
  <adminConsole>
    <port>9090</port>
    <securePort>9091</securePort>
  </adminConsole>
  <admin>
    <!-- <authorizedJIDs></authorizedJIDs> !-->
    <authorizedUsernames>admin</authorizedUsernames>
  </admin>
  <locale>en</locale>
  <network>
    <interface>11.22.33.44</interface>
  </network>
  <connectionProvider>
    <className>org.jivesoftware.database.DefaultConnectionProvider</className>
  </connectionProvider>
  <database>
    <defaultProvider>
      <driver>com.mysql.jdbc.Driver</driver>
      <serverURL>jdbc:mysql://localhost:3306/openfire</serverURL>
      <username>jabber</username>
      <password>secret</password>
      <minConnections>5</minConnections>
      <maxConnections>20</maxConnections>
      <connectionTimeout>1.0</connectionTimeout>
    </defaultProvider>
  </database>
  <ldap>
    <host>domaincontroller.corp.example.com</host>
    <port>389</port>
    <baseDN>dc=corp,dc=example,dc=com</baseDN>
    <adminDN> Diese E-Mail Adresse ist gegen Spam Bots geschützt, du musst Javascript aktivieren, damit du sie sehen kannst </adminDN>
    <adminPassword>secret</adminPassword>
    <connectionPoolEnabled>true</connectionPoolEnabled>
    <sslEnabled>false</sslEnabled>
    <ldapDebugEnabled>false</ldapDebugEnabled>
    <autoFollowReferrals>true</autoFollowReferrals>
    <usernameField>sAMAccountName</usernameField>
    <searchFilter>(&
                    (objectCategory=Person)
                    (memberOf=cn=JabberAccess,ou=Users,dc=corp,dc=example,dc=com)
                    (sAMAccountName={0})
                  )
    </searchFilter>
    <vcard-mapping> <![CDATA[
      <vCard xmlns="vcard-temp">
        <FN>{displayName}</FN>
        <N>
          <GIVEN>{givenName}</GIVEN>
          <MIDDLE/>
          <FAMILY>{sn}</FAMILY>
        </N>
        <EMAIL>
          <INTERNET/>
          <USERID>{mail}</USERID>
        </EMAIL>
        <NICKNAME>{sAMAccountname}</NICKNAME>
        <URL>{wWWHomePage}</URL>
        <BDAY>{dob}</BDAY>
        <ADR>
          <HOME/>
        </ADR>
        <ADR>
          <WORK/>
          <STREET>{streetAddress}</STREET>
          <LOCALITY>{l}</LOCALITY>
          <REGION>{st}</REGION>
          <PCODE>{postalCode}</PCODE>
          <CTRY>{c}</CTRY>
        </ADR>
        <TEL><WORK/><VOICE/><NUMBER>{telephoneNumber}</NUMBER></TEL>
        <TEL><WORK/><CELL/><NUMBER>{mobile}</NUMBER></TEL>
        <TEL><WORK/><FAX/><NUMBER>{facsimileTelephoneNumber}</NUMBER></TEL>
        <ROLE/>
        <TITLE>{title}</TITLE>
        <ORG>
          <ORGNAME>{company}</ORGNAME>
          <ORGUNIT>{department}</ORGUNIT>
        </ORG>
      </vCard>]]>
    </vcard-mapping>
    <nameField>cn</nameField>
    <emailField>mail</emailField>
    <groupNameField>cn</groupNameField>
    <groupMemberField>member</groupMemberField>
    <groupDescriptionField>description</groupDescriptionField>
    <posixMode>false</posixMode>
    <groupSearchFilter>(objectClass=group)</groupSearchFilter>
  </ldap>
  <provider>
    <vcard>
      <className>org.jivesoftware.openfire.ldap.LdapVCardProvider</className>
    </vcard>
    <user>
      <className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
    </user>
    <auth>
      <className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
    </auth>
    <group>
      <className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className>
    </group>
    </provider>
  <setup>true</setup>
  <log>
    <debug>
      <enabled>false</enabled>
    </debug>
  </log>
</jive>

Diese Konfiguration wäre passend, wenn man eine Domain 'corp.example.com' betreibt, in der es eine OU 'Users' gibt, und dort eine Gruppe 'JabberAccess' angelegt hat, in der die Benutzer stehen, die auf den Jabber-Server connecten dürfen. Wichtig zu sagen bleibt, dass die Funktionalität der Benutzerregistrierung im Client selbst ausgehebelt wird, da der Openfire Server bei Benutzung von LDAP-Datenbanken nur lesend zugreifen kann. Die Benutzerpflege geschieht also komplett im Active-Directory.