Avecto DefendPoint on Mac

I am just starting to use it. I don't have a ton of experience with it, but I've been running it next to JAMFPro on about 6 macs (as a test deployment) for a month or so. So far in my testing they haven't interfered with each other, but I also haven't intentionally tried to make them interfere either. Any specific questions I can try to answer?

@hulsebus

Sorry for the delayed response.

I was curious to see how many are using Avecto in their environment.

We are using security authorizationdb for now, but we may be moving to Avecto soon.

bump on this one?

Any further information back on Avecto?

We have a POC here, and to be honest, it looks very "clash" like with Jamf?

So far we've been having relatively good luck with it. Again, I haven't had time to try elevating a process that JAMFPro has restricted (or vice versa), but Avecto hasn't interfered with any processes elevated through Self Service/EA/Policy so far. It has worked out really well for those users that won't use Self Service...

The biggest hiccup we've had so far is with our developers that use the terminal extensively. Avecto just recently started supporting terminal elevation so we're working on implementing that.

hulsebus thanks for the response.

I already had several items in place for elevation, so it may be a matter of removing those specifics and letting defendpoint take control.

Any issues with defendpoint interfering with Jamf management? Trying to override something that Jamf already put in place, etc.

Thanks

I'm chiming in here because this is something that will hit my 2018 or 2019 roadmap and I want to be ready for it. Are there alternatives to Avecto? I'm not against Avecto but I'd love to bake off with a competitor.

BeyondTrust also has a Mac agent, as part of their Powerbroker solution. Both BeyondTrust and Avecto's solutions are younger than their Windows solutions so there will of course be caveats with either. I definitely recommend a bake off/comparison to see what best fits the needs at your organization.

Just a quick update for anyone interested. I'm starting to encounter cases where Defendpoint is blocking execution of app installations from Self Service. The weird part is it doesn't do it for everyone, even though everyone is on the same white-list definitions. I rolled out a new application a month of or so ago and out of 8 installs (that I'm aware of) only two have failed because of Defendpoint. Unfortunately it's a graphically silent fail (you have to dig through log messages to find it) so users are getting confused why Self Service says the install was complete but the application isn't there.

I've spoken to our Defendpoint rep and there should be a new Mac agent coming out soon (hopefully) that has some white-listing enhancements that will hopefully fix this issue.

We're gearing up to start rolling out the Defendpoint agent for both Windows and Mac, starting with a smaller subset of users. I'll keep an eye out for that kind of issue, @hulsebus. I'll also let you know what kind of things we run into as well in case it might be helpful.

Are you using the sudo control features by chance?

We have been using Avecto on Windows with no issues and good results. The Mac agent is super buggy. Their last agent v4.x.x.x made all our macs to Kernel Panic. The new version 5.0 corrected that, but we are having a ton of problems removing clients because the instructions they left don't work...

The mac client feels half-baked, to be honest... They need more time in the oven...

The latest release of Defendpoint for Mac (5.0 SR1) has fixed some of the stability issues that existed in the 5.0 release (Chrome freezing/hanging, Apple updates not installing, issues running pkg files created by Composer). We are still in a very limited pilot for the Mac client because it is much less mature than Windows, although it is getting better. I've been running Avecto on my own Mac for a couple of months now and for the most part it is ok. The sudo control seems to work well. The limitations with the /Applications folder are a bit of a pain. Starting with 5.0, DMG files are supported (the Avecto agent prompts to copy contents to the /Applications folder) but there isn't a way to tell it NOT to do that (like when you download a DMG file that has a .app installer that needs to be double clicked, not just copied to the /Applications folder). Still doesn't resolve not having the ability to remove items from the /Applications folder, which we've been working around with sudo commands with our more technical users. We've seen a small number of incidences where some component of the Avecto agent/services crashes or becomes unresponsive but it's still intercepting auth requests. In that scenario, user gets prompted for credentials as per policy, however Avecto does not accept the credentials provided by the user. Fixed by rebooting.

For client removal, since it is trying to kill Avecto services as root and root cannot at this time be excluded from Avecto policies, it intercepts the sudo commands causing their uninstall instructions (script) not work. I think this MAY have been resolved in SR1 but not 100% sure.

We've been doing this:

Open Terminal
su to administrative account
run the following commands:
sudo launchctl remove com.avecto.pgdaemon
sudo launchctl remove com.avecto.custodian
sudo launchctl remove com.avecto.pgpolicyserver
sudo /usr/local/libexec/Avecto/Defendpoint/1.0/uninstall.sh

The Avecto agent for Mac also does not intercept ALL auth requests in all scenarios. There are some situations where it won't (manually modifying profiles for example). In order to perform those types of tasks, you HAVE to have an admin account of some sort. Mostly edge cases, but with technical users it will be a challenge.

@gpalau , the Spectre/Meltdown patch from Apple changed the way kernel extensions are allowed to load, which is why the 4.x agents caused crashes. Version 5+ use the new correct method.

Version 5 seems better, but I've run into the issue where I can no longer white-list Apple applications based on publisher. In 4.x, we could white-list the Apple applications (calculator, calendar, mail, etc) simply by white-listing the Apple publisher, but in 5, Apple applications show simply as 'signed' and not 'signed by Apple Corp' like they used to. As a result, our test systems could literally not launch anything with our first roll-out. Still working on correcting this...

Another update for anyone following this, I've encountered another hiccup between Defendpoint and JAMF Pro. In Defendpoint you define 'work-styles' which effectively classifies users and what types of elevations they'll be allowed to do. Running the current Defendpoint (5.0.19550 I think...?), the casper-admin account receives execution restrictions based on whatever work-style it falls into. This isn't such a big deal when you know it's happening, but I didn't know until I started experiencing issues (didn't happen on Defendpoint v4). It is easy enough to generate a work-style specifically for that account, you just have to know to do :-)

