Staj

@Peter RandziakCan I please grab the systemd service unit file? I still need to resolve the problem.

The Apache HTTP Proxy installation - Linux documentation neglected to instruct on configuring htcacheclean, now the filesystem is full, can I please have a working systemd service unit file that I may use for /var/cache/apache2/mod_cache_disk ? Also, this should be included in documentation.

I'm looking into expanding our use of ESET products into a different part of the business but they utilise Proxy Auto Config (PAC) for their devices (Windows). I'm aware you can configure proxies statically in policies and that there is a "Detect proxy" button as well but is there support for PAC for Endpoint Antivirus and Security products?

I had some issues configuring Active Directory integration (Kerberos etc.) with ESMC so I decided to do a write-up on what I did to get it working. This is for Ubuntu Server 18.04 but it should be applicable to other Debian based distros, adjust where required. Let's assume we have the following environment: ESMC Linux Distribution: Ubuntu Server 18.04 ESMC Hostname: esmc ESMC FQDN: esmc.test.local ESMC IP Address: 10.123.1.2 Active Directory Domain: test.local NetBIOS Domain: TEST Domain Controller: dc.test.local (10.123.1.1) ESET ESMC AD User Account: eset.esmc@test.local (eset.esmc) Ensure the required Server prerequisites (v7.2) are installed. sudo apt-get install krb5-user ldap-utils libsasl2-modules-gssapi-mit samba Configure Samba at /etc/samba/smb.conf Ensure you change workgroup to the NetBIOS Domain, netbios name to the ESMC Hostname and realm to the Active Directory Domain. The following configuration is based on one found in ESMC VA v7.2 [global] workgroup = TEST netbios name = esmc server string = Samba Server Version %v security = ads realm = test.local domain master = no local master = no preferred master = no socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 use sendfile = true idmap config * : backend = tdb idmap config * : range = 100000-299999 idmap config TEST : backend = rid idmap config TEST : range = 10000-99999 winbind separator = + winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind nested groups = yes winbind refresh tickets = yes template homedir = /home/%D/%U template shell = /bin/bash client max protocol = SMB3 client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes restrict anonymous = 2 log file = /var/log/samba/log.%m max log size = 50 load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes client ipc signing = auto Configure Kerberos at /etc/krb5.conf Ensure you change default_realm to Active Directory Domain (Must be capitalised) and the realm definition Active Directory Domain (Must be capitalised). Ensure you specify your Domain Controller as a kdc under the realm definition for your Active Directory Domain, if you have multiple Domain Controllers, specify multiple kdc's. Ensure you map Active Directory Domain (prefixed with ".") to the realm name (Your Active Directory Domain but capitalised) under domain_realm. The following configuration is based on one found in ESMC VA v7.2 [libdefaults] default_realm = TEST.LOCAL ticket_lifetime = 24h forwardable = true [realms] TEST.LOCAL = { kdc = dc.test.local } [domain_realm] .test.local = TEST.LOCAL Configure DNS Resolution. systemd-resolved can cause issues with Kerberos, it can probably be worked around but disabling it as follows also works. sudo systemctl disable systemd-resolved.service sudo systemctl stop systemd-resolved Configure /etc/resolv.conf Specify your Domain Controller as a nameserver, create additional nameserver definitions for each Domain Controller. Specify Active Directory Domain for search nameserver 10.123.1.1 search test.local Ensure Hostname is set correctly If you need to change your hostname, you can use: sudo hostnamectl set-hostname esmc.test.local Configure /etc/hosts Add your ESMC and your Domain Controllers to the hosts file. Take note of the ordering of FQDN and aliases after the IP Address as net join will use the first defined alias for your host as SPNs etc. when joining the system to the domain. All values are tab separated. 127.0.0.1 localhost 10.123.1.2 esmc.test.local esmc 10.123.1.1 dc.test.local dc Configure Time Synchronisation By default, the maximum tolerance for computer clock synchronization for Active Directory Kerberos participants is 5 minutes from a Kerberos Key Distribution Center (KDC; in our case, the Domain Controller) to operate correctly. If ESMC is in a VM, you may already be using a Hypervisor with some VM Agent that handles this but, if not, then systemd-timesyncd should suffice or you can use ntpd. Let's assume you use systemd-timesyncd: Configure /etc/systemd/timesyncd.conf NTP Server addresses are separated by spaces. specify each of your Domain Controllers [Time] NTP=10.123.1.1 Ensure systemd-timesyncd is set to sync and force it to resync. You should see a log entry that it "Sychronized to time server 10.123.1.123" as per your configuration. sudo timedatectl set-ntp on sudo timedatectl status sudo systemctl restart systemd-timesyncd.service systemctl status systemd-timesyncd.service Join System to Domain If you have Webmin you can use Rejoin Domain (VA v7.2) but it more or less just runs the following command (Replace Administrator with an authorised AD User that can join systems to the domain): sudo net join ads join -U Administrator This relies on a correctly configured /etc/smb.conf You will probably want to move the resulting Computer object this creates in your domain from the default Computers OU to a more relevant OU given your OU hierarchy design in your domain. Setup Mapped Domain Security Groups under Access Rights in ESMC Configure Active Directory under Advanced Settings in Server Settings (v7.2) Map Domain Security Groups and assign Permission Setting Map Domain Security Group users (v7.2) Setup a Static Group Synchronization Server Task in ESMC Synchronization mode - Active Directory / Open Directory / LDAP (v7.2) Setup a User Synchronization Server Task in ESMC User Synchronization (v7.2) Troubleshooting The following can be used to test Kerberos login and LDAP GSSAPI whilst showing debug information, useful for troubleshooting. It destroys and existing Kerberos tickets for your user, obtains a Kerberos ticket for the specified AD user, lists obtained Kerberos tickets then performs LDAP Search by authenticating with GSSAPI. When troubleshooting Kerberos, you should always check the system time with the relevant Domain Controller (KDC) to ensure they are within 5 minutes of each other (by default). Replace eset.esmc with the AD User Account that ESET ESMC will connect under. Replace dc.test.local with your Domain Controller. Replace DC=test,DC=local with the Distinguished Name (DN) of the Base OU in your Domain where you want to list all child Computer objects of. kdestroy KRB5_TRACE=/dev/stdout kinit eset.esmc klist -f KRB5_TRACE=/dev/stdout ldapsearch -LLL -Y GSSAPI -h dc.test.local -b 'DC=test,DC=local' '(&(objectCategory=computer))' 'distinguishedName' 'dNSHostName' @tomasS @Peter Randziak

