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.

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.

• 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 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.

• 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.

• 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.

• 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;-

• 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 some other stuff. Have a nice day !!!

Recommended content

RODC Installation Guide- Step by step guide to install read only domain controller

RODC Filtered Attribute Set

Installing and configuring a RODC in Windows Server-2012

How to find the GUID of Domain Controller

Group Policy Understanding Group Policy Preferences

Group Policy Verification Tool GPOTool Exe

Group Policy Health Check on Specific Domain Controller

What is Netlogon Folder in Active Directory

How to Create Custom Attributes in Active Directory

How Can I Check the Tombstone Lifetime of My Active Directory Forest

How to Determine a Computers AD Site From the Command Line

How to Check the Active Directory Database Integrity

How to Check the Active Directory Database Integrity

Disabling and Enabling the Outbound Replication

DFS Replication Service Stopped Replication

What is Strict Replication Consistency

The replication operation failed because of a schema mismatch between the servers involved

Troubleshooting ad replication error 8418 the replication operation failed because of a schema mismatch between the servers

How to export replication information in txt file

Repadmin Replsummary

Enabling the outbound replication

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.