Blocking AIM/YIM/MSN/ICQ & Trillian

If your users are using the Exchange IM client (which looks similar to, but is implemented differently from, the standard Windows Messenger and MSN Messenger), see the Microsoft article "XFOR: How to Configure Instant Messaging Client System Policy Settings" (http://support.microsoft.com/?kbid=264472). In particular, you can configure the Exchange IM client to connect to Exchange servers only by setting the ExchangeConn registry value of data type REG_DWORD to 2 under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MessengerService\Policies registry subkey. The best way to apply this setting is to use an Active Directory (AD) group policy.
If your users are using the Windows Messenger client with plugins that allow Exchange access, you'll have to create a group policy to add two new registry values to the HKEY_CURRENT_USER\Software\Policies\Microsoft\Messenger\Client registry subkey. Both values are named Disabled, are of data type REG_DWORD, and should be set to 1. To turn off the Microsoft .NET Messenger Service plugin, add a value named Disabled to the {9b017612-c9f1-11d2-8d9f-0000f875c541} registry subkey; to turn off the Communications Services plugin, add a value named Disabled to the {83D4679F-B6D7-11D2-BF36-00C04FB90A03} registry subkey.
If you simply want to block the IM traffic, block all TCP port 1863 access to any host in the msgr.hotmail.com domain. To turn off IM and chats only, block UDP ports 13324 and 13325.

> .. does anyone have an idea of how to block this w/o installing additional software or changeing user rights?
no software, no other rights, no change. Except you pill the internet wire ;-)

If you don't want to change the clients, neither software nore any permissions, then you need a sophisticated application level firewall.. Are you prepared for $$$$$?

Actually the suggestion from Vand sounds promising and I will test it tomorrow.  I don't want to install software because it can be costly and would add to the support load.  I have 1 peice of critical network software that requires the users to have local machine admin rights and that was what I was referring too when I said I didn't want to change user rights.

Thanks, E

> .. users to have local machine admin rights ..
then simply forget about any solution to stop a user to modify his/her client to do anything you don't want, imposible.

modifying the Active Directory Group Policy should work though.

> > users to have local machine admin rights ..
what should AD help there?

Using the disallowrun registry edit in the group policy should work even if they have local machine rights.

You are correct EWilson12, in fact, I commonly will allow the domain users group admin access to the local machine, and restrict them through the domain.  This prevents 5000 daily calls for trivial rights issues, while still allowing you to lock down the workstation.

Leave the authenticated and everyone group in the local users group to prevent users from logging in locally to try to damage their local machine, if they are inclined to do so.

> users to have local machine admin rights ..
and
> .. group to prevent users from logging in locally
how should this work?
Either a person (I mean the human, not a electronic user) knows the local admin password, or not. And if the password is known, and this admin (the account) can login locally, then domain policies never apply. Dot.

No one logs on locally, if they did they wouldn't have access to any of our business specific productivity apps on the network.  So if to get around my IM block they decided to log on locally for a few hours every day it means that they absolutely wouldn't be getting any work done whatsoever and would be pitched out the door in short order.

Thanks, E

You are correct ahoffmann.  My statement made 2 assumptions:
1. The pcs were not always in a domain and therefore had local user accounts.
2. They are using some other known local account or shady method to gain access

What I was stating is the fact that if a user somehow did gain local access by some means other than authenticating to the domain, they would be regulated to very restrictive "local user" rights.

Lets take a look at what I'm suggesting

"You are correct EWilson12, in fact, I commonly will allow the domain users group admin access to the local machine, and restrict them through the domain.  < Here I have told the PC that anyone who successfully logs in with a Domain user account and password has admin rights to the PC, except for whatever restrictive policy I have applied via group policy.

This prevents 5000 daily calls for trivial rights issues, while still allowing you to lock down the workstation.

Leave the authenticated and everyone group in the local users group to prevent users from logging in locally to try to damage their local machine, if they are inclined to do so." < Here I have modified the default local groups to regulate anyone who is not an authenticated Domain user to only have Local user privledges.

Hope that clears it up

>  No one logs on locally, ..
in theory. But in praxis they can, and hence circumwent any policy.
So if fireing them is an option, you're fine. :-)) Arn't you?

The only free, effective way, is to setup network monitoring (or look at firewall logs) and ensure that any traffic destined to IM servers is blocked.  Eventually you'll get a list of about 40-50 IM servers, that you just block with a firewall rule and the problem will go away.

Redirecting DNS doesn't really help - users can circumvent by hard coding IM server IP addresses into applications.

aah, sounds like my very first comment http:#11777644 gets into mind, slowly .. ;-)
and no, a (traditional network, aka packetfilter) firewall itself *cannot* block all IM traffic

I disagree, if you block the exe from executing, IM cannot run.

You can use group policy editor to block access to
MSN/Windows Messenger by setting a policy and enforcing for the
required groups.

This thread is getting off track, EWilson12 please try applying the policy and let me know what happens. If you need help on how or what policies to apply, just post here again. I will respond to any questions you have.

Vand, your solution is awesome!!!! but... there is 1 huge loophole in it:

Users can rename the exe and run it that way ;(

Fortunately your advice is now leading me down a similar road.  I am seriously considering using an allowed programs list for even tighter security this should eliminate a ton of spyware type progs in addition to time waster progs from running.  As far as the user logging on locally to run crap I may change it so that they must validate to the domain to access the internet this in combination with an allowed programs list would make our environment far more secure for very little effort and no hard $ costs.  Of course I would bet money that if a user renamed a program so that it matched one on the allowed programs list it would still run.

Thanks for the help, E

> Users can rename the exe and run it that way ;(

Not if whatever program you use to control exe access uses signature-based checking...

For example, Websense CAM has a database of program signatures, so knows what they are by looking at file headers, rather than program names.  This means users can rename programs, but still, they won't be able to run.

There are other ways of doing this too - it's a pretty well-researched subject and there are a lot of products out there that can help.

interesting topic.. i got some tips from it..