LDAP capable IM solution: OpenFire 3.4.6

OpenFire 3.4.6

http://www.igniterealtime.org/projects/openfire/index.jsp

My need for IM:

Recently, I have discovered the need to notify my users of system outages (um…email?). The Windows Messenger service is out of the question as it is hard to selectively broadcast messages, and you cannot keep a central log of your messages easily – or at least, not without some third-party solution keeping track for you. Not only that, but you can’t configure file transfer, perform voice chat or other more advanced functions.

Enter OpenFire, a Jabber/XMPP compatible IM server, and Spark, the chat client provided by Jive software (makers of OpenFire). I was completely flabbergasted by the capabilities that this free software could provide!

So, a quick list of features out of the box (and mind you, this is supposed to be a quick overview, so I may skip over some other features you might find handy):

• SQL, MySQL, PostGreSQL, Oracle, IBM DB2, HSQLDB and embedded database compatible
• LDAP compatible authentication
• Assortments of plugins available
• Supports other Jabber clients (besides ‘Spark’, the one that you can download from OpenFire’s website)
• Extensive administration options
• Broadcast capability
• User groups
• Import/Export user data
• Configurable chat rooms

A quick look at the server information page

What caught my attention was the ability to authenticate my users via LDAP. This means that my users can log in with their Windows domain credentials and not be concerned with creating and/or remembering a new or different password. Nice!

Setup complexity: Low

If you are a sysadmin who is worth his or her salt, you should have absolutely no trouble setting this up within 5 minutes. If you aren’t terribly familiar with LDAP (and want to get this to work) or have some port magic you have to work, it could take you a little while longer to set up…but, out of the box, it only takes a few minutes to get going.

To set up OpenFire in my environment, I opted for the SQL server backend, for scalability and performance. I only needed to know the SQL administrative password for setup, then OpenFire did the rest.

Also, when I configured LDAP, I needed to know the DN for my administrative account (which would be authenticating my logons) and CN for where to pull my user accounts from. I used SysInternals’ AD Explorer to get this information quickly.

These users were imported into OpenFire from AD automatically.

The Spark client

• For me, the awesomeness does not stop at the OpenFire server (and how ridiculously easy it is to set up), but I really like the Spark client as well.
• The download is a bit hefty at 27Mb, but I assure you, it is a full-featured and robust client that has some great capabilities:
• Easy file-transfer
• Send screenshots quickly with the built-in screenshot snip tool
• Voice chat
• Avatar support
• Invite-to conference

Now, some of these features can be disabled at the server level (like the file-transfer and avatar support), but for a support staff, you can see the benefits of having a screenshot snip tool!

What would be really nice is the ability to lock down the main Spark interface so that you could remove the ‘Accounts’ and ‘Advanced’ buttons…don’t want my users messing around, right?

Plugins

Some of the plugins available for the OpenFire server:

Asterisk-IM Openfire Plugin

Integration for Asterisk and Openfire.

Broadcast

Broadcasts messages to users.

Client Control

Controls clients allowed to connect and available features

Content Filter

Scans message packets for defined patterns

Email Listener

Listens for emails and sends alerts to specific users.

Fastpath Service

Support for managed queued chat requests, such as a support team might use.

Fastpath Webchat

Web based chat client for Fastpath.

IM Gateway

Provides gateway connectivity to the other public instant messaging networks

Monitoring Service

Monitors conversations and statistics of the server.

MotD (Message of the Day)

Allows admins to have a message sent to users each time they log in.

Packet Filter

Rules to enforce ethical communication

Presence Service

Exposes presence information through HTTP.

Registration

Performs various actions whenever a new user account is created.

Search

Provides support for Jabber Search (XEP-0055)

SIP Phone Plugin

Provides support for SIP account management

Subscription

Automatically accepts or rejects subsription requests

User Import Export

Enables import and export of user data

User Service

Allows administration of users via HTTP requests.

Oh, OpenFire, how do I love thee?

What next for me?

Next, I need to:

• Develop an acceptable use policy
• Figure out how to lock Spark/OpenFire down a bit more to prevent abuse
• Discover proper deployment technique and pre-configure the client upon installation
• Test out the ‘Support chat room’ plugin (IT support, anyone?)

Have you used OpenFire? Do you use a different IM solution at your job? What were your issues that you had to overcome in order to successfully deploy it in your organization?

If you aren’t an IT admin like myself – what do you think of the IM in your company? Is it useful? What don’t you like?

Exchange admin tip: Create a query-based distribution group

Requirements:

• Windows Active Directory
• Exchange server 2003 or higher

Do you have distribution groups or lists that you are maintaining constantly? Are they department or organization-based groups? Perhaps you have organized your OU structure within Active Directory according to department or logical business units?

If your answers were "yes" or you are just plain curious...then here is a really handy way to create virtually maintenance-free distribution groups in Exchange. The only thing you would need to do is make sure that your users are located in their proper OU structure in AD so they automatically become members of the group you are creating.

Here's the information from Microsoft:

To create a query-based distribution group

1. In Active Directory Users and Computers, in the console tree, right-click the container where you want to create the query-based distribution group, point to New, and then click Query-based Distribution Group.

2. In Query-based Distribution Group name, type a name for the query-based distribution group, and then click Next.

3. Under Apply filter to recipients in and below, verify that the parent container shown is the one that you want the query-based distribution group to be run against. If this is not the correct container, click Change to select another container.

   Note:
   The query returns only recipients in the selected container and its child containers. To get the results that you want, you may have to select a parent container or create multiple queries.

4. Under Filter, select one of the following options:

   • To filter the query based on a set of predefined criteria, click Include in this query-based distribution group, and then select from the following criteria:
     - Users with Exchange mailboxes
     - Users with external e-mail addresses
     - Groups that are mail-enabled
     - Contacts with external e-mail addresses
     - Public folders that are mail-enabled
     
   • To create your own criteria for the query, click Customize filter, and then click Customize.
     

5. Click Next to see a summary of the query-based distribution group that you are about to create.

6. Click Finish to create the query-based distribution group.

   The new query-based distribution group appears under the container that you selected in Step 3.

So, I've created an LDAP filter/query that picks up users that are located in an OU (in my case, an OU that denotes a physical location, "State Street").

Here is the query that I've created:

(&(!cn=SystemMailbox{*})(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) )))

Don't worry, you create these queries on the fly and isn't as complex as it looks above.

But...you can create compound filters if you want to get really crazy.

Excluding users from a query:

I created a filter that excluded our physicians here in town (the last part of the query excludes an account called helpdesk from the distribution list):

(&(!cn=SystemMailbox{*})(&(&(&(|(&(objectCategory=person)(objectSid=*)(!samAccountType:1.2.840.113556.1.4.804:=3))(&(objectCategory=person)(!objectSid=*))(&(objectCategory=group)(groupType:1.2.840.113556.1.4.804:=14)))(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) )))(objectCategory=user)(!description=Physician*)(!samAccountName=helpdesk))))

So, the benefit? First, each distribution list gets their own SMTP email address - and, as long as my users appear in those OU's, my distribution lists are always up to date!