@Peter Randziak This appears to be resolved, turns out I missed out on some configuration in the hosts file. Thank you to @tomasS for the one-on-one assistance with this. I'll try to write-up a How To soon on how I configured this all so if anyone else is configuring this on a Linux component (non-VA) install, they'll avoid some of the mistakes I've made.

@tomasSWill sent unredacted log to you via direct message.

@tomasSThat ldapsearch command yields the same problem, it states "Matching credential not found" as it tries for ldap ticket but eventually finds krbtgt ticket. It then tries, and fails, to query non-standard DNS records for Kerberos using and eventually fails. This is after kdestroy. I had a more thorough krb5.conf but it failed to work correctly so I grabbed, and modified, a working one from a working test ESMC VA instance and modified it. [libdefaults] default_realm = TEST.LOCAL ticket_lifetime = 24h forwardable = true [realms] TEST.LOCAL = { kdc = dc.test.local } [domain_realm] .test.local = TEST.LOCAL It's a lot more minimal then we usually do but it's more or less the same as my working test ESMC instance against a test WS2019 DC. As for the user: UPN: eset.esmc@test.local NetBIOS Domain: TEST SAM Username: eset.esmc Account Options: User cannot change password Password never expires Account expires: Never We have security groups to minimise permissions of such users but I've tried it as nothing more than a member of Domain Users and even Domain Admins, ensuring to kdestroy between each test, so I don't think that's related. Also, I'm currently redacting information (search/replace), if there is a way to do this privately I can provide unredacted information.

@janoo Thanks for that, that explains the dependency as we as we're also having issues with Active Directory integration as well.

