Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrade.
Please accept our apologies in advance for any inconvenience this might cause.

AD security groups for SEP policy control

Created: 14 Feb 2013 • Updated: 25 Feb 2013 | 15 comments
Language Translations
Sean_Moore's picture
+4 4 Votes
Login to vote

Concept:

Use Active Directory security groups to assign SEP policies. This concept demonstration use's Application and Device Control for user level device management.

Knowledge Required:

  • Active Directory Users and Computers
  • Microsoft Group Policy Management
  • Windows Registry
  • SEP 11 or 12
  • Application and Device Control rule development

SEP Client Modes:

User Mode: SEP client intial registration with the SEPM is in User Mode with a SEP package deployed to the endpoint in User Mode.

Computer Mode: Default client installation.

Switching from computer mode to user mode after installation does not allow for the client to always retain this mode.

 

Active Directory Users and Computers

For test purposes to satisfy the functionality of this concept, create an OU and move a few users into the OU who will be part of the concept.

Create another OU and create three security groups which define what acess level the user will have on USB storage devices.

 

Policy Model:

4 x Application and Device Control policies for USB management:

  1. Default - A SILVER USB flash drive is permitted for use by any user with Read/Write access.
  2. Restricted - all USB devices are blocked upon connection.
  3. Read Only - A specific BLUE USB flash drive is permitted for specific users with Read Only access.
  4. Read/Write - A specific BLUE USB flash drive is permitted for specific users with Read/Write access. 

Hardware Reference:

For both the silver and blue USB drives the Device ID should be obtained from either within Windows device manager or using the DevViewer tool which is available on the SEP media. Do not use the Class ID for reference of the device. Add both of the Device ID's into the SEPM database.

 

Device Control Policies:

Use a mix of device control and application control to allow silver (all users) and blue (for certain users) and block everything else at the time of connection. Device control will control the actual connection of the device and the application will grant the level of access once a device is connected successfully.

 

 

Active Directory Integration:

Active Directory integration is required. Configure your SEPM to read from the AD domain(s) as required to import your users.

 

Import your users OU as a client group within the SEPM client group hierarchy. Once the Users are sync'd (can be done manually by right click on the imported OU) then deploy the User Mode SEP client to their machines.

 

Location Awareness:

Use the security groups in AD as the mechanism to determine which group a user belongs in order to apply the correct policy set.

This is achieved by using multiple locations within a client group. 

Create three additional locations.

  • Default
  •    ADC Policy = USB Default
  • Restricted
  •    ADC Policy = USB Restricted
  • Read
  •   ADC Policy = USB Read Only
  • Write
  •    ADC Policy = USB Read and Write

The conditions that will be required for a client (user) to use the locations and the policy set assigned to each will be a check in the registry for a value of a  certain registry key. 

The registry to use in this demo is HKLM\SOFTWARE\Symantec\DeviceControl\USB

The value of the key will be 0=default, 1=Read, 2=Write, 3=Restricted.

The condition created will read the registry key value when the user logs on and the SEP client starts. The client will automatically be associated with the location depending on how the registry value is set. The SEP client will then adopt the policy set assigned to that location. In this case the Application and Device Control policies that we have created.

Registry Settings:

The registry settings are applied by using Group Policy Objects. The group policy that is applied is a change to the user configuration within the group policy. When a certain group policy is applied it alters the value of the registry key used for location awareness conditions. Group policy can be scoped to be assigned to users with permissions to recieve the GPO. 

Group Policy:

Create four group polices: for Default, Read, Write and Restricted. 

Each individual GPO will write a registry value on the client machine when the user logs on. 

Use the GPO scope's to ensure the correct GPO is applied to the client machine at logon.

The default will be applied at the highest level with a presedence of 1. Read, Write and Restricted will be applied directly to the users OU and enforced.

 

The scope is set on each as follows:

 

Default

Read

