Slashdot Mirror


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?"

73 of 360 comments (clear)

  1. Jabber is what you need by osssmkatz · · Score: 4, Insightful

    The question is which client and which server, and that I don't know. You should be able to lock it down by not allowing anyone to change its preferences.

    --Sam

    1. Re:Jabber is what you need by palegray.net · · Score: 3, Informative

      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).

    2. Re:Jabber is what you need by craagz · · Score: 5, Informative

      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.

    3. Re:Jabber is what you need by flosofl · · Score: 2, Informative

      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.

      --
      "This calls for a very special blend of psychology and extreme violence" - Vyvyan "The Young Ones"
    4. Re:Jabber is what you need by Creepy+Crawler · · Score: 2, Insightful

      If you go that route, you could instead install Xming on the clients and run the jabber client locally, on the jabber server. Kind of high overhead, but full and complete control.

      Each department could have their own eJabber server, so granularity would be rather fine.

      --
    5. Re:Jabber is what you need by Em+Emalb · · Score: 3, Insightful

      This looks like a good spot to reply. :-)

      At my work, we allow two IM programs, Pidgin and Trillian. Both are wide open, however all conversations are logged via Postini. My company (a financial firm) took the opposite route, rather than block a whole bunch of programs and port #s, we allow just about every form of internet communication and log it all.

      So far, it's worked out fairly well. Users respect that the company respects their ability to not be "Big Brothered" to death by allowing everything but making them aware that it's all logged.

      As far as IM clients go...what type of phone system do you have? If it's a Cisco system, you can look at Presence Server (CUPS) which has a built-in IM client and various other very nice to have options...just a thought.

      --
      Sent from your iPad.
    6. Re:Jabber is what you need by Tweezer · · Score: 4, Insightful

      What the hell are you smoking? I find answers like this to be way over simplified. Just setup a Debian box in an hour. Really? That is a bit naive. I have to ask you. Do you actually get your production servers setup in an hour? I don't know about you, but it takes me at least an hour or two to rack mount a new server, get it cabled, verify the redundant power is done correctly and get everything labeled properly. Then you have to get the OS loaded, app loaded etc. After all that, you need to be sure backups are setup and working properly, do some tests. After all this is HIPPA related and he needs to make sure it's working correctly, not to mention something like this will become a mission critical app in short period of time, because other people will come to rely on it . I could easily see after the release of something like this, other departments putting the use of the IM system into policy and procedures, because it's all logged. For example some manager says he will approve purchase requisitions over the IM system as it's all logged. I assume you've tested the log recovery from a backup and are confident you will be able to restore yesterday's log 7 years from now. And then document the whole thing. You do document things I hope. Even if you are the only admin, you need to document in case you are unavailable during an emergency. If you don't you aren't doing the job properly. I find a proper server takes more like 16-24 man hours.

    7. Re:Jabber is what you need by johnkzin · · Score: 4, Insightful

      The problem with Jabber/XMPP is that ... it doesn't satisfy the "not used externally" part. Jabber is the basis of GoogleTalk, and several individual IM services.

      But, that's a questionable goal of the request anyway. Any one of his coworkers can connect to AIM/Yahoo/GoogleTalk right now. If he doesn't want that happening, he can't just say "we said 'no no bad coworker'" and expect that this makes things all good and happy. If he wants to ensure that coworkers aren't going to connect to external IM services, he needs to block those IM services at the border (firewalls and/or routers).

      In my opinion, he should block all IM traffic (Yahoo, AIM, MSN, IRC, ICB, ICQ, XMPP/Jabber, Simple, and the others (look at what pidgin supports, find out what ports those chat/IM services use, block all of them)) at the border, and then require legitimate external users to use a VPN to access the internal Jabber server. If there are remote offices, then either those workers would need to VPN in to the site that hosts the Jabber server ... or each site should have its own Jabber server, and then the Jabber servers would all talk to each other via VPN.

      That's how I'd set it up. Block every chat/IM protocol/port at the border (and at the border of each remote office). Set up a Jabber server at the central and at each remote office. Link the Jabber servers to each other via VPN/tunnel/etc.. Go from there.

    8. Re:Jabber is what you need by Em+Emalb · · Score: 2, Informative

      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)

      --
      Sent from your iPad.
    9. Re:Jabber is what you need by bigstrat2003 · · Score: 2, Informative

      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.

      --
      "16MB (fuck off, MiB fascists)" - The Mighty Buzzard
    10. Re:Jabber is what you need by palegray.net · · Score: 2, Interesting

      Holy crap! Calm down, dude. My idea was for setting up a test system, with a test failover system using what I presume would be readily available test systems in an organization like his (if they're not using virutalization, they probably should be). Yes, the progression you described is totally accurate for putting together a production rig. Wow, documentation? You don't say, I never knew about documentation requirements for maintaining a network. Again, wow. The guy's looking for ideas for how to get started with solving his problem; I assume he knows how to do the rest of his job.

      Speaking of jobs, I've been doing this for close to fifteen years, including major work on Navy networks. How long have you been plugging away at it? Your technical skills sound great, but your interpersonal skills seem to indicate a penchant for running away with wild assumptions.

    11. Re:Jabber is what you need by Tweezer · · Score: 2, Interesting

      I just reread my post. Sorry I cam accross as too harsh. I've been at this for about 15 years myself and I just get sick of people assuming something only takes a short period of time to setup, because you can knock out a proof of concept quickly. I've also run into plenty of situations over the years where the documentation wasn't done, because either the admin didn't do it or management didn't understand the importance and wanted something with a higher priority done. I've also seen proof of concept systems turn into production systems when a manager says it's good enough and not a critical system and not to worry. That's when you really need to worry.

    12. Re:Jabber is what you need by palegray.net · · Score: 2, Interesting

      Hey, no hard feelings :). I definitely feel your pain; I've seen a setup where a repurposed desktop system shoved in a closet was acting as a domain controller for 150 workstations, another office with 90% of the outbound bandwidth consumed 24 hours a day by bots spouting spam, and still other situations where companies got some guy from the community college to build several "proof of concept" systems and just kept using them in production (they only had a cell phone number for their "guy", and I wound up trying to deal with the ensuing nightmare when crap started failing left and right). Sorry about that run-on sentence there, I get a little worked up about these things :).

    13. Re:Jabber is what you need by loners · · Score: 3, Informative

      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.

    14. Re:Jabber is what you need by Deanalator · · Score: 2, Informative

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

      hak5.org

  2. Pidgin by Shikaku · · Score: 4, Informative

    Use the encryption capabilities in Pidgin.

    http://pidgin.im/

    1. Re:Pidgin by compro01 · · Score: 2, Insightful

      I love Pidgin, but that doesn't fit the "does not support outside protocols" criteria.

      --
      upon the advice of my lawyer, i have no sig at this time
    2. Re:Pidgin by erlehmann · · Score: 2, Informative

      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.

    3. Re:Pidgin by Anonymous Coward · · Score: 3, Insightful

      You don't even need to do this. All the protocols are dynamically loaded (AFAIK, this is the case on Windows as well).

      Just remove the files for the unsupported protocols & block all jabber communications with the outside through the firewall (gmail for instance uses jabber).

      BTW, suggesting he hack the source instead of providing him with a client that meets his criteria is only useful if there are no free Windows clients that meet his needs. Since there are, at best you are telling him to use closed-source free (as in beer) software. At worst, he'll resort to closed-source non-free software.

      If there are no open-source alternatives, offer to create him one by a fixed-cost contract, cause my guess would be that they are more concerned with recurring per-seat license costs than just paying $1000 one time up-front.

    4. Re:Pidgin by Cylix · · Score: 2, Informative

      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.

      --
      "You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
    5. Re:Pidgin by Korin43 · · Score: 2, Informative

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

    6. Re:Pidgin by erlehmann · · Score: 2, Informative

      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.

    7. Re:Pidgin by Tarwn · · Score: 2, Interesting

      Unfortunately, while I personally like the XMPP protocol and think it would normally be an excellent solution, I think you have uncovered the biggest flaw. Preventing the clients from talking to the outside world is going to be nearly impossible unless you keep them on a network that doesn't route to the outside world.
      For instance, GTalk uses SSL over port 443 so if you want any type of secure web transactions with the outside world then your also going to be allowing secure chatting. Even if you go through and block obvious XMPP hosts that are using non-standard ports (443, 80, etc) it will require ongoing attention as other sites start their own services.

      --
      Whee signature.
  3. SILC by Zapotek · · Score: 5, Informative

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

    1. Re:SILC by hgesser · · Score: 5, Informative

      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.

    2. Re:SILC by uhoreg · · Score: 2, Informative

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

      --

      To get something done, a committee should consist of no more than three persons, two of them absent.

  4. Jabber. by Mercury · · Score: 4, Informative

    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.)

    1. Re:Jabber. by WindBourne · · Score: 3, Insightful

      Live with it, because any IM server worth using is going to have _some_ public servers.
      Actually, the whole point is that they CAN NOT. Hippa mandates that they do not do that. It would be possible for somebody to copy/paste into the wrong window. For that, it would certainly lead to a firing, and possible jailing. I have consider doing a talk for kopete with an enforced port (via code). It sounds like that is exactly what is needed, though a secured jabberd would cut it.

      --
      I prefer the "u" in honour as it seems to be missing these days.
    2. Re:Jabber. by Kadin2048 · · Score: 2, Informative

      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.

      --
      "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
  5. Openfire by Anonymous Coward · · Score: 5, Informative

    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.

    1. Re:Openfire by drsmithy · · Score: 2, Informative

      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.

  6. IRC? by gaelfx · · Score: 2, Interesting

    I've always found that IRC is pretty handy as a help service, most Linux distros host live help chat on it. Many other FOSS solutions seem to use it as well, such as VLC, OpenOffice.org, etc. I'm not sure how exactly one would go about setting up a server, but I can't imagine it would cost much of anything and it shouldn't be too difficult to set up. There is a pretty good wiki about it, it should have all the relevant links you could need for finding out how to do it. Cheers.

  7. We use soapbox by alta · · Score: 3, Insightful

    It's jabber based. Free as in beer for both the client and server.

    Lets us save logs of all chat sessions between employees, lets employees also save chat if they want to. Lets us do some filtering, overall a pretty good client/server.

    http://www.coversant.net/

    Oh, and I HAVE gotten Digsby to connect to the server, as well as trillian.

    --
    Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
  8. You're doing it wrong by SoapBox17 · · Score: 5, Insightful

    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.

    It sounds like your network, which contains confidential medical records, is connected to the internet.
    So I have just one question: Dear God, why?

    1. Re:You're doing it wrong by Yvanhoe · · Score: 4, Informative

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

      --
      The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
  9. Openfire by cleveland61 · · Score: 2, Interesting

    openfire is a jabber based FOSS server.
    we use it with AD integration. I haven't implemented it yet, but they have plugins supporting full message transcript.

    Spark is the client from the same company and it is jabber only.

    If I remember correctly, openfire alos supports being a proxy for all other (most?) IM protocol's so even if someone gets a copy of AIM or whathave you on you network, there server can still log the transcript.

    Easy to set up, free and robust.

  10. Re:FOSS? One Word: Bullshit. by Auroch · · Score: 2, Insightful

    *or* ...
    Number 3 ...

    The health care company isn't american and understands that being OPEN isn't a bad thing. Americans have a problem with that concept.

    --
    Quartz Extreme and Core Image. Are there any other real reasons to spend all that money on generic hardware?
  11. Jabber + Miranda IM by ScytheBlade1 · · Score: 3, Interesting

    I wrote about this some time ago, right here.

    The short and simple answer, that should fully meet your needs, is to install jabberd2, configure it as needed (should have a logging module/plugin somewhere), and then to use Miranda IM with only the XMPP components as the client. Miranda is very easy to customize; if you don't want a protocol you simply don't include the relevant DLL.

    Note: the links on that page are dead, namely the ones to the MSI installer package that I built. If you have a need for it, feel free to drop me an e-mail (the /. address should be fine).

  12. We use Exodus and Zimbra by jkrise · · Score: 3, Insightful

    Exodus is fairly simple to setup and administer. Zimbra provides much more than just Instant Messaging; we use it mainly for Zimlets and Collaboration; but the IM feature of Zimbra with auto-logging is very useful and sophisticated as well.

    --
    If you keep throwing chairs, one day you'll break windows....
  13. OPENFIRE - FOSS Jabber (XMPP) server by waa · · Score: 2, Insightful

    It has an intuitive/simple web interface for administration, and meets your logging needs and more. It can also support many gateways such as AIM, MSN, GADU-GADU, Yahoo! etc - But you don't have to enable them if you don't want them. I use this with the PSI IM client http://psi-im.org/ - A cross-platform Jabber IM client for MAC OSX, Linux and Windows. Check it out at: http://www.igniterealtime.org/projects/openfire/index.jsp

    --
    Windows is not the answer.
    Windows is the question.
    The answer is "NO."
  14. Re:FOSS? One Word: Bullshit. by Urza9814 · · Score: 2, Insightful

    FOSS? Where did he say FOSS? He never said FOSS. He said 'free'. Most likely free as in beer. What company _isn't_ looking for free software? My guess would be they just don't consider this essential and don't want to waste a shitload of money on it.

  15. Re:Not another one by neokushan · · Score: 3, Insightful

    You know, I had the exact same issue this guy is having and, guess what - google gave me that exact answer (Openfire).
    Of course, I used MirandaIM because I knew Miranda had Jabber support and it's a decent little client, but yeah, another vote for both Openfire and "just fucking google it next time".

    --
    +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
  16. Re:Not another one by Kleen13 · · Score: 2, Insightful

    Hey look, another Ask Slashdot that should have been Ask Google! Wow! You never see those on here or anything. Maybe this could have been an Ask Freshmeat if they still want a solution from OSDN.

    Boooooo. It's not a rumour, you do suck. Perhaps you should stop pissing in your Cheerios every morning and realize that perhaps he wanted a professional or experienced opinion.

    --
    That sinking feeling deep in your gut when you KNOW you screwed up bad summed up with: {head desk} {head desk}
  17. Citadel groupware server has all of the above by IGnatius+T+Foobar · · Score: 4, Informative

    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.

    --
    Tired of FB/Google censorship? Visit UNCENSORED!
  18. Re:FOSS? One Word: Bullshit. by drawfour · · Score: 4, Informative

    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.

  19. Re:Not another one by Kleen13 · · Score: 2, Insightful

    Your point is that he's wasting your time? You probably shouldn't have replied then. My boo stands.

    --
    That sinking feeling deep in your gut when you KNOW you screwed up bad summed up with: {head desk} {head desk}
  20. Re:Not another one by kolbe · · Score: 2, Informative

    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.

  21. Re:Not another one by Kleen13 · · Score: 2, Funny

    gotcha.

    --
    That sinking feeling deep in your gut when you KNOW you screwed up bad summed up with: {head desk} {head desk}
  22. Re:wtf by erlehmann · · Score: 3, Insightful

    IMO, an "educated" opinion from a technical crowd is in any way better than a simple Google query. I don't know, for example, how Google could possibly have a differentiated answer to the pros and cons of particular clients.

  23. Re:Not another one by harryk · · Score: 5, Informative

    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.

    --
    think before you write, it'll save me moderator points.
  24. We ran this. by Allnighterking · · Score: 4, Informative

    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.

    --

    I'm sorry, I'm to tired to be witty at the moment so this message will have to do.

  25. Re:Not another one by Gerzel · · Score: 4, Interesting

    Perhaps he also wanted some insights from people who have been in similar situations?

    There is a big difference between a website found on google and a testimonial from someone who's done it.

  26. Re:Bonjour may be what you need. by Phroggy · · Score: 2, Interesting

    Bonjour is great, but what you've suggested doesn't meet his needs at all. One of the stated requirements is that there MUST be centralized logging of all conversations, and what you've proposed is direct client-to-client chats with no centralized server.

    --
    $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
    $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
  27. Blocking outside services is a waste of time by fadir · · Score: 3, Insightful

    Set up a policy if you really have to but wanting to block services is just a waste of time and doesn't add anything to your security unless you have totally incompetent personnel or fully locked down computers. Otherwise they'll start using web clients or simply work around firewall blocks or the like - which at the end might cause more security issues than the usage of the service in the first place.

    It's much better to invest this time to educate your people and teach them why it's a bad idea to use MSN.

    Lots of companies set up ridiculous firewall rules and think that they are safe - not knowing that the overkill is causing exactly the opposite of what they want to achieve. People don't like to be locked down if they don't understand why.

    I had a similar problem to solve in the (small) company that I work for. We ended up with Openfire and Pidgin. This is not safe from the outside but better than what our big mother company did. They force everyone onto Sametime and have their system locked down like no tomorrow - which ends up in people using a multitude of services and wasting a lot of time to work their ways around the firewall to be able to use MSN, Facebook, Jabber & Co.
    While I know what I have to deal with and act accordingly, teach the people that they please stay away from insecure services on their work PC the mother company trusts in their rules and unintentionally provokes insecurity.

    Security never works against the people, only with the people.

  28. Spark + eJabberd by darkpixel2k · · Score: 2, Interesting

    I support a 7-site network with ~80 PCs. I use the Spark client because it comes packaged as an MSI--easy to push out via Group Policy. I also have a batch file which creates an initial settings file for the users the first time they sign in.

    Initially we had an internal (old junker box) linux server which was only accessible from the internal network and everyone had Jabber IDs of user@customer.local. We recently switched to user@customer.tld so people could access it from their iPhones and Windows Mobile phones using the Palringo client.

    ejabberd on linux has nice LDAP integration with Active Directory on Windows. You could also use the OpenFire server which is made by the same people that make Spark. It has a free version and a commercial version IIRC.

    --
    There's no place like ::1 (I've completed my transition to IPv6)
  29. +1 for Jabber by shutdown+-p+now · · Score: 3, Informative

    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.

    1. Re:+1 for Jabber by shutdown+-p+now · · Score: 2, Informative

      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.

  30. Re:Sametime by Lingerance · · Score: 2, Informative

    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).

  31. Go easy on the "should" will you? by golodh · · Score: 5, Insightful
    @Anonymous Coward

    As to where the parent post "should" have asked his question, the parent post asked an intelligent question on a forum that harbours a lot of people who can provide a good answer in under a minute. Slashdot.

    There are lots and lots of applications like Jabber, Openfire and whatnot about. And yes, if you want you can create a great big (useless) list of them by Googling for a few minutes. And then what? What are the pros and cons of each app? Where can you find comparative tests? Are those tests any good? Has anyone got practical experience with the app? Any show-stoppers that aren't immediately apparent?

    The point about most questions like this is that people who already know the answer consider them "easy". People who don't know the answer consider them hard, and will have to expend a lot of time finding out. Time that's wasted if you could simply have eliminated 90% of the options by asking. That's why you ask. At least if you'd rather get some useful work done instead of being the umpteeth person researching the same wheel.

    It's a compliment to Slashdot that people ask such questions, and they do that because they even tend to get useful answers. It shows that Slashdot has value apart from serving as a forum for inane bickering.

    1. Re:Go easy on the "should" will you? by damona · · Score: 5, Insightful

      ... And for those of us who already know the answer, this is a good opportunity to find out whether there's something new we should be looking at too.

    2. Re:Go easy on the "should" will you? by strongmantim · · Score: 2, Insightful

      Thanks for the support! According to many posters here, I should also likely Google programming languages, learn to program, write my own IM/chat application, etc. There are a lot of people on Slashdot who have already gone through all the research and have a ton of experience using a particular server or client. I didn't ask this question on other boards or sites because I knew I wouldn't get honest, helpful answers from the other sites... I chose Slashdot because the community is resourceful, intelligent, and knowledgeable. Thanks again for your post!

  32. VOIP softphone + server by kiss7 · · Score: 2, Informative

    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.

  33. Thanks for the recommendation. by Anonymous Coward · · Score: 3, Insightful

    Thanks for the recommendation. I wish that people who don't like a story wouldn't visit it and clutter the story with negative comments.

  34. Re:Not another one by LoadWB · · Score: 5, Insightful

    This is the exact attitude that pushes people away from FOSS in the first place.

    It is almost impossible to get a real answer from people with experience when all you get in return is "RTFM n00b."

    R'ing TFM does not always give you practical information or experience. Especially since there are quite a lot of people out there who are great at writing software but cannot write a manual to save their life. Either it is too technical and boasts about all of the incredible feats of writing the program with very little usability information, or overly verbose about how the program works with very little usability information.

    Google does not have all of the answers. It has a wealth of information, but sometimes no answers.

  35. Re:Not another one by atraintocry · · Score: 4, Informative

    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.

  36. Re:Apple Bonjour for Windows + Pidgin by Arimus · · Score: 2, Insightful

    And will not comply with the OP's logging requirements...

    --
    --- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
  37. Re:Not another one by Skylinux · · Score: 5, Insightful

    You will find plenty of testimonials if you Google for them.

    So why not take it a step further and close down Slashdot.org?
    After all, the articles on slashdot are not written by slashdot staff but borrowed of the web so anything on here can be found via Google. Most websites also have a comment section so the trollish comments can be found not only on Slashdot.org

    So get over yourself, some people here may actually try to learn from the experience of others.

    Don't like a story? Don't fucking reply!

    --
    Everyone who buys Wild Hunt will receive 16 specially prepared DLCs absolutely for free, regardless of platform.
  38. Re:Spark IM client/server by cgabbadon · · Score: 3, Interesting

    I agree, Openfire Server with Spark as the IM client will satisfy your requirements. It is a solid, extensible instant messaging server that should meet all your requirements.

    What is nice about Openfire is that it allows you to centralize the management and security a lot, which gives you a lot of control in information-sensitive situations like this. It has integration with an existing LDAP/AD server if you want to keep your authentication policy centralized on your LDAP server if you have one. Likewise, you can force all users to use SSL for secure messaging if you want.

    Likewise, I was working with the open source version over the last couple weeks (I setup a test environment for our company), and based on the menu options it appears that message auditing also is included (I didn't try it), so you can log all your conversations as you would like. I knew they had this feature before in their paid version, but it looks like they made it available in their open source version.

    Finally, if you ever grow and need support, you can get it from their list of service providers. And it's free :-). It has easy installs for both Windows and Linux - definitely give it a try.
    Good luck!

    Openfire Server
    Spark XMPP Client

  39. WASTE by bioborg · · Score: 2, Interesting

    http://en.wikipedia.org/wiki/WASTE might work, it was developed by Nullsoft for internal communications and file sharing, is encrypted, and has no central server.

  40. +1 for OpenFire+Spark (FOSS) by Shouden · · Score: 2, Insightful

    I'm the Senior SysAdmin for a large datacenter in Florida. We currently employ over 50 people in our building. We recently migrated from Pidgin+OTR(Encryption) to OpenFire+Spark with ActiveDirectory Integration. I had the server installed and pulling down a list of accounts from the AD server in a matter of minutes. The server has worked flawlessly for us for months and has tons of options. It supports the ability to either allow or lock out 'other' clients(AIM,YIM,etc). This coupled with ACL or Firewall restrictions will ensure that your users are ONLY using the Spark client. It also has chatrooms built into it which you can force your users into when they log on. It's pretty neat stuff.. oh.. it supports SSL connections, and will provide LiveChat for your website as well. It also support logging of all chat conversations if you have a need for that. The only downside that I've run into.. there's a bug on the linux client that has to be fixed manually(associated with the tray icon not showing up). The Windows client has a tendency to run slightly slow. While I read that it runs slow under Windows, in practicality I have not received even one complaint regarding the use of Spark. Oh.. while there is a history in the Spark client, it shows it all as one realllly long page so it's a little clunky having to hunt through your own personal chat history. Look no further. OpenFire+Spark is your answer.

  41. Re:Not another one by jwilson27 · · Score: 5, Informative

    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.

  42. GW Messenger from Novell by FlyingGuy · · Score: 2, Informative

    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.

    --
    Hey KID! Yeah you, get the fuck off my lawn!
  43. Re:Not another one by trmatthe · · Score: 2, Informative

    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.

    --
    Yeah right...