@MartinK Running ldapsearch with KRB5_TRACE revealed much more information Example: KRB5_TRACE=/dev/stderr ldapsearch -LLL -Y GSSAPI -h dc.test.local -b 'DC=test,DC=local' '(&(objectCategory=computer))' 'distinguishedName' 'dNSHostName' Despite kinit being successful and klist indicating valid ticket, ldapsearch with Kerberos tracing reveals the actual problem is "Matching credential not found" from the cache: Getting credentials eset.esmc@TEST.LOCAL -> ldap/10.123.123.1@ using ccache FILE:/tmp/krb5cc_1000 Retrieving eset.esmc@TEST.LOCAL -> ldap/10.123.123.1@ from FILE:/tmp/krb5cc_1000 with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_1000) klist $ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: eset.esmc@TEST.LOCAL Valid starting Expires Service principal 06/11/20 18:51:47 07/11/20 04:51:47 krbtgt/TEST.LOCAL@TEST.LOCAL renew until 07/11/20 18:51:43 I've redacted/replaced identifying information in logs.

@MartinK It feels like a hostname mismatch but the hostname of the ESMC linux instance matches the dNSHostName and servicePrincipalName of the Computer object in AD, will keep looking at that angle.

@MartinK libsasl2-modules-gssapi-mit is installed as per Server prerequisites - Linux (7.2) kinit runs successfully but using ldapsearch in the same described in the Synchronization mode - Active Directory / Open Directory LDAP (7.2) documentation triggers the same error. I created a lab environment and setup a WS2019 Domain Controller (ADDS) with ADCS and a test ESMC VA instance was able to connect. Next thing I might look at is GPOs as we apply baselines but I think the issue is more likely the configuration on our ESMC linux instance.

@Peter Randziak I have Mapped Domain Security Groups working but I'm having issues configuring a Static Group Sync Server Task but it fails when doing ldapsearch. SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) #011additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database) Normally I'd suspect a keytab or SPN issue with this but I've been reverse engineering the ESMC VA to see how it has it configured and I don't actually see a keytab anywhere? This would be a lot easier with better documentation.

Thanks for the link anyhow.

I'm very unhappy with the quality of the documentation and the level of support we're receiving for an enterprise setup, are there plans or products available that give us more than level-1 support?

Where is the documentation for getting Active Directory Integration setup for ESMC on Linux (Non-VA)?

Server prerequisites - Linux (7.2) winbind package is dropped as a dependency in 7.2, compared with 7.0 instructions, but it's still actually required for Active Directory integration.

I forgot to mention an important point regarding the "Repair ESET Agent" step. If you use PowerShell, you can change the "Start in" path to the UNC path of the ESET Agent source files but you'll have to contend with the PowerShell execution policy, script signing, SYSTEM computer object share permissions etc. If you use Command Line, instead of trying to mount the the share or something using script, you could cheat and redundantly package the Agent source files into an SCCM Package that you specify in said Run Command Line step. It's a bit wasteful and redundant, but it works. You might be able to find the MSI in cache or try to get the repair step working with the ProductCode too but we didn't go down that route to test that.

Attached is a screenshot of the hierarchy in the Task Sequence Editor. The "(P)" in the Uninstall Actions represents it was configured "With Password". This wasn't the one we used in Production, but one for testing and the one I described in the main post.

