I ran into an odd issue with DLP this week that I'm still working on troubleshooting. I'm looking to get some feedback and potential suggestions from the community. Our environment is as follows: DLP 9.2, ePO 4.5.6, HIPS 8 and VSE 8.8.
We control CD\DVD-ROM Rights using user policy which is linked to Active Directory groups. The default is deny read and then we have an Active Directory group for allow read and another for allow write.
Everything was working fine until roughly a week ago. There have been no policy changes in the past week, however I did make several software changes including: updating to McAfee Agent 4.6 Patch 3 from 4.6 Patch 1, updating from VSE 8.7 to 8.8 and installing HIPS 8 in logging mode.
Here is an explanation of the issue I'm encountering in Windows 7 64-Bit. When logging into an account and then selecting switch user, the second user who logs into the computer inherits the DLP rights from the first user. For example, an administrator with burn privileges logs into a workstation (with nobody currently logged in) to assist a customer. Once hes finished assisting the customer he locks his session instead of logging out. Anyone who logs in after him inherits his DLP permissions. This works in reverse as well. If a customer with deny read privileges is logged in and locks so that an administrator can help them, that administrator inherits the customers permissions and can no longer burn despite being in the appropriate groups.
This issue is occuring across multiple systems in our test group and we can replicate the problem 100% of the time. I haven't had much time to dig into it yet, thus far I've only rolled back the Agent with no change. I plan to open a ticket with McAfee after I do a bit more troubleshooting. Any assistance or suggestions is greatly appreciated.
DLPe enforcing rules from a user logged in first to all other users logging in later (as long as the first user still shows up as logged in) is expected behavior. 9.3 is the first version to fully support multiple user sessions.
We have a secondary environment with the exact same products that I listed above and the issue isn't present.
Any thoughts as to why DLP 9.2 is working for multiple user sessions in one environment and not another?
In the secondary environment did you test with the first user still logged in (they may lock the screen)?
This is from the 9.3 Readme:
Fast User Switching (FUS) on Windows Vista, Windows 7, Windows 8, Windows Server 2003, Windows Server 2008, and Windows Server 2012 is now supported with multiple user sessions. If Plug-and-Play device rules are differentiated by user, the most restrictive rule is applied to all user sessions.
I upgraded our test environment to 9.3 and multiple user sessions are now working.
However, a major issue I have discovered is when upgrading from 9.2 to 9.3 the McAfee Agent does not pull policy for DLP after rebooting. As a result no policies are enforced, DLP is inactive and the system is left unprotected. The only way to get the newly upgraded clients to pull policy is to go into the DLP console and apply the policy which increases the Policy Revision Id and Global Agent Configuration Revision Id. Please advise.
McAfee Agent 18.104.22.16822 and McAfee DLP Endpoint 22.214.171.1247.
Message was edited by: mullenjm on 7/12/13 12:55:52 PM CDT
From the 9.3 Readme:
If you are upgrading from an older version of McAfee Data Loss Prevention Endpoint (McAfee DLP Endpoint), verify that the DLP Policy Push task is scheduled to run every 2 hours. This new ePolicy Orchestrator Server Task pushes McAfee DLP policies to endpoint computers that have no DLP policy. The task is optimized for performance and does not push a policy to endpoints that have already received that policy.
This server task is necessary because ePolicy Orchestrator 4.5 and 4.6 fail to push policies to products whose internal product code ID has changed. Since McAfee DLP Endpoint client 9.2.2xx has a new product code, this task must be run periodically until all endpoints are upgraded to McAfee DLP Endpoint client 9.2.214.