Therefore if the user does not belong to any of the defined secuity groups of read, write or restricted the default GPO applied. This default GPO writes the registry key value of 0. This means that a user has read/write on the silver USB drive but all other USB devices (storage) are blocked.

The DeviceControl Read policy writes the registry value of 1, write = 2, restricted =3.

With the Read, Write and Restricted GPO's authenticated users scope have been removed. You only want to scope the GPO to the individual groups to ensure complete control of the users policy assignments within SEP.

Group Policy Settings:

Editing the GPO for DeviceControl Write. Under User Configuration -> Preferences -> Windows Settings -> Registry there is an entrie to update the USB registry key value to a value of 2.

The path of the registry key is in the HKLM hive. This is because the SEP location conditions for reading the registry are pre-set to HKLM and cannot be changed to read the HKCU hive. So the HKLM registry key is set for this reason. 

 

Example: This is the condition for the DeviceControl Default policy.

 

SEP Locations:

SEP locations should be configured as follows:

 

The default client group will have just the single default location with the DeviceControl restricted policy applied. This will ensure that if the machine is logged on locally, because the SEP client is in User Mode and the account used is not within AD then the client will use the Default group policy settings. So even local administrators will not be able to write to any USB device.

 

End User Experience:

With this now in place, one of our users logs on to a workstation. The registry is referenced by SEP and the location changed appling the policies associated with the location and the level of access to the USB drives authorised for that user.  

This concept can be used to apply any policy or control the SEP client in any way neccessary in your environment.  This is also allows for operational overhead to be reduced significantly as helpdesk support can assist by moving users into security groups to control a 'SEP profile' associated for each user.

This can also be applied a the computer level in computer mode. 

The principal functionality of this solution is to write a registry value based on a GPO which can only be applied to users within a specific security group and for SEP to reference the registry value for location conditions.

 

Enforcement & Monitoring:

You can run reports from within SEP and now Active Directory to establish which users have which level of access.

I also use Critical System Protection to monitor the Active Directory for changes made and schedule reports from CSP. CSP is also ideal for protecting the registry keys.

You will need to protect the registry key to only allow svchost.exe to manipulate the registry keys that you define, preventing a knowledgable end user from altering the registry key to gain temporary access to a USB device.

 

 

 

 

 

 

Comments 15 CommentsJump to latest comment

yang_zhang's picture

Good article!

If a forum post solves your problem, please flag it as a solution. If you like an article, blog post or download vote it up.
+1
Login to vote
Milan_T's picture

This shaws haw we can be configure and control GP with the help of AD and SEP to improve infra IT security.

Really good information and study of SEP and AD. 

0
Login to vote
Ambesh_444's picture

Good article !!!!

appreciated and good luck for next..

 

Thank& Regards,

Ambesh

"Your satisfaction is very important to us. If you find above information helpful or it has resolved your issue. Please don't forget to mark the thread as solved."

0
Login to vote
SUPPORT-2-SUPPORT's picture

Hi Moore,

Thanks for sharing this useful article but have on concern.

We are planning to integrate AD with our SEPM RU2 and all clients are in computer mode then wht you suggest on this suitation?

Does we need to redeploy the package of user mode or by converting from computer to user mode from SEPM itself it works.

 

 

Regards,

S2S

 

Please don't forget to mark your thread solved with whatever answer helped you.

0
Login to vote
Sean_Moore's picture

This concept can be used in either usermode or computer mode. Because the GPO is applied based on the users AD group membership and manipulates a registry key within the HKLM, this is transparent to which mode you decide to use.

Therefore there is no need to re-register your SEP clients in user mode to achieve this. 

User mode is good when you want to apply policies on a per user basis but not via AD.

MCTS,MCSA,ACSA,SCS,STS
SME - SEP/SCSP/MS-BITLOCKER
0
Login to vote
MKV's picture

Hi Sean,

We are planning to deploy the machines in computer mode initally & proabably a certain group of users to have user level control.Will this be achievable in similar method.