We use SCCM for our software deployment and we've always had problems doing major version upgrades of ESET products with it, we've had no luck with installing new Agent in-place over the top of old Agent, trying to uninstall old products and install new ones or using agent infrastructure to send our new policies to direct to new infrastructure etc. but we finally solved our problem using SCCM Task Sequences. The purpose of this topic to help those who were in our situation from having to go through the same we did. If this information is useful to you, or you're affected by the same problems I am, please make a comment and make your voice heard to ESET. I'm tired of the ESET upgrade/migration experience being , ESET needs to do better in both documentation and the MSI. Notes We have ERAS6, ERA6 and ESS6 and we wanted to upgrade to EMA7 and ESS7 which connects to a whole new separate and freshly installed instance of ESMC7. There is no connection between ERAS6 and ESMC7, we did a new build. We're using SCCM-CB/MCEM (2008) with Windows 10 Enterprise devices. We use automated packaging software to manage our SCCM Applications, to keep them source files up to date and to push updates via SCCM+WSUS. It sets up two separate Applications, one for each architecture (x86 and x64) as opposed to one application with multiple Deployment Types for each architecture. Adjust the task sequence to suit for your situation. A number of our systems are laptops with user-space VPN clients, so we designed our Task Sequence to suppress reboots until the end despite potential issues that could bring. Adjust the task sequence to suit for your situation. We use ESET Endpoint Security but adjust the task sequence to suit whatever applications you have installed and want to install. In regards to Uninstalling existing product, it's possible to use a PowerShell script to find the the ProductCode of the installed software based on the UpgradeCode (Powershell: Uninstall application by UpgradeCode) but the process below does not take that approach and just defines a new Action for each scenario permutation. Process assumes you have packaged your ESET products, including a customised install_config.ini for the ESET Management Agent. We do not have Supersedence set up for any of the ESET Products SCCM Applications, we couldn't get it to work because the Uninstall step of Deployment Types didn't work for some reason. I have no idea why running the exact command in a Task Sequence works and not via Application Deployment Type Uninstall step (both operate as SYSTEM in runtime). This has the result of the ESET Management Agent 7 being installed, in place, over the top of ERA6, which doesn't actually work, but we fix this by repairing the MSI in the following step. Task Sequence Process x86 (Add in Condition to only allow 32-bit editions of Windows) Uninstall ESET Endpoint Security 6 (Run Command Line) You can use a PowerShell script for all this logic or setup an Action for each permutation of the following: Each deployed version you want to uninstall Add in "Installed Software" Condition to this Action and select one of the old relevant versions of the x86 MSIs of a version you have deployed that you will be uninstalling in this Action. Take note of the ProductCode for the msiexec command, it is unique to that version-architecture combination. With Password In the event Agents don't receive the new policy to remove password, happened to us despite ERAS6 saying policy was applied. Without Password If you try "Without Password" version before trying "With Password" make sure to set "Continue on error". This logic can probably be better handled by a script. The command to be executed will be one of the following, depending on the situation: Without Password (Product Code is just an example, use the one for the version you're uninstalling) msiexec /x "{8E9AB319-74FD-490E-864F-21B29AEC6A90}" /q REBOOT=ReallySuppress With Password (Product Code is just an example, use the one for the version you're uninstalling) msiexec /x "{8E9AB319-74FD-490E-864F-21B29AEC6A90}" /q REBOOT=ReallySuppress PASSWORD=PassWordHere Install ESET Management Agent 7 (Install Application) Repair ESET Management Agent 7 (Run Command Line or Run PowerShell Script) The /i is deliberate, /f didn't work despite it seemingly doing an MSI repair. With Password msiexec /i agent_x86.msi PASSWORD=PassWordHere Without Password msiexec /i agent_x86.msi Install ESET Endpoint Security 7 (Install Application) x64 (Add in Condition to only allow 64-bit editions of Windows) Uninstall ESET Endpoint Security 6 (Run Command Line) You can use a PowerShell script for all this logic or setup an Action for each permutation of the following: Each deployed version you want to uninstall Add in "Installed Software" Condition to this Action and select one of the old relevant versions of the x64 MSIs of a version you have deployed that you will be uninstalling in this Action. Take note of the ProductCode for the msiexec command, it is unique to that version-architecture combination. With Password In the event Agents don't receive the new policy to remove password, happened to us despite ERAS6 saying policy was applied. Without Password If you try "Without Password" version before trying "With Password" make sure to set "Continue on error". This logic can probably be better handled by a script. The command to be executed will be one of the following, depending on the situation: Without Password (Product Code is just an example, use the one for the version you're uninstalling) msiexec /x "{632B1C53-E8E5-4F68-817C-EBA1E9098FB7}" /q REBOOT=ReallySuppress With Password (Product Code is just an example, use the one for the version you're uninstalling) msiexec /x "{632B1C53-E8E5-4F68-817C-EBA1E9098FB7}" /q REBOOT=ReallySuppress PASSWORD=PassWordHere Install ESET Management Agent 7 (Install Application) Repair ESET Management Agent 7 (Run Command Line or Run PowerShell Script) The /i is deliberate, /f didn't work despite it seemingly doing an MSI repair. With Password msiexec /i agent_x64.msi PASSWORD=PassWordHere Without Password msiexec /i agent_x64.msi Install ESET Endpoint Security 7 (Install Application) Restart Computer Remember to change it to "The currently installed default operating system" If you have multi-boot and the operating system running is not default you'll have to restart via a script instead. Process Create the Task Sequence. Ensure all relevant Content is Distributed. You can do this by selecting "Distribute Content" on the Task Sequence Decide how you will be deploying the Task Sequence. Will you have separate Device Collections? Will you be using the Planned Deployments feature or do deployment manually? Will you have a test Device Collection and a production Device Collection? Using ERAS6, deploy new policies, or adjust existing ones, to change the following settings for the following applications: ESET Management Agent Unset "Password protected setup" under "Advanced Settings" ESET Endpoint for Windows etc. Disable "Enable Self-Defense" under "Detection Engine" > "HIPS" Under "User Interface" > "Access Setup" Disable "Password protect settings" for "< 6.x" Unset "Set Password" for "< 6.x" Ensure Polices are deployed to relevant Agents before continuing by checking Statuses under "Applied Polices" of relevant Computers. Deploy the Task Sequence using one of the following methods with the following considerations: Phased Deployments with test and production Device Collections or do a Deployment to a test Device Collection, review results manually, then do a new deployment to production Device Collection. Ensure Task Sequence is not deployed to any systems that are already running ESET Management Agent 7. You may want to create a superset Device Collection that has a Query Membership Rule excludes said systems and limit your test and production Device Collections to said Device Collection. Make Deployment Available and set Assignment Schedule as per your requirements. I recommend setting the "Rerun behaviour" to "Never rerun deployed program", it's doubtful just rerunning the task sequence is going to be successful if it fails, a failure will most likely require intervention. Set User Experience "outside maintenance window" options as per your requirements. Task Sequence Deployment can be monitored in Monitoring > Deployments in SCCM Console. Our experience has been fairly positive in SCCM/MCEM 2006 when it comes to reporting useful "In Progress" information. We remediated failures manually.

