MS Patch (KB 971737) breaking Logon Agent
For those of you using Logon Agent Transparent Identification Agent, a bit of caution: Microsoft patch 971737 breaks Logon Agent.
What happened is that Microsoft updated the winhttp.dll library used by LogonApp.exe to authenticate itself with Logon Agent. Basically, the update enables “extended protection for Windows authentication” for all users of winhttp.dll AND it turns on NTLM v2. NTLM v2 will be supported in Websense 7.5.
Extended protection for Windows authentication only applies to the NTLMv2 and Kerberos authentication protocols and does not apply to NTLMv1.
Besides not installing the patch, customers can install the patch and then edit the registry to disable “extended protection for Windows authentication” and revert to using NTLM v1 (two different registry changes). Customers may want to do this in order to take advantage of changes to winhttp.dll that Microsoft is not advertizing (always a possibility).
The registry changes are:
| Set the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection to 1 to enable protection technology. By default, this key is set to 0 upon installation, disabling the protection. Set the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel to 1. This is not the default on Windows XP and Windows Server 2003. This is an existing key which enables NTLMv2 Authentication.
You’ll have to reboot after making the registry changes… |
Is it possible to copy information between Policy Databases? Is there any equivalent to Central Policy Distribution (CPD) for Version 7?
- The Websense Policy Broker and Websense Policy Database services must be installed and running successfully on both machines.
- Both Policy Database machines must be running on the same operating system.
- Both source and destination Policy Brokers and Policy Databases must be the same version.
To transfer data from the source Policy Database to the target:
- On the TARGET machine, make a backup copy of the config.xml file (located by default in C:\Program Files\Websense\bin or opt/Websense/bin) and save it in another location (with a name like config.xml.sav).
- Use the following command to create a backup copy of the TARGET Policy Database:
PgSetup -save SavePolicy.db - Stop all Websense services on the TARGET machine.
- Open the config.xml file on the SOURCE machine, and copy the Token data (example shown below) to the config.xml file on the TARGET machine. When you are finished copying the data, save and close the file.
<data name="Token">0542A478BC2AB7773AE226F8471E4DD12E7AB78DEFF21A3A151621EFBF5A9855B2B5560F020CDB3AF84BE45F001619
D8F205471447AFA83DF5CD95EAB6D9BBA0A1BDD0B54ACD112254B23A8FD96B2397C45FC58FCC8A2616BB9FFE19D1960B5CEF7BBA09F4BA9E4
CC3076B88873A61EAE26CE2DA8D3DE858D550C7A5ECF732E39C1DBB7403F7F22E9C4F401815FAD21BD427175DBD1B06B28465CC20C41AD452
DE2B7798A71CF17E</data> - Rename the config.xml.bak file on the TARGET system to config.xml.bak.old.
- On the SOURCE machine, navigate to the Websense bin directory (C:\Program Files\Websense\bin or /opt/Websense/bin, by default) and run the following command:
PgSetup –save Policy.db - Copy the Policy.db file from the SOURCE machine to the Websense bin directory on the TARGET machine.
- From the Websense bin directory on the TARGET machine, run the following command:
PgSetup –restore Policy.db - Start all Websense services on the TARGET machine.
All policy data from the SOURCE system is now duplicated on the TARGET system.
Site is categorized as Malicious
Have you ever wondered why a site could be categorized as Malicious? Well, there's several reasons, ranging from email phishing to other various causes of why Websense would categorize the site as Malicious.
If you'd like to know why they're malicious, you could email SUGGEST@WEBSENSE.COM, and we'll tell you.
Or, you could download a utility called Malzilla and inspect the site itself. While this isn't necessarily always the cause, most of the time it has to do with javascript obscufication. After de-obscufication, sometimes you'll see the hidden urls do, in fact, go to third party malicious urls, even though there is nothing malicious about the host you went to in the first place.
You can find a tutorial how to use Malzilla by going to the site: http://malzilla.sourceforge.net/documents.html
DC Agent issues
A lot of us in Technical Support are seeing DC Agent installed in non-supported configurations. (Especially for WCG and V10K installs)
- DC Agent requires to be installed on a Server that is part of the Domain
- DC Agent can be a Server that has a two way trust relation to the domain you want to transparently identify users.
- Users that are being transparently identified will have to have unique user names between the domains.
- DC Agent requires a Domain Account
- Using the “Local System” Account is not supported for DC Agent. You must use a Domain Account for DC Agent.
- This is because DC Agent needs an account with appropriate rights to be able poll the Domain Controllers to retrieve User to IP/Workstation information.
- If using a trust, you will need to have rights to domain(s) you want to transparently identify users.
- Using the “Local System” Account is not supported for DC Agent. You must use a Domain Account for DC Agent.
- DC Agent can be a Server that has a two way trust relation to the domain you want to transparently identify users.
- In most situations, we recommend that you run both DC Agent and User Service with domain administrator access rights.
- This is because these service only monitor information; they do not change anything in the domain.
- Workstation polling requires that the account used by DC Agent have local admin right to the workstation being polled. Domain Admins natively have this right.
Hotfix 42 has been released for 7.1 DC Agent. I highly recommend this hotfix be applied.
http://eval.websense.com/download/patches/WSE_7.1_Hotfix_42_DCAgent_Connection_breaking_windows.zip
Please see KB 2660 (http://kb.websense.com/article.aspx?article=2660&p=12) and the Transparent ID white papers (http://kb.websense.com/article.aspx?article=3835&p=12) for more information on DC Agent.
Site Categorizations
Lots of customers create cases asking why sites are categorized a certain way especially when it comes to sites categorized as Malicious.
Technical Support has no input or view into why a site is categorized as Malicious, or any other reason. Only our Database team has the ability to look at that information.
So if you don't want to waste time, send an email to mailto:suggest@websense.com directly, with the information you're asking for, and include the version of Websense you're using as well.
The software is not supported in that configuration.
You'd be surprised how often that is said in this line of work. Websense software is tested in specific methods and certain technologies are not tested, nor even planned for during the development phase.
Lets take some examples. In one case, the customer is trying to install Websense Client Policy Manager client on a Vista Enterprise 64bit SP2 system. Websense 6.3.2, which the customer is using, does support using Vista, however not with 64bit systems. In fact, *none* of our software currently works as designed on 64bit systems. I'm sure there are some enterprising individuals who have gotten it to work by smoothing out wrinkles. I know of at least one component that will absolutely fail on a 64bit server. That's the Network Agent, which uses code to access network card level information and open the communications for promiscuous traffic. In 64bit systems, these "low level" access requires signed drivers which isn't in place. Therefore, the Network Agent can't even detect the network cards and can't even install.
In another case, the customer plans to use Websense filtering with a Blackberry Enterprise Server. Blackberries and other phone type devices have historically been unable to display the blockpage because Websense uses frames, where those devices can't. For another reason, the Blackberry Enterprise Server is essentially a proxy server for these handhelds. In some proxies, such as the Websense Content Gateway, we have a plugin which will pass user information to the filter service. There is no such plugin for Blackberry servers. The best the user can do is to use another proxy server (like Websense Content Gateway) which *is* supported and *will* pass usernames if configured to do so.
Websense will not document what it doesn't support. It only documents what *is* supported. So, if the installation that you're planning to do isn't in the documentation, don't assume you can do it.
In the Beginning….
I've been considering for a long time doing a blog based on my experiences and cases I work with on a daily basis, and highlight some of those with the public so everyone can share. Names of individuals and companies, of course, would not be shown to protect their identies.
Of the various software companies out there, I think Websense is unique that it doesn't have a lot of "pro"-Websense forum/blog communities and yet still does very well in the marketplace. Most of the blogs and forums are from students and employees trying to find ways AROUND the software blocking their access to sites like Facebook and gambling sites. I guess the rule of thumb to follow here is that our software's value is inversely proportional to the amount of hate toward the software from the users of the various networks the software is installed.
This site isn't about promoting Websense nor about how to defeat the software so those users could bypass the filtering. This site is specifically written to the system and network administrators who struggle with administrating the Websense software. I aim to make this site an easy way for looking for resolutions to common problems, without having to search KB.WEBSENSE.COM.
And, in the process, perhaps you won't need to call into Technical Support as often. That would be a 'Win-Win".