How we can protect the Schema master from unauthorized changes.

Hello all,

Hope this post finds you in good health and spirit.

This post is about to protection of Schema master.How we can protect the Schema master from unauthorized changes.

The Microsoft Active Directory schema contains formal definitions of every object class that can be created in an Active Directory forest. The schema also contains formal definitions of every attribute that can exist in an Active Directory object.Kindly follow the below steps to protect your schema master from unauthorized changes.

  • Schema master should be in separate AD site

Kindly make sure your schema master should be in separate active directory site and access should be limited to this site.

Schema-Site
  • Only members of Schema Admins group can modify the schema

Only members of Schema Admins group can modify the schema. You would rarely need to modify the schema manually. Schema should only be modified by trained schema professionals. You cannot delete schema objects.

  • SchemaUpdateAllowed registry

Kindly Add the SchemaUpdateAllowed registry on schema master to avoid unauthorized schema changes.By default in Windows 2003 and later versions of AD DS, the schema is already enabled for updates. Nothing more must be done unless the registry has specifically been locked down to keep schema updates from occurring on the domain controller that hosts the Schema Master FSMO role. To edit this registry setting, perform the following steps:

  • 1. Navigate to Start > Run.
  • 2. In the Open dialog box, type Regedit and press Enter.
  • 3. Navigate to the following Registry key: HKLM\SYSTEM\CurrentContro1Set\Services\ NTDS\Parameters.
  • 4. On the Edit menu, click New, then click DWORD Value.
  • 5. Enter the following information: Value Name: Schema Update Allowed Data Type: REG_DWORD
  • Base: Binary
  • Value Data: Use a value of 1 to enable schema updates, 0 to disable schema updates.
  • 6. Close the registry editor.
Schema Registry.
  • Schema group membership

Membership to the schema admin must be limited and do not allow anyone to be member of schema admin group until unless there is any change planned. Schema should only modified by trained schema professionals or L3 resources.

Schema Admins Properties
  • Avoid to implement the schema changes by normal account.

Please do not use the normal account for schema changes. There should be -E account for Schema changes and monitoring should be placed.-E account should be vaulted and its password should be valid for some time -e g 1 or 2 hours.

-E Account for Schema changes
  • Disable the outbound replication

Kindly disable the outbound replication before start the schema changes. Doing this we can stop the replicate changes to entire forest if in case of any issue comes.

repadmin.exe /options  <server name> +DISABLE_OUTBOUND_REPL  

  • Enable outbound replication

Enable outbound replication once changes verified and everything expected working fine to avoid any corruption the AD forest.

repadmin.exe /options <server name> -DISABLE_OUTBOUND_REPL  

  • Admincount attribute

The adminCount attribute is found on user objects in Active Directory. This is a very simple attribute. If the value is <not set> or 0 then the user is not protected by the SD Propagation. If the value of adminCount is set to 1 that means the user has, or has been a member of a protected group. Kindly make sure your -E account should part of this value.

admin count value
  • Different containers for High Privileged accounts

High Privileged accounts should be in different containers and must be limited access on these containers.We should follow the RBAC modeling to avoid any access related issue. and also make sure only limited access on these containers.

  • Schema Monitoring

There should be monitoring placed for schema modification.Whenever any schema changes happened, alert should be triggered to CDT and AD team DL. Alert should be triggered based on below event;-

Schema Event
  • P1 Change Request

Change should be raised as P1 and very critical and these changes should be go through AD technical advisory broad so analysis should be done before doing these changes.

  • SOPT testing

Changes should be implemented in production after SOPT testing completion. it is best practice to perform the changes in SPOT environment after that implement to production environment.

So, that’s all in this blog. I will meet you soon with next stuff . Have a nice day !!!

Guys please don’t forget to like and share the post. You can also share the feedback on below windows techno email id.

If you have any questions feel free to contact us on admin@windowstechno.com also follow us on facebook@windowstechno to get updates about new blog posts.

How useful was this post?

Click on a star to rate it!