Active Directory synching for SGN 5.50.8.13 error

Finally got a response back from tech support yesterday after complaining to our sales guy about no response for a week and a half.  Simple fix, which is annoying and SHOULD have been made available on the website. I’’’’m gonna write documentation for Sophos and bill them accordingly….

This issue has to do with our Sophos/Active Directory synchronization and how we need to synchronize the entire AD tree at some point during the night so it has a baseline. We currently have scheduled tasks setup to sync only certain OUs every 30 minutes because we are rolling this out to a few groups at a time who are not physically located in our office.

The fix is to download SGNKeyTester (specific to the version of SGN you are using) – we use 5.50.8 so if you need that one, I can provide it otherwise Sophos will have to direct you to their FTP site to download it (good luck with that). So, you download the SGNKeyTester, run it on your Sophos server – login as the MSO account (not one that you elevated, it has to be the actual MSO account). I have a screen shot of the SGNKeyTester but it won't let me paste it here.

Select “All Objects” radio button and click “Check only structure keys”, it will display any “Wrong Entries” in the bottom part of the screen, select one of the wrong entries and click “Additional Infos” (gotta love that misspelling!) and then “Repair Selected” (continue selecting the wrong entries listed and clicking “Repair Selected” until they are all fixed). Then click on “Check group and structure keys” and continue the “Additional Infos” and “Repair Selected” until those are all fixed.  Continue with the same process for “Check user and structure keys” and “Check computer and structure key”. Once you have done that, your problem is fixed and your AD syncs should work again.

The key to prevent it from happening again is to setup a scheduled task to run at say 1:00AM to synchronize your entire AD structure. That way it has a baseline – at least that’’’’s what tech support said. Then you can sync just the OUs that are using Sophos as necessary during the day.

HI there,

thank you very much for submitting this request and discussing the issue.

Actually I want to add some information to the reply from JuJo:

1. JuJo is referring to an internal tool. The tool should therefore only be distributed by the local help desk.

2. The keytester tool must not be used without any instructions and advice else some unpredictable side effects might happen

3. The keytester cannot fix all issued that might happen around the sync which would then require further steps that are dependant on the technical situation.

As a result of the above mentioned points we ask all customers to open a ticket when facing a issue with the sync. The local help desk will then provide next steps (eventually the keytester, if reasonable) to solve the issue.

Please note that sync issues can have different reasons and should therefore be inverstigated case by case; however, the mentioned approach to sync the whole AD is the best way to avoid side effects.

Regards

Dan

One other thing I just learned is that syncing with AD does not sync passwords - only objects (computers or users moving from OU to OU). So, I basically changed my AD sync to run only one time at 1AM so we'll see how that goes.

They said Sophos SGN knows a user's password as soon as the user changes it, but I've not seen that consistently. So, again, we'll see how that goes.

I have had this error for a couple weeks now. It is not new but it has been a problem with safeguard for several versions now. Sophos does not like to admit it but there is a sync issue and they do not know how to fix it. The key tester tool does not always work. I have worked with Sophos on this and the solution they come up with is to delete the object with a problem from the sg database and re sync so it syncs up. This can be an issue as I can only trrack it down to a container not to the individual computer

While this does usually fix the issue does not fix the probem that caused it in the first place. It also deletes all the keys for the ou out of safeguard so you have to make sure you back it up first in case you have a problem with a computer and have to challenge/response it.

To me this is not a fix but as I have been using safeguard enterprise since 5.2 and this issue has been around almost as long I don't expect them to be able to fix it.  I don't think they really know what causes it but they always says it will be fixed in the next version. :smileymad:

Got agree with Mike on this one, was meant to be fixed in v5.4 but we're still getting this issue with 5.5.

Usually relates to a workstation that's been moved in AD or to user accounts that have been renamed or moved to another OU in AD.

 I haven't figured out why it happens but you can usually narrow it down to to a particular OU and compare the contents of that OU in Safeguard against what's in AD -  not much fun but you can usually find the missing user or duplicate workstation.

As mentioned above synchronising the whole  of AD rather than individual OU's seems to minimise it happening.

We seem to have finally got this working. But it came after having to delete the problem OUs out of the SG database. Then support  changed my auto sync script to do all at once rather than the way we had been doing it in sections. They had me set it up this way in 5.4. So far I have been syncying for 2 weeks now without an issue. But I also incrased to every 3 hours rather than once a day.  

can you send me the 5.508 version, I'm having that issue too..I have the 5.40 version but I know it is version specific....

thanks

Hi awest,

as already mentioned the keytester is an internal tool!

Please be so kind and contact the local support so that the issue can be properly analyzed and the root cause can be determined. In case that the problem cannot be solved directly they will also provide you with the keytester tool if required.

@all: The recommendation for AD sync is still to import the whole directory as this is the best way to recognize changes in the AD (rename, move, delete). Doing a full sync will ensure that no actions happen outside the scope of the SGN AD import once they happen. If this is not done further changes might be done to the object which can hardly be determined when finally importing the object at a later point of time.

Also please keep in mind that even though an object is not synchronized into the Management Center it will report back showing up under Autoregistered. At this section it is already possible to assign policies to ensure that all settings are applied to the client. As soon as the AD synced the object is automatically moved to the right place.

Regards

Dan