Choose from several options for complete web, email and data security.
Learn more
Evaluate Websense products by watching demos and installing evaluation software.
Learn how Websense solutions help keep our customer safe, secure and productive
Get information on product updates, support resources and more.
Get the most out of support in five simple steps.
Find tools and assets to help sell Websense solutions.
Come work for the global leader in unified information security. Go
Good morning,
To simplify things in Websense and for a better management I’ve decided to use AD groups for Websense filtering (before I had only networks as clients and no problem at all), but when a user is going on a website that is blocked, the website is not blocked as it should be. But if I apply the policy directly to a client instead to apply it to a group, it works… so it works if I filter by user, but not by group…
Websense is configured with DC Agent and Logon Agent and it is Windows Active Directory – Mixed Mode. Our domain is in Windows 2003 Server Mode. In AD, I’ve created and tried both Global and Universal groups, but it’s not working with either one.
I did some tests and I’ve found the following: if I do a test with Check Policy and Test Filtering for a specific user (with the right policy applied), it works, but if I do the same thing for my Websense Groups, the Default policy seems to apply instead of the right one, even if in Policy Management – Clients – My Websense Group I have choose the right policy.
Any ideas how to solve this?
Thanks,
Well your users are being identified correctly, so that's a good sign, but it sounds like you're not pulling AD group memberships at all. DC Agent and Logon agent are only there to identify users, so they're not your problem.
Does the Directory Services service account have domain admin rights? That'd be my first guess, that for some reason Websense can't pull AD group memberships, most likely permission problems. Directory Services is what's responsible for pulling AD group memberships every few hours.
Reading your post got me curious, so I followed the steps you reported in your original post. I get the same result and we're running v7.6.5 stand alone on Win2008 R2 64-bit. I have an AD group called WS-Drugs which allows access to the Drugs category and all sub-categories - IE Marijuana. If I test the users they all have access to anything within the Drugs category (including sub-categories). If I test against the AD group WS-Drugs, the default policy is applied.
I believe this is by design. A group is for administrative purposes, a group doesn't generally have a logon, but users do. I believe WS doesn't know what to do with the group.
By the by... Your service account definitely does NOT require Domain Admin rights. We have a very strict security policy where I work and one of the first things we do is get services running with the least amount of rights required. Its just good practice. We contacted support and they confirmed that you do not require Domain Admin rights for the service account. However, you will receive annoying error messages in the logs stating that your service account doesn't have Domain Admin. I would like to see some solid documentation from WS as to exactly why Domain Admin rights are required for the service account. Most of their documentation online simply states that you need this and any explanation given sounds more like a guess than informed.
CF
Well... I’ve already went to Triton Settings - User Directory and I've configured the LDAP user directory with Active Directory (default port 3268) and I did a Test Connection and everything is OK.
So Websense it does "talk" with AD, but like cfowler said and tested, Websense seems unable to work with AD groups?
If so, it means I must assign a policy at each and every user… well, it can be done, but that make Websense a bit clumsy J
Nononono, you can definitely, without a doubt, filter and assign policy by AD security groups. In a previous life I lived off of that ability and relied on it to filter thousands of people properly, and in my current scenario I use it as well.
I'm confused. :)
The original question - if I perfrom a Check Policy (via TRITON console) using the AD Group Name as the User, why does WS tell me the Default policy applies. If do the Check Policy using a user who belongs to the same AD Group the correct policy applies. Why?
For example... cfowler belongs to the AD Group WS-Unrestricted. When I do a check policy on th user WS-Unrestricted, I receive Policy: Default, Type: User, Client WS-Unrestricted. If I do the same process using cfowler as the username I receive Policy: Unrestricted, Type: Group, Client: WS-Unrestricted.
I think the question is why doesn't WS report the same result for the Group WS-Unrestriced since the policy actually applies to that AD Group.
The configuration you're running with AdrianRB sounds correct. You should proceed by assigning AD Groups as the applicable client. IE create your policy & when you apply the client choose the AD Group you want that policy to apply to. To test, do a Check Policy for any user within that group.
I did what you asked, but before that I went to Settings – Directory Services – Global Catalog Server and I checked if the connection is OK. At Administrative Access WS is configured with Full distinguished name, since my account in not in the Users OU . I did a Test connection and… Connection succeeded. So… so far so good.
Then I went (again) to Clients and I’ve added the group Websense Filter HR and I’ve assigned a policy called Facebook Deny. Then I connect myself on someone’s computer who is in the Websense Filter HR group, I did a test with Facebook and the website is not blocked…
I went back to Websense, I did a Policy Check with the group’s name as a client and the result is Policy: Facebook Deny, Type: Group; Client: Websense Filter HR – so, it should work, but it isn’t!
Next, I’ve added one of the users which are already in the Websense Filter HR group as a client and I’ve applied the same policy - Websense Filter HR… this time the website is blocked as it should.
Next, I did again a Check Policy with the user’s name and the result it as follows:
Policy Type Client
Facebook Deny User Someone
Facebook Deny Group Websense Filter HR
…which means the user is correctly identified as a member of Websense Filter HR group.
So… half of the problem is solved, I have the same policy for the group and my user, but it only works if it is applied directly to a user, not to a group in which the user is member !?
If I check the properties for each client in WS I have:
Client “someone”:
LDAP://dcr2.mydomain.com OU=Ressources Humaine,OU=Siège Social,OU=mydomain.com,DC= mydomain,DC=com/someone
Client “Websense Filter HR”
LDAP://dcr2. mydomain.com,OU=Ressources Humaine,OU=Siège Social,OU= mydomain.com,DC= mydomain,DC=com/Websense Filter RH
I’ll do a test tomorrow with TestLogServer while keeping only the Websense Filter HR in place to find out more…
First, thanks a lot for trying to help me with my issue. I Owe You.
Second, according to Websense documentation, when you configure AD in Native Mode it says: Specify which administrative account Websense software should use to retrieve user name and path information from the directory service. This account must be able to query and read from the directory service, but does not need to be able to make changes to the directory service, or be a domain administrator.
When I did my test I did them logged as a user, not with my account, sorry if it was not very clear. Yes, we have W7 and I did not switch the user.
I have to do my test with Facebook because the management want to block THIS website. I’m aware about HTTPS issues with Facebook, but I’ll solve them later.
Beside this, I think I found where the problem is… I did a Test Filtering Results, first with the user someone and then with the group Websense Filter HR and the results are:
1. User - Result: This custom URL is assigned to a blocked category.
URL: www.facebook.com
Client: someone
Category:Facebook Deny
Details:Defined as custom URL
CATEGORY BLOCKED CUSTOM DENY
2. Group - Result:This custom URL is assigned to a permitted category.
Client: Websense Filter HR
CATEGORY NOT BLOCKED CUSTOM PERMIT
How that could be explained if when I do a Policy Check with the user’s name and I have (see below) ?
Policy : Facebook Deny Type : Group Client: Websense Filter HR
I don’t get it…
