Internal Instant Messaging Client / Server Combo?

strongmantim writes "I manage an internal help desk (25-30 people) for a medium-large company in the healthcare industry. We're looking for an internal, secure, FOSS (if possible) instant messaging / presence awareness client and server combo. Transmission of Protected Health Information is a sensitive issue, so the server has to be able to log any conversations that occur. It is preferred that the client not support outside protocols such as AIM, MSN, Yahoo, etc.; if it does, I will have to promulgate and enforce yet one more policy that my techs not connect to them. All of the computers that will connect run Windows XP. The system should be scalable up to ~100 people (in case we decide to include our entire office in the roll-out). Hardware and OS for the server are not an issue. Oh, and one more thing: It has to be free. Suggestions?"

Comments

Pidgin

[Shikaku]

Use the encryption capabilities in Pidgin.

http://pidgin.im/

Re:Pidgin

[erlehmann]

While Pidgin may be a reasonable multi-protocol client as a Jabber client I would suggest Gajim, which also does PGP and esession encryption (Pidgin cannot do either, AFAIK).

Disclaimer (possible conflict of interest): I contributed the :3 smilie to the Gajim icon set.

Re:Pidgin

[Cylix]

Pidgin protocols are supported through plugins.

Removing the respective plugin removes support for that protocol.

There are other measures which can be taken to ensure it stays protocol broken, but it really depends on how far the requester is willing to go.

Re:Pidgin

[Korin43]

