none
Default Domain Policy and Default Domain Controller Policy

    Question

  • I am looking for some help on explaining why these two policies really shouldn't be modified to use for anything other than default Policies, however I am having trouble putting into words a non-techie would understand...

    Would anyone be able to help me out on this subject with Microsoft Best Practices ?

    Thank you

    Tuesday, January 10, 2017 9:17 PM

All replies

  • They contain very sensitive configurations and I believe this is the reason that is not recommended to update them. Instead, new GPOs could be created to achieve exactly the same results.

    This posting is provided AS IS with no warranties or guarantees , and confers no rights.

    Ahmed MALEK

    My Website Link

    My Linkedin Profile

    My MVP Profile

    Tuesday, January 10, 2017 11:40 PM
  • Hi,

    As X said, they contained sensitive configurations.

    Besides, they're domain level policy, so their impact level is the whole domain.

    If you edit it with a wrong configuration, the whole domain might encountered unexpected issues. That's fatal in product environment.

    So, our principle is : reduce risk to a minimum. Also, making things as easier as we can.

    It's also very helpful for troubleshooting issues.

    Best regards,

    Andy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, January 11, 2017 5:02 AM
    Moderator
  • Hi,
     
    Am 10.01.2017 um 22:17 schrieb Jason_A_T:
    > I am looking for some help on explaining why these two policies
    > really shouldn't be modified [...]
     
    It´s completly up to you. There is no technical reason to handle it one
    or the other way.
     
    GPOs are just a kind of transport modules to deploy information. The
    object does not care, if the settings comes from one or the other
    object. In the end the ruleset must give your desired result.
     
    I use the Default Policies for a few reasons, but I have some rules:
     
    - I only change existing values that do not fit. DefDomPol contains
    Account, Lockout and Kerberos Settings nothing else. DefDomConPol
    contains User Rights assignment and Security Settings.
    I do not add any other.
     
    - The Default Policies have hardcoded GUIDs, they are always the same in
    any AD. They are easy to find and easy to troubleshoot, because of that.
     
    - It creates more work, if "personal Defaults"-Policies are used.
    You need to be aware of the sort order. If you install a software on a
    DC, thats needs an entry in "User Rights assignment", this is done
    automatically into the DefDomConPol, because it´s a hardcoded GUID (you
    remember?) and the right GPO can be identified by the software.
    If you have youre own GPO, you need to set the value manually and you
    should not forget that, otherwise the softwasre does not work.
     
    - There is a interaction between the DefDomPol and the Domain Head
    Password settings. If you edit the Password attribute in
    "dc=your,dc=dom" it will automatically update the value in DefDomPol.
     
    - Aswell, there is an interaction between the local policy of the PDC
    emulator and the DefDomPol. Which can cause a little confusion when
    updating or changung DCs.
     
    - I do not accept the argument: "Do not change the default, because we
    do not know how to restore them, in a specific case".
    Thats stupid. It takes 10 minutes to install a NEW AD and DC by
    "enter-enter-ok". Get the settings from there ... It´s the DEFAULT, you
    did  not change the origin, so ANY fresh AD can give you the settings.
     
    - Create Backups of your GPO, easy job with the GPMC or script to backup
    once a day, but only if changes happen
     Conclusion:
    It´s up to you.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Wednesday, January 11, 2017 9:19 AM