Please note that we use locaation awareness feature to distinguish between VPN/Office etc as well.If so will this contradict.

0
Login to vote
Sean_Moore's picture

You can use this concept in either Computer Mode or User Mode. The underlying mechanics to this is for a registry setting to be set for which SEP can reference using location awareness. You can apply the same conditions for your VPN/Office locations that you currently have with the addition of 'AND' ing the conditions of VPN / OFFICE with AD GROUP 1 / AD GROUP 2 etc.  

User mode makes it simple to follow the user however the disadvantage with the synchronsation of users or computers from active directory is you lose a licence seat from the pool for each object that is imported from AD to the SEPM client groups whether the object is and active client or not.

Therefore using the standard setup of adding clients in computer mode without sync from AD and using this concept will work well for you. I have already implemented the solution in this way which proved successful.

MCTS,MCSA,ACSA,SCS,STS
SME - SEP/SCSP/MS-BITLOCKER
0
Login to vote
MKV's picture

Hi Seane,

Thanks for the explanation.

What I was thinking is to syncronize the computers alone from AD after deployment to maintain the structure & then use the device control for special users alone.I am not sure whether this is a scrambled thought. , but what is your opinion?

 

0
Login to vote
Sean_Moore's picture

Basic workflow attached.

 

Yes that will work fine, just have these location awareness conditions within a specific client group for your 'special users' although if you mix Computer Mode with User Mode, Computer always wins. 

I suggest sync all computers in that case and then just add your 'special users' to the 'special user group' in AD. Job done :)

Screen Shot 2013-03-28 at 15.49.58.png

MCTS,MCSA,ACSA,SCS,STS
SME - SEP/SCSP/MS-BITLOCKER
+1
Login to vote
MartinHache's picture

Nice Job Sean :

I have a question , where i find the key registry for Application and device control policies? 

(in this case, for usb policy) , cause i applied some policies but i cannot see anyone.

thanks!

0
Login to vote
Sean_Moore's picture

Martin,

You create your own Registry Key (eg. ADC) and values (eg. USB, OPTICAL, SDD).  You can use the default domain GPO to create the keys on all of your endpoints and then use the scoped GPO's to manipulate the values of the keys dependent on the users group membership.

 

Remember to protect the registry keys and values that you create with another rule in the Application and Device control policy to prevent any processes chnaging the values of the keys with the exception of c:\windows\system32\svchost.exe which is the process used by the GPO to modify the values.

MCTS,MCSA,ACSA,SCS,STS
SME - SEP/SCSP/MS-BITLOCKER
+1
Login to vote
MartinHache's picture

Thanks Sean! appreciate your help 

0
Login to vote
MKV's picture

Hi Sean ,

Thanks for the inputs.

One question that I had on the registry settings.When we make our own registry keys , will the Tamper protection allow to do so in 12.1.Now if i disable TS from console and create a key inside Symantec , will it affect any normal operation .Also won't the TS again prevent changing the keys?

Appreciate your help.

0
Login to vote
Sean_Moore's picture

Within the ADC policy you must define the process which is allowed to make changes to the registry key. If you are using Group Policy this will be svchost.exe which must be excluded when you create you rule.

There are many ways you can configure your rule. The way I have chosen is to include a rule within the ADC policies called something like 'Protect ADC RegKey' to include a Registry rule to block any process from accessing the regkey and exclude svchost.exe (using the full path).

Tests I have performed did not get blocked by Tamper Protection. 

MCTS,MCSA,ACSA,SCS,STS
SME - SEP/SCSP/MS-BITLOCKER
0
Login to vote
Sean_Moore's picture

Ideally this solution should be incorporated into SEP in a future release by adding functionality within the ADC policies for group/user lookup similar to SCSP..

MCTS,MCSA,ACSA,SCS,STS
SME - SEP/SCSP/MS-BITLOCKER
0
Login to vote