Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 12247 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AD sync and multiple policies

JTech

Howdi. If I have a folder in Enterprise Console 5.1, which is synchronizing my client machines from multiple AD OU's, is it possible to have systems in the synchronization to have different policies, AV policy in this use? I went and made a new group with the correct policies, and then to move the machine out of the sync folder in Enterprise console, only to have "Unable to move - the following computers are part of a synchronized group and may not be moved". The only way I can see around this is to either change the synchronization.. which is a lot of work due to multiple OU's OR move the single machine in AD to a new OU, outside of the synchronized folder.. which in itself has knock-on complications. Anything I can do? Thanks.

:36227


This thread was automatically locked due to age.
  • 0

    Hello JTech,

    as you have seen AD Sync mirrors the AD structure below the sync'ed OU/container by creating corresponding subgroups. A computer belongs to and is "fixed in" the (sub)group associated with its container. You can neither move the computer "outside" nor "within".

    The basis for policy assignments in SEC is groups. Thus you can apply different policies to the subgroups - thus if you have a single machine which needs different settings you'd have to create an additional OU (usually as sub-OU) in the synchronized folder.

    HTH

    Christian

    :36233
  • 0

    Im just going to reuse this thread since it pertains to my question. If its rpeferrred I create a new one, please let me know and Illdo so in the future.

    Same boat as JTech. We want to avoid creating additional OU's just for AV policy reasons but want to keep sync on for ease of managment. Is there anything down the road to make this a feature and if not, for what reason(s) ? For the time being, would  setting the endpoint policy manually be a suitable workaround, even though it will constantly flag on the console?

    An example would be as opposed to a general "Order Entry Servers" OU policy which consists of the application server, batch server, as well as the SQL servers we would like to create different exceptions per server role. The batch servers dont need the SQL exceptions, SQL servers dont need the Application Server exceptions and so on. As I understand it, the less unecessary exceptions the OnAcces scanner has to look for, the better perfomance.

    Thank You in Advance.

    :51320
  • 0

    Hi,

    Apart from either not using ADSync or creating sub-OUs for excpetions, making the computers use a local config is about the only thing you can do.

    In the 'core' database, e.g. SOPHOS521, SOPHOS52, etc, (http://www.sophos.com/en-us/support/knowledgebase/17323.aspx) there is a table called 'ComputersAndDeletedComputers', this has a column called: 'PolicyManagementType'.  If you update this to be a 3 (default is 1) for a given computer the computer will show as locally configured.  E.g. for a computer called computera, in  SEC 5.2.1+ instalation with a SOPHOS named local SQL instance:

    sqlcmd -E -S .\sophos -d sophos521 -Q "update computersanddeletedcomputers set policymanagementmype = 3 where name='computera'"

    May give you something to try.

    I suppose another option would be to have an updating policy linked to the group, e.g. \\servera\sophosupdate.

    As required, servera could resolve to a different CID, possibly with a a savconf.xml in it to configure SAV?  I appreciate this is pretty hacky and relies on split dns/host file hacks.

    Regards,

    Jak

    :51322
  • 0

    Apreciate the quick response Jak. I think I'll just deal with the policy notifications and just document the reasons so the console will still tell me excatly what is different and it will most likely ring a bell.. (well hopefully)

    :51324