Thanks, Alan. Hopefully, this can be a relatively quick resolution.
Original Message:
Sent: 06-04-2020 10:25 PM
From: Alan Lee
Subject: SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM
Scott, thanks for the update. Let me see if I can reproduce it. I'm currently on 10.15.5 with build 510, not seeing this error but let me check if there's a associated defect on this.
Alan
------------------------------
Sr Manager, Product Management
Original Message:
Sent: 06-04-2020 03:28 PM
From: Scott Kraft
Subject: SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM
Support was able to find the following error:
2020-06-02 11:47:14.415 PDT ERROR smc.SMC [2020-Jun-02 11:47:14.415133] [ERROR] The NetPortManager failed to start failed. [thread:0x70000232b000]
Debug logs from SymDaemon and GatherSymantecInfo did not point to the cause of the error.
I asked support to test communications of a managed SEP client under macOS 10.15.5 client with a SEPM to see if they could reproduce the problems I am seeing since applying Apple's Security Update 2020-002 released March 24, 2020 (https://support.apple.com/en-us/HT211100). I was told that Broadcom migrated support's internal labs to AWS and they no longer have access to a Mac environment. What?!?! It is not acceptable for an enterprise product. Support must have access to all supported clients for testing and troubleshooting.
My case is being written up for development to review and possibly make a code change.
Totally unacceptable! Renewals are now at least double with no advanced notice (Problems with Renewing Symantec Endpoint Protection. Tier 1 support has gotten significantly worse. Support no longer has access to supported clients to test and troubleshoot bugs and problems. After 19 years with Symantec Endpoint Protection (Norton AnitVirus Corporate Edition 7.x originally), it is definitely no longer an enterprise product and I can no longer recommend Symantec Endpoint Protect for any environment. I will be recommending my organization switch to a different product in 2021.
Original Message:
Sent: 05-29-2020 06:12 PM
From: Scott Kraft
Subject: SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM
Thanks, Alan. I started to observe these problems with Apple's Security Update 2020-002 for macOS Mojave (10.14.x) and Catalina (10.15.x) released March 24, 2020. I recollected the logs (client and SEPM) with macOS 10.15.4 and 10.5.5. Hopefully, support can find something in the logs this time.
Thanks,
Scott
Original Message:
Sent: 05-26-2020 08:25 PM
From: Alan Lee
Subject: SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM
Scott,
I've managed to use Let's Encrypt wildcard certificate (but no SAN for internal IP, as they don't allow) on my test SEPM. It maps to internal IP using my dnsmasq. Testing was done on SEP 14.3.558 on macOS 10.15.1. The SEP client did managed to connect after a reboot with Sylinkdrop. Tested with both disabled and enable certificate validation.
In your case, the configuration sounds right with matching wildcard certificate and MSL. SAN is not important, since you have them matching FQDN and wildcard certificate and not using IP. The only different is you have multiple SEPMs defined, which I didn't try. Hopefully you have supplied a crash dump to support team, so that we could investigate further on the behaviour.
Alan
------------------------------
Sr Manager, Product Management
Original Message:
Sent: 05-26-2020 05:54 PM
From: Scott Kraft
Subject: SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM
Hi Alan,
We use a wildcard certificate (*.<Internal_Domain_Name>.net) and the management server list uses <Hostname_of_SEPMs>.<Internal_Domain_Name>.net. Using various web browsers (Chrome, Firefox, Edge, & Safari under macOS) all accept this certificate without any warnings and considers it to a valid certificate (such as https://<Hostname_of_SEPM>.<Internal_Domain_Name>.net/secars/secars.dll?hello,secars). The wild card certificate doesn't have a Subject Alt Name field, but it does have Subject with the following values:
CN = *.<Internal_Domain_Name>.net
OU = PositiveSSL Wildcard
OU = Domain Control Validated
Yesterday Broadcom support escalated my case to a Support Engineer 2 based in the US, which is currently reviewing the case and I am sure I will get further progress compared to tier 1 support.
Thanks,
Scott
Original Message:
Sent: 05-26-2020 01:00 AM
From: Alan Lee
Subject: SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM
Hi Scott, does your certificate and management server list matches? For e.g. in SEPM self sign certificate, it shows the Subject Alt Name with these details. When I get sometime later, I will try Let's Encrypt to see if I've problem with my macOS connection.
------------------------------
Sr Manager, Product Management
Original Message:
Sent: 05-22-2020 06:49 PM
From: Scott Kraft
Subject: SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM
I have already been working with Broadcom support with no progress, therefore seeing if anybody has some suggestions that I haven't tried yet.
Problem: Starting with Apple's Security Update 2020-002 for macOS Mojave (10.14.x) and Catalina (10.15.x) released March 24, 2020, we have two major problems with SEP clients on macOS systems with communicating our SEPMs. First, vast majority (>95%) refuse to communicate with either SEPM we have despite working for many years and no changes to the Communication/Management Server List policies. Second, new SEP installs (via remote push by SEPM, exported client, and installing unmanaged SEP client and then updating the communication settings) will initially communicate with one SEPM, but then refuses to communicate again and doesn't receive a Symantec Policy Serial Number (and acts more like an unmanaged client).
Affected SEPM versions: 14.2 RU2, 14.2 RU2 MP1, and 14.3 (14.3.558.000/current)
Affected SEP macOS client versions: 14.2.5323.2000, 14.2.5569.2100, 14.2.5580.2100, 14.2.5587.2100, and 14.3.510.0000 (current)
Affect macOS versions: macOS Mojave (10.14.x) and Catalina (10.15.x) versions after receiving Apple's Security Update 2020-002 released March 24, 2020 (https://support.apple.com/en-us/HT211100)
SEPM Configuration: We use a valid commercial wildcard certificate because of internal security requirements and cannot use self-signed certificates. We have no communication problems with our Windows systems.
Troubleshooting: I created a new group on SEPM for troubleshooting with the default Virus and Spyware Protection, LiveUpdate, and Memory Exploit Migration policies (minimum required). For the Communication or Management Server List, I created one that uses <FQDN_of_SEPM>:8014 (with HTTP and not HTTPS, because years ago SEP under macOS would not accept any certificate, self-assigned or wildcard; also tried using <FQDN_of_SEPM>:80). I am using a Mac laptop with 10.15.4 (all updates from Apple installed), connects via Cisco AnyConnect VPN, built-in Apple firewall disabled, uninstalled SEP (also ran RemoveSymantecMacFiles because the uninstaller doesn't remove all files, especially with 14.3.0), and installed the SEP client (tried 14.2.5323.2000, 14.2.5569.2100, 14.2.5580.2100, 14.2.5587.2100, and 14.3.510.0000; all have same problem) via (1) remote installation from SEPM, (2) package exported from SEPM, or (3) installed the unmanaged client and then pushed the communication settings. All results with the same result of the SEP initially communicating with a SEPM then refuses to communicate again and doesn't receive a Symantec Policy Serial Number (and acts more like an unmanaged client).
Support did find the following in the logs submitted, but no suggestion on a resolution (other than steps I have already taken):
softwareupdated[580]: SUOSUServiceDaemon: Error reading /var/folders/zz/zyxvpxvq6csfxvn_n00000s0000068/C/softwareupdated/com.apple.OSUpdate.SUOSUServiceDaemon.state: Error Domain=NSCocoaErrorDomain Code=260 "The file "com.apple.OSUpdate.SUOSUServiceDaemon.state" couldn't be opened because there is no such file." UserInfo=
Since support hasn't been helpful thus far, any suggestions or ideas would be appreciated.
Thanks,
Scott