Remove schema

  • Last Post 10 August 2017
manasrrp6 posted this 10 August 2017

How can I remove schema for a particular user in AD so that some tab will be removed from user property dialog box.
NOTE: -  It dose not should be effect for whole users in entire domain.
With Warm Regards,
Manas Dash.
AD & Exchange Admin
+91 9437615424
+91 7400342191
Skype : manasrrp6
Plant a Tree & Save the Earth.

Order By: Standard | Newest | Votes
daemonr00t posted this 10 August 2017

Hi there…


Hope I am getting your question right but I think what you want to look into is creating a custom MMC/task pad with the proper delegation assigned.


Kindly see


You also need to define who you want to prevent from seeing those attribute, remember the tab is just a logical grouping of attributes presented to you in a friendly



Also bear in mind that anything you change at the schema level is forest wide, so you don’t wanna mess with the schema for a single object need.








manasrrp6 posted this 10 August 2017

Hi Danny,
Actually we want prevent some tabs of user property dialog box from our L1 engineers in our enterprises.
Is any schema editor tools ?


darren posted this 10 August 2017

I think what Danny is trying to suggest Manas, is that the right way to do this is not found in the schema. If your goal is to prevent L1 engineers from editing certain attributes on certain objects, then the right way to do this is through

delegation. Trying to obfuscate access to those attributes in the UI or through other means is not a substitute for using delegation, since other means to get to those attributes (e.g. PowerShell or other scripting) will still be open.





daemonr00t posted this 10 August 2017

Yep, Darren is on the same line as me.


I suggest you look into delegation, then if you want you can create a custom task pad so they can only see what they are entitled for.


Hiding a certain tab from ADUC won’t be safe as they can do PoS, DS commands or any other scripting.


Property sets are also useful in scenarios like this, hope there’s one that fits your needs.







barkills posted this 10 August 2017

A bit more detail is needed to give more than generic advice (which is generally excellent). Put differently, depending on the details a schema change or extensive process change may be necessary.


A variety of explicit permissions granted to built-in AD groups enable read and write permissions on object classes. Delegating via inherited permissions will not prevent accounts which are members of groups

that have those explicit permissions. Examples of two such built-in AD groups which I’m thinking of are: Account Operators (which L1 engineers may have) which broadly provides write access and Pre-Windows 2000 Compatible Access (which everyone in your domain

may have) which broadly provides read access.


Those explicit permissions are granted at object creation time because of schema.


So to repeat myself, without know more, I don’t think we can give more than the generic advice that has already been voiced.


Manas, you’ll need to share a lot more if you want specific advice that will be effective.


What attributes (or ADUC tabs)? What built-in AD groups are the L1 engineers in? Are you trying to prevent read or write or both? Anything else about the scenario we should know?