SEP (14.2 RU2 – 14.3.0) under macOS 10.15 & 10.14 not communicating with SEPM

[Scott K]

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

[ALee]

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.

Alan

------------------------------
Sr Manager, Product Management
------------------------------

[Scott K]

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

[ALee]

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
------------------------------

[Scott K]

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

[Scott K]

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.

[ALee]

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
------------------------------

[Scott K]

Thanks, Alan. Hopefully, this can be a relatively quick resolution.

[Gwyneth Llewelyn]

Hi! I know I'm piping in late, but I wonder if you managed to fix your issue... That last error you have (related to the softwareupdate CLI utility) is related to, well, system software updates. In my case, I have that error too, which prevents macOS to contact any update server whatsoever, and although I know that there are pending upgrades waiting for an eventual connection, I cannot list them with the softwareupdate tool - nor get System Preferences to open, either (it just spins the usual 'beachball' and does show a few icons, but becomes unresponsive before I can do anything).

I've pretty exhausted all the searches I've made on Google about this specific issue - and trust me, I tried out many 'solutions', including disabling SIP, deleting everything under /var/folders/ (and letting macOS 'regenerate' those temporary files again), starting in Safe Mode/Single-user mode/Recovery Mode, reading and writing parameters to system configuration files, resetting NVRAM, etc. etc. etc. - so I was curious how you fixed your own issues...

My feeling is that it must be something very easy to fix.

And aye, it affects other parts of the operating system, not only macOS system updates. As said, System Preferences (because it does contain the Software Update preference pane) will not work; Time Machine hiccups once in a while; etc...

------------------------------
---
I'm just a virtual girl in a virtual world...
------------------------------

[Cesar_Americo]

I have been facing in my enterprise env a pretty similar case since long time, not sire if since sep 14.0 or 14.1. We export a sep package from console and use JAMF to push it just like historically we do without problems. We realized client never get a policy from SEPM even not having any kind of communication issues per tests we do via http and https 80 and 443 ports. This is totaly client side/OS. We have a peculiar behavior, sometimes client must be launched/opened several times, it seems that is need to something get loaded on background to make it work and some times didn't. There is also case of "authorizing kernel extensions" error message, which keeps it not health. There is a fix button which makes things worst. About 8k Mac computers with Not Available definitions and problems to communicate with manager.

I had a first related case with Symantec which got escalted to DEV team on 14.3 that was closed with information that 13.mp1 would get fixed, but does not.

Now a second case opened since a month ago, the tech seems to have some instructions to not escalated it and dismiss anything possible on first level. Lot of webex session without productive actions, just random senseless guess without resolution, making every time same questions and spent time, they don't want to escalate the case and don't anwser the why. Our organization definitivily looking for switch that application. The Symantec support that was never a great model got worst since Broadcom aqcquisition. Totally painful. We have no help to get it fixed and there is no light about if sometihng is gonna be done about it.