I had some issues with the documentation and wanted to post my experiences and resolutions and some additional advice in case anyone else has to go through it. Also, can the doc team please spend more time more on QA of the doc content? MySQL installation and configuration (7.2) "For MySQL 5.6.22 and later:" also includes MySQL 8 despite MySQL 8 having it's own section, although correct, it's a tad vague as one could interpret it as "and later within the major version" like I did initially. server-linux-x86_64.sh Database Configuration Checking Some of the error string are unhelpful (Eg: "The database server is not configured correctly. Please check the documentation and reconfigure the database server as needed.") Apache HTTP Proxy installation - Linux (7.2) Step 8 refers to /etc/apache2/mods-enabled/proxy.conf but it is probably meant to refer to /etc/apache2/conf-available/proxy.conf as the proxy definition was defined in that configuration file for these instructions. The "Forwarding for ESET communication only" section also has a block which refers to "allow forwarding all communications" which should be it's own heading but isn't. It has a big block of Apache configuration that look identical to the first but the first ProxyMatch tag is missing an open square bracket, don't accidentally copy it instead of the primary one at the stop or you'll get errors. KB6783 Add or remove password protection of ESET security product settings from ESET Security Management Center (7.x) Figure 2-1 is wrong, it's highlighting the blue circles instead of the grey circles as per the instructions. Deployment steps - SCCM These instructions aren't good enough, it doesn't work in practice when it comes to the entire lifecycle of the product, especially uninstallation and superseding previous version of the product. Installing agent in place, uninstalling old products first or using old policies to redirect agents to new servers all have their own problems. In the end, we did our upgrade/migration using SCCM Task Sequences and scripts, I'll post a separate topic on how I did that for others because we had the same saga with our v5 to v6 years ago too.

I'm noticing this too, repairing the MSI Agent v7 install restores functionality. I think I'm just going to have to utilise a SCCM Task Sequence and PowerShell to perform this migration...

These specific machines are for I.T. staff and are manually installed via Windows installation media (except for laptops, they are deployed by SCCM Task Sequence). Given they are for I.T. staff they have many things on there which could be causing issues (Eg: VMware Workstation, WinPCap, USBPCap etc.). That said, one of the workstations is a manual build but isn't being used at the moment and, despite this, has the alert pop-up twice in two days. One laptop affected is just a Dell Latitude.

@MartinK We installed it right over the top, install_config.msi along with Agent v7 MSI was used.

We also get situations where "Stop Managing (Uninstall ERA Agent)" Task from ERA6 seems to remove it (Task remains as "running" in ERA6) but it's still listed as installed, even after reboot, just like the other methods.

@MartinK I've left the latest test computer on for many hours in this state now and not once has it tried to connect to new ESMC instance nor did it seem to ever try (according to trace.log). So how do I fix this problem? Is there a way to forcefully apply configuration (again)? ecmd or something? What do I do from here?