Mac - IP address change on client causes RMS to fail, and again with the duplicate Mac computer objects

Hello Howard,

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.

Christian

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>

Howard

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?

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. ;-)

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. 

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?

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.

Hi MRC Cognition and Brain Sciences Unit 

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.

Hi,

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.

Hi MRC Cognition and Brain Sciences Unit 

Thank you for sharing your findings and resolution.