The 5.2 version of Avecto Defendpoint renamed some files, so if you had an EA that reported the Defendpoint version it may now be broken. Here's a version of the EA I use that's updated to handle 5.2:

<?xml version="1.0" encoding="UTF-8"?><extensionAttribute>
<displayName>Avecto Defendpoint Version</displayName>
<description>This will check to see if the Avecto Defendpoint software is installed. If it is, the version number will be returned, otherwise result is "Not Installed"</description>
<dataType>string</dataType>
<scriptContentsMac>#!/bin/sh&#13;
#&#13;
############################################################################&#13;
#&#13;
#  Created on 2018-06-19 by sdagley&#13;
#  Updated 2018-09-11 by sdagley&#13;
#   Support renamed Defendpoint daemon app for version 5.2.27899.0&#13;
#&#13;
############################################################################&#13;
#&#13;
&#13;
if [ -f "/usr/local/libexec/Avecto/Defendpoint/1.0/PrivilegeGuardDaemon.app/Contents/Info.plist" ] ; then&#13;
    VERSION=$( defaults read "/usr/local/libexec/Avecto/Defendpoint/1.0/PrivilegeGuardDaemon.app/Contents/Info.plist" CFBundleShortVersionString )&#13;
elif [ -f "/usr/local/libexec/Avecto/Defendpoint/1.0/defendpointd.app/Contents/Info.plist" ] ; then&#13;
    VERSION=$( defaults read "/usr/local/libexec/Avecto/Defendpoint/1.0/defendpointd.app/Contents/Info.plist" CFBundleShortVersionString )&#13;
else&#13;
    VERSION="Not Installed"&#13;
fi&#13;
&#13;
echo "&lt;result&gt;$VERSION&lt;/result&gt;"</scriptContentsMac>
</extensionAttribute>

Just out of curiosity, if Jamf built an integration between Jamf Pro and Avecto, what would you want to see in that? Other than the EA that reports back on the version of Defendpoint that @sdagley posted above of course...

@kryptedjamf You asked... A GUI to manage the Defendpoint configuration settings in defendpoint.plist (which can't be managed via the Defendpoint McAfee ePO Console interface - why not have configuration options in two different locations and only provide GUI configuration for one) so I don't have to modify a script/generate a .pkg to update them.

Have any Defendpoint users seen an issue where a .pkg file being installed by a JAMF policy causes the user to lose focus of the active window being worked in? If we run a script to view the active process it is SecurityAgent that becomes the active window, rather than whatever the user was in. It's annoying to users because it means that every 30 minutes they will need to click to reselect the Window they were working in.

If I remove Defendpoint the issue does not occur. If I run a package manually via the OS X GUI then SecurityAgent never becomes the active process. If I run the Policy via "sudo jamf policy" it does not trigger SecurityAgent. It is only triggered when a .pkg is installed during a normal JAMF check-in.

Have a ticket opened with BeyondTrust, but no progress after several weeks.

@rlindenmuth Not that it's any help in this case, but we experience occasional focus changes with or without Defendpoint. It does seem to occur more often with Defendpoint though. I haven't dug into it too far, but we have some policies and possibly extension attributes that call third-party executables for information gathering and I'm wondering if those other executables are taking focus when run and then dropping focus to desktop it when it closes. Again, don't have much insight aside from speculation, but we experience similar focus symptoms.

Thought I would introduce myself. I'm a product manager @ BeyondTrust (formerly Avecto), and I look after the Defendpoint for Mac product. Please feel free to tag me into any posts about our product and I'll be happy to answer any questions you have.

If you are a user of our product, and you want to suggest a new feature, enhancement, integration, whatever it is, we have an ideas portal you can use ideas.beyondtrust.com - or just add a post here :)

So far no direct "clashes" with jamf unless you try removing it. The uninstaller doesn't restore the device permissions so Jamf and other admin accounts end up broken.

Even for troubleshooting purposes removing it is a tedious and painful task.