Pidgin has encryption plugins, but from what I've heard, they aren't entirely stable :(

Re:Pidgin

[erlehmann]

considering that its been around for 5 years, the answer may not surprise you - or anyone for that matter: yes it is. i know only of one reliable way to crash it and that was a problem with the xmpp specification and has since been fixed. even running svn - which i do - does not necessarily mean there will be any instabilities.

SILC

[Zapotek]

You can setup a SILC server.
That's what we used to use in a company I worked for and it worked quite nice.

Re:SILC

[hgesser]

This post was rather short, but I think it is one of the best suggestions. I played a bit with SILC some years ago: From a user's view it looks a lot like an IRC client, so users can talk to one another privately or join a channel to meet with several other users. What's most important is: It meets all the criteria,
- it encrypts all communication
- it is no multi-protocol thing, i.e. you cannot connect to other services.
I can't remember whether you can run connections to several silc servers at the same time, but if so, that's at least better than having to restrict a program that can connect everywhere. Even though I haven't heard much of silc lately, the software is still actively developed. The last release is from March 19, 2009.

Re:SILC

[uhoreg]

SILC, however, fails the "log everything" requirement, by design.

Jabber.

[Mercury]

You're looking for a jabber server and client.

I work for a credit card company, and we use ejabberd on the server end of things.

You probably have some jabber only client options, but those will still be able to connect to other jabber servers like Google Chat.

Live with it, because any IM server worth using is going to have _some_ public servers.

I'll leave the logging up to you, ejabberd can do it, but our company decided that the security issues involved with storing the logs were much worse then not having the logs.

(Having stored, unencrypted, card data for any length of time is something that, on the very optimistic (good luck with the auditor) side requires a great deal of security. And just encrypting the drive it's sitting on doesn't really do away with more then half of that. Health data should be as much of a nightmare, but maybe not.)

Re:Jabber.

[Kadin2048]

Trying to enforce policy by trying to make the clients only connect to a specific server is stupid; a much better way (and the way I've actually seen implemented successfully) is to use a standard client program, a standard server running inside the LAN, and then enforce policy at the corporate firewall to prevent a user from connecting their client to a public server.

This way you can use whatever client/server combo you want: Jabber, SILC, AIM-style, SameTime, etc.

The way I'd enforce the gateway policy is simply to block ALL traffic from machines inside to machines outside. Machines inside the network, save specifically-designated servers working on specifically designated ports, don't get to talk to machines outside. Period. If they want to communicate with the outside world, they do it through a protocol-specific proxy. That would make it fairly easy to block connections out to IM servers; you just configure the HTTP proxy to never allow connections to the known public servers for that IM client, and to any server except on well-known HTTP ports. That will keep 99% of users from doing anything.

It's not totally secure, of course -- a highly-motivated user could set up a relay or IM server of their own, running on their own server (which wouldn't be blacklisted), on a common HTTP port, and there'd be no way to detect it except via packet inspection. However most people who are likely to do that are going to be in IT already.

I've worked in a number of healthcare and financial institutions that do the total-firewall plus filtering proxy thing; it actually allows them to be a lot less restrictive with their endpoint policies than they would otherwise have to be. You don't have to obsess quite so much about locking down every possible setting of every possible local program on the client machine when there's no way for the machines to pass traffic outside the network except through a small number of closely-monitored application proxies.

The only downside to this approach is that it can be a real bitch to get working if you have any legacy (non-web) client/server apps that weren't set up to use a proxy; if you start punching whole-port holes in your firewall to accommodate stuff like that, you quickly end up with nothing but a false sense of security.

Re:Jabber.

[Anonymous Coward]

i work in a HIPAA shop and i can assure you that you don't know what the fuck you are talking about. if you have a web browser you can accidentally paste something in a submit box just like this one. oh noes! you could accidentally fax a stack of docs to the wrong person. whoopsie! or how about email? reply all!

all that is required is due diligence in training employees in what not to do and what to do if you fuck up. we had one idiot send hundreds of archival CDs to the wrong clients. never got sued. just called and sent them all letters & email requesting destruction of the information. HIPAA is not the over reaching umbrella restriction you imagine.

on the off chance that you do have experience with it and that is your understanding i feel sorry for the company whose time and money you wasted securing things that don't need to be secured.

Openfire

[Anonymous Coward]

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

Works very well. Meets all your reqirements. Client supports Mac, Win and Linux but is a resource hog. It's jabber though so you can use many clients.

Re:Openfire

[drsmithy]

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

Works very well. Meets all your reqirements. Client supports Mac, Win and Linux but is a resource hog. It's jabber though so you can use many clients.

I second OpenFire. We have been (mostly) happily using it for a couple of years now. Trivially easy to setup, can back onto all the major DBs (or has one builtin) and has reasonable - if a bit clumsy and limited - capabilities to integrate with Active Directory.

openfire / spark

[Anonymous Coward]

Spark + openfire.

I implemented these with Active directory authentication.

Highly recommended, sure a couple quirks here n there with the advanced functions of the client, but for the basic features of needing to chat, and log... its the best i know of.

Re:Jabber is what you need

[palegray.net]

He could set up a Debian box (or virtual machine, whatever) running Jabber under his company's label in about an hour, including the OS install. Add a couple of hours to set up a backup/failover system synchronized via rsync and he's good to go. As for clients, there are a bunch of Java-based Jabber clients that integrate nicely with virtually any web app you've got deployed (with a bit of Perl or PHP glue, in some cases).

Re:Jabber is what you need

[craagz]

Openfire.. so easy you will be surprised. I've just come off a successful implementation at our workplace.
hack out the pidgin plugins. Pidgin Portable 2.5.5 is around 23MB and I removed all languages except English, plugins of everything except Jabber. Compressed it and 8MB.

Re:Jabber is what you need

[flosofl]

I second the Openfire/Spark combo (or other client of your choice). I set it up at work as a quick and dirty IM for our department (flung around the world). It's fantastic for quick questions or collabs that don't need or require email or phone. We've been using it for years (back when it used to be called Wildfire), and have not had one issue with it.

Citadel groupware server has all of the above

[IGnatius T Foobar]

You definitely want to try out the Citadel groupware server. Even if you don't need it for its mail system, address book, calendar, etc... it's got a built in XMPP (Jabber) service that integrates nicely across the entire environment. It also logs all of the instant messages sent through it. Each user can review their own logs too, which is nice. And you have the ability to journal everything that comes through the system, perhaps to an external archiving service (this feature was built with industries like yours in mind, where anything that gets read by anyone *must* be archived).

And it's free software ... GPL 3, to be exact.

Re:FOSS? One Word: Bullshit.

[drawfour]

FOSS? Where did he say FOSS? He never said FOSS.

Nice job reading. I quote from the Ask Slashdot itself:

We're looking for an internal, secure, FOSS (if possible) instant messaging / presence awareness client and server combo

He didn't say it HAD to be FOSS, but if possible, he would like it.

Re:Not another one

[kolbe]

I also recommend Ignite Realtime's Openfire. I have run it since Jive owned an Enterprise version of it (~2005) and all I can say is that it's rock solid.

It can run the server under either Windows or *NIX, offers integrated or external Database Server options, can be deployed to your website via Fasthpath to offer online chat services and offers several client options.

The best part of it is that it's easy to learn and deploy. A definite must to check out.

Re:Not another one

[harryk]

I agree.

The OpenFire Jabber server is rock solid and integrates with LDAP, has the ability to log conversations and generally speaking is very elegant and easy to maintain.

We also use the Spark client, which is made available by the same group.

Very solid setup if you ask me.

We ran this.

[Allnighterking]

At a company I left recently I installed Openfire and our supported IM client was their spark client (however despite my ex-bosses rants a lot of clients ended up being used by employee's) Spark works really well. Openfire is rock solid. It runs on Linux or Windows (better on Linux less server load). Without a hitch. Live upgrades work, and if you use mysql as the DB backend you can have auto failover. SSL 3 and TLS are supported as well.

+1 for Jabber

[shutdown -p now]

If you want free, open, secure and cross-platform, then it's definitely XMPP/Jabber. No surprise there - open protocol, plenty of servers and clients to choose from - it really is good. From your description, you'll almost certainly want that.

However, For all-Microsoft shops with AD and Exchange, a pretty decent option is Office Communicator (+ the corresponding Server). It doesn't really have many advantages as an IM, but it does integrate with Outlook, Exchange and SharePoint (from shared address book, to minor bits such as auto-setting your status to "Busy - in a meeting" when you have a meeting scheduled on your Outlook calendar, and storing conversation logs in Outlook mailboxes, which indexes them for search). It's also pretty good for conferences. Still, main feature there is that integration - on its own, it's hardly worth the bother. And, of course, it's not free (in any definition of the word), and the protocol, while SIP-based, is not without proprietary quirks.

Re:+1 for Jabber

[shutdown -p now]

Office Communicator on its own is pointless and when linked to Outlook is one of the worst software combinations ever. When either gets stuck, it takes the other out with it. Disconnect and reconnect to a VPN for example, and if you were using them together, Communicator will hang and you will have to restart Outlook and lose whatever you were writing because its obviously not multithreaded at some key point where it interacts with Communicator.

I've been using Outlook+Communicator at work for over a year, and I have never seen it do what you describe, even when the network went down entirely. I had Communicator crash otherwise two or three times, but Outlook kept working.

Re:Sametime

[Lingerance]

Sametime? Run far far away. It is the most bloated client I've ever used for any chat protocol, it crashes frequently enough and when it does it will sometimes prevent the user from rejoining a group chat, requiring a new one be made and everyone move over. There isn't a way for people to join a group chat on their own accord and must be invited, nor is there a way to auto accept invites. Any time you need to copy/paste a chat log it must be manually edited so it becomes even remotely readable and some of the GUI settings work contradictory to what you'd expect (like disabling smileys, it just does not work).

Re:You're doing it wrong

[Yvanhoe]

Why not ? I worked in an army lab that does that. One screen, one keyboard, one mouse, two PCs, a KVM switch.

VOIP softphone + server

[kiss7]

I can recommend the voip server and client from mizutech http://www.mizu-softphone.com./ It has built in encyption capable for handling up to 10000 client. Unfortunately it is not free.

Re:Not another one

[atraintocry]

I don't know about plain LDAP but I had serious trouble getting OpenFire to work with Active Directory. It integrated fine on the server side but single sign-on for the clients never worked. It seemed like it works great for 95% of people but for certain setups it's just impossible to get right. It's highly dependent upon your DNS setup, although I can't think of anywhere our DNS would be different from the norm. I also got in a little trouble because my users aren't all in cn=users but based on testing I don't think that was where the issue was.

I tried for a long time to get SSO working and eventually I had to just roll it out with separate user accounts. I suppose I could have paid for support but if I was going to do that I would have just bought one of the Windows-based enterprise IM packages that's out there.

Other than that it's been great. I was using Psi for a client but I can't seem to get it to alert people consistently. I (and the users) want something that will pop up the message and take focus no matter what. But Psi seems to be erratic in this regard.

Re:FOSS? One Word: Bullshit.

[Anonymous Coward]

Speaking as someone who provides IT for clinical departments at a (American) teaching hospital. FOSS is not evil, or verboten. My employers, and the people I support, are more interested in results than methods, they just want to know that someone (even if it's us) will take responsibility for the system.

Re:Jabber is what you need

[Anonymous Coward]

I double and triple recommend Openfire. http://www.igniterealtime.org/projects/openfire/index.jsp/

We have been running this with their Spark client http://www.igniterealtime.org/projects/spark/index.jsp/ for roughly 300 employees and this thing is great.

- Free
- Supports logging
- Supports keyword blocking (important in a medical environment)
- Has a web-based client, too
- LDAP (Active Directory) integration supported

You'd be hard-pressed to find another IM server that is as polished as Openfire, while still being free.

Re:Jabber is what you need

[Em Emalb]

We use postini to log all email and instant messenger communications. Postini acts as a proxy and stores each message for each user.

It's one of the requirements we have as a financial firm. (actually, I don't believe its required yet, but will be soon)

Re:Not another one

[jwilson27]

Another vote for OpenFire. I am the IT manager at a healthcare facility and I have implemented this successfully. The latest version was very easy to setup and integrate with Active Directory. It has been working like a champ for almost 8 months now. I also enabled the web client and Red5 video plugin for video chat. This saved us quite a bit of cash in travel fees since we have numerous clinics spread out over the area. We did not eliminate traveling (nothing beats face-to-face time). Instead we do weekly video meetings and monthly travel.

Re:Jabber is what you need

[bigstrat2003]

Yep, use that for your server. Do yourself a favor and use something other than Spark for the client, however. We use Openfire/Spark at my company, and while the server is solid and workable, the client is pure shit. It's slow and buggy as hell. Use Pidgin, Miranda, or whatever multi-protocol client you prefer, but not Spark.

GW Messenger from Novell

[FlyingGuy]

You will need at least one Edir Server and they can be the same box ( I Think, it might work with ldap ) and from there you are off and running.

It supports complete logging and log search ability ( by user or full text ), the client supports no other protocols it supports SSL has both linux and windows clients.

It is VERY light weight on both the server and client side.

Re:Jabber is what you need

[Anonymous Coward]

Here's another vote for Openfire. It is really easy to setup and maintain, can be used with external databases (we are using postreSQL), integrates w/ LDAP, has an external client gateway plugin, and has FastPath which allows you to do do queue-based chat routing from a website. We have been using it for about 2 years now and have been really happy with it.

Re:Jabber is what you need

[Anonymous Coward]

Second openfire. I'm not in some huge regulated industry (or company)--but Openfire was ridiculously easy for me to install even on our outdated SLES systems (and even easier on ubuntu). I'm not running SSO/LDAP yet (*sigh* I want to...don't start guys)--but I have centralized logging, absurdly easy web-based account mgmt, a client that I can install on any o/s, and it's so simple to use that I can get remote people on it safely without even requiring them to use the VPN. If I wanted to, I could (and have briefly) syndicated it with other jabber servers to expose "outside" chatting--we decided that wasn't worth it.

The application has caught on enough that amongst the non-blackberry crowd, it's more popular than email for interoffice communications--and there's been some discussions about getting our field team on it too--it would be absurdly easy if we decided to--to the point where the real barrier is that our "business" DSL account just doesn't have the uplink capacity for these things.

The Spark java client feels a bit slow and klugy -- most of the programmers prefer IRC or run pidgin to connect to it, but it's good enough to get the job done and anybody can figure out how to install it. I haven't tried any sort of A/V with it (we don't need that and don't have the outbound pipe anyway).

Re:Not another one

[trmatthe]

Fancy pointing out these LDAP "issues"?

I've migrated a metric crapload of LDAP apps from OpenLDAP, Sun LDAP and BT X.500 to Active Directory and AD/AM (aka AD-LDS) and haven't found a single issue with the LDAP interfacing apart from where apps were relying on non-RFC features in the original LDAP servers.

Your anecdote != data.

Re:Jabber is what you need

[loners]

You might want to take another look at Openfire. They stopped creating a separate "Commercial" version and released a lot of the features into the open source version. There is now logging and some other features.

Re:Jabber is what you need

[Deanalator]

By the way, the hak5 episode that came out today features a really nice video tutorial on setting up an openfire server.

hak5.org