We'd love to hear about it! Click here to go to the product suggestion community
Two issues have once again reared their ugly heads this week. I was building two new Macs running MacOS 10.15.x, and found that after the initial install via a USB-C NIC, we could not get the laptops to connect via Wi-Fi.
At first it looked like the very presence of the wireless adaptor stopped it from working, and removing all network devices except the USB-C NIC was the only way to fix it.
We have also found that even a simple IP address change is enough to completely break RMS. For instance, and I'll make up IP addresses here but accurate enough to be relevant:
1. On IP 192.168.1.1, I can use the SEC console to request an update, and I will see via a tcpdump on the Mac that traffic gets to the laptop and it checks for updates
2. Put in an exclusion of that IP address on both DHCP servers and force a renew. The IP address changes to 192.168.1.2.
3. A local "Update Now" will work, as well as our automated check every 10 minutes.
4. However, in the console the machines IP address has not changed, a SEC "Update computers now" does nothing, and no traffic is shown on the client side tcpdump.
The second issue we have yet again observed is the repeated creation of duplicate Mac computer objects. Typically we see the object create by the folder with AD sync enabled. When the client connects first time its a toss up whether the server will "enable" this object or just go ahead and create a duplicate, usually in "/Unassigned" so no policy gets assigned for updates.
It's quite frustrating that his has been going on for years, Sophos appear to have done nothing to address this, and do not even offer a facility to merge these objects.
Feedback would be useful, as I'm sure some of my Mac supporting colleagues will have seen the second issue at least, if not the first as well.
We are running on-premise SEC 5.5.0 and deploying Sophos 9.9.5 on the client side.
haven't seen the first half of the first issue. As for the second half - the SophosMessageRouter should report the current IP when it's (re-)started. Would have to check how it behaves when going from wired to wireless or v.v.
AD sync is tricky, as is merging of computer objects. Both together ... well ... Usually name, domain/workgroup, OS version are significant - though the latter isn't really relevant with Macs I think.
In reply to QC:
Just updated one of the affected laptops from 10.15.1 to 10.15.2. I disabled wireless and put it back on to a cabled network connection. After the restart the console does indeed show the new LAN IP, but RMS is still broken. Local pull via CIFS works just fine. Running tcpdump locally and performing operations on the server shows no traffic hitting the laptop:
sudo tcpdump -n host <IP OF SEC SERVER>
In reply to MRC Cognition and Brain Sciences Unit:
Just throwing ideas out there but if you perform a DNS lookup on an affected laptop from SEC, does it resolve to the new IP or old IP?
In reply to MEric:
The new one. DNS seems to be working okay. What may "fix" it would be to delete that computer object, and the AD synced object, then uninstall the client, and then re-install. But we can't keep doing that every time it's IP address changes. ;-)
Hi MRC Cognition and Brain Sciences Unit
I would suggest you open a support case for this as this might require to check on few logs on the endpoint as well as on the server. Please PM me the case number once you have registered the same.
In reply to Shweta:
Is there an update to this as to root cause? We are experiencing similar behavior (duplicates caused by IP/Hostname changes) and seemingly ineffectual "Update computers now" submissions to the endpoints from the console. Was there a solution provided?
In reply to Robyn Smith:
Hi Robyn Smith
We have not received any case number on this issue from Howard and not sure whether the case was opened or not.
Would you please suggest if you opened a case for the issue to work on. If yes, please PM me the case number, so I can take look at the case.
We didn't get to the root cause, or rather fix, for the duplicate computer object issue, although a contributor was the "Workgroup" of the machine.
When a Mac is bound to AD using the built-in Apple software, the "Workgroup" gets changed to the name of the domain it has joined. During AD sync, this matches the computer object and you have a better than average change of the object that's activated being the synced computer object.
If you join the Mac to the domain using the Centrify software, the "Workgroup" remains as workgroup. It's not 100% of the time, but since this doesn't match, then a duplicate object is created. Additionally, we found AD synced objects from a machine that had already been joined once before, and hence have an OS attirbute set, does not seem to understand what MacOS 10.15.x is, and instead picks the first OS in its list, so my synced Mac object, in grey, shows the OS as "Windows Vista".
Hopefully the next version of SEC, 5.5.2, improves on this...
Regarding IP address changes causing RMS to fail, amongts trying a few things to work around this, we had a couple of DNS related issues:
1. In DHCP, we had an incorrectly configured domain suffix, comprising of two domains separated by a space. This caused reverse lookups on wireless only to be broken.
2. In the DNS reverse lookup zone, some of the objects there had incorrect permissions set, essentially making the owning client computer the owner of that object, so no other could update those DNS entries. This broke Sophos.
2a. We were given a workaround to try, which involved tweaking the way the Centrify client handles these dynamic updates. For new objects, this actually led to the situation where the Mac computer itself was the owner of the DNS object, and hence no others could update it. This was abandoned quickly.
2b. Instead, we deleted all of the DNS entries that did not have the DHCP server itself as the owner, and this fixed both the DNS reverse lookup creation/updating problem, and also allowed SEC to correctly update the registered computers IP and restore RMS.
One remaining issue I observed was that when a computer that is currently connected via RMS has it's IP address change, although the console updates to reflect this in a few minutes time, typically it takes a little longer than that for functionality to restore i.e. the console shows the correct IP, and with a tcpdump running on the client, when I perform a remote update, I see no traffic hit the client. This does ulimately restore itself, but I see some odd behaviour, such as tcpdump traffic detected, but not update in the GUI window for the update status.
A reboot after the IP change clears this up immediately, but at this point, that is the least of our worries. We can now switch between cabled and wireless connections at will, and typically within 5 minutes functionality is restored.
Thank you for sharing your findings and resolution.