We are not able to see the destination url field within Mcafee Db. It is coming as "Not available" against the field.
Checked - Windows client config and already enabled :
Have you managed to find what exactly causes a URL Not Available incident? In my experience I've discovered this issue with Microsoft Edge when it is used to open PDF files containing data matching the DLP policy and the issue is not resolved up to that point. If that's the case for you, please submit a SR describing this issue and explaining it's regarding a bug that's already been raised with engineering - this should help getting it sorted out sooner.
There are also some other cases when URL Not Available might be encountered, if the above is not related to your case, could you please let me know what is the evidence file name / extension?
We had this same issue with all 11.6 versions. We opened a request with support last week but haven't heard anything back yet. Going to try to escalate today. We provided a MER, and all the logs so hopefully they can find something since the extension is loaded in the browser.
So this shouldn't be anything on your side that's configured incorrectly or missing. When I hear back I'll update this
I honestly jumped on here hoping someone had the same issue with a fix 😕
Note: IE is not effected by this bug and it's only gotten worse in the V90 and newer versions of Chrome or Edge.
We've had nothing but problems with 11.6 Endpoint (and Prevent). We're getting the not available from strange files in Web Protection (on Chromium-based browsers only) and the evidence it provides are random files from the Chrome directory--not even attempted POST or PUTs.
We've had the same issue with strange files. Nothing in the Chrome directory but now that you mention it that'll probably be the next place it flags. DLP seems to flag on O365 custom dictionary as well even when we don't have it enabled for Outlook. We use something else there.
We can't use an older version either due to wanting to use the new Edge browser and Chrome.
So does the issue with Chrome concern files such as "c1de9e6b910c7e688fb1462954f15d4b2f834882e839627aceb68826769a2f83"? If so, then I am afraid this is the same issue.
As for the dictionary - does this concern roamingcustom.dic?
In this case I assume the rule that you're triggering is for personal names. Yesterday we had a session with a McAfee technician and we replicated the issue in their test environment. They are gathering data at the moment to forward to the McAfee Engineering team - I believe submitting a service request and pointing out that it's an issue that has been already raised could result in the Engineering team taking a look at this with higher priority. I will keep you posted if I get any news from the SR.
Yep, flagging on names. We had the issue nearly every day, but we couldn't reproduce at will which meant no procmon which also meant that support wouldn't help.
Hopefully you have better luck
I have had evidence files with similar GUIDs. Their extension has been .tmp for the most part. I have see a variety of 'f_****' files that appear in some Chrome directory locations as well--among others.
The Classifications have been all over the board regarding the sensitive info types. We have opened an SR with Support and it is with their Dev Team. I was able to replicate the issue while accessing McAfee's own Webex site--so we gathered the pertinent logs/HAR.