Zoho Banner September 2011

Archive for August, 2015

I’m sometimes asked what the best practice is surrounding the Default Domain Policy and Default Domain Controllers Policy. Microsoft has some good guidance on this topic, but it’s not always clearly and consistently stated. Here’s a quick Q&A that might help.

 

Q. Is it ok to make changes to the DDP and DDCP GPOs, or should I leave them alone and create new policies?

 

A. The best practice recommendation from Microsoft is as follows:

 

  • ·    To accommodate APIs from previous versions of the operating system that make changes directly to default GPOs, changes to the following security policy settings must be made directly in the Default Domain Policy GPO or in the Default Domain Controllers Policy GPO:
  • ·    Default Domain Security Policy Settings:
    • o    Password Policy
    • o    Domain Account Lockout Policy
    • o    Domain Kerberos Policy
  • ·    Default Domain Controller Security Policy Settings:
    • o    User Rights Assignment Policy
    • o    Audit Policy

Source: Best Practice Guide for Securing Active Directory Installations (https://technet.microsoft.com/en-us/library/cc773164(v=ws.10).aspx)

 

So, that’s it!  If you want to apply other settings at the domain root level or to the Domain Controllers OU then you should create new GPOs and link them to the appropriate scope of management. The ordering of the GPOs shouldn’t really matter as you should have no overlapping settings. As a general rule of thumb, however, I would recommend assigning any new GPOs a higher precedence in case someone starts using the default GPOs for settings that are not on the “approved” list above. That way the new GPOs will win in any conflict.

 

Another reason to limit the settings in the default GPOs is to allow them to be re-created with minimal re-work in scenarios where they have gone missing or are corrupt and you don’t have a good backup.  The method by which you can re-create the GPOs is using a tool called DCGPOFIX.EXE (https://technet.microsoft.com/en-us/library/hh875588.aspx).  Bear in mind that this tool is a last resort following a major issue or disaster and you should really ensure you have good GPO backups, as per this article:

 

If you are in a disaster recovery scenario and you do not have any backed up versions of the Default Domain Policy or the Default Domain Controller Policy, you may consider using the Dcgpofix tool. If you use the Dcgpofix tool, Microsoft recommends that as soon as you run it, you review the security settings in these GPOs and manually adjust the security settings to suit your requirements. A fix is not scheduled to be released because Microsoft recommends you use GPMC to back up and restore all GPOs in your environment. The Dcgpofix tool is a disaster-recovery tool that will restore your environment to a functional state only. It is best not to use it as a replacement for a backup strategy using GPMC. It is best to use the Dcgpofix tool only when a GPO back up for the Default Domain Policy and Default Domain Controller Policy does not exist.

Source: https://support.microsoft.com/en-us/kb/833783

 

Q. We have disabled our DDP and DDCP GPOs and replaced them with new GPOs. Is that OK?

 

A. No, that’s not ok.  The GPOs have a fixed GUID and can be targeted directly using these by the “legacy APIs” mentioned above. 

 

31b2f340-016d-11d2-945f-00c04fb984f9: Default Domain Policy

6ac1786c-016f-11d2-945f-00c04fb984f9: Default Domain Controllers Policy

 

One well known application that directly modifies the Default Domain Controllers Policy is Microsoft Exchange.  The installer adds the Exchange Servers group to the “Manage Auditing and Security Log” User Right (also referred to as SACL right). So, if you disable or unlink the GPO this right (and potentially others like it) it will go missing and will cause problems for Exchange.

 

Q. Is it OK to rename the DDP and DDCP GPOs?

A. If you feel you must do this I don’t believe it will have any impact, other than it might confuse people when they look for them. I’ve seen some customers rename the GPOs to align them with their in-house naming convention. As mentioned above, these GPOs are targeted using their well-known GUIDs, which is why the rename shouldn’t cause an issue. 

 

You can find the renamed GPOs quite easily using the Group Policy cmdlets, e.g.

 

# Find the Default Domain Policy

Get-GPO -Guid 31b2f340-016d-11d2-945f-00c04fb984f9

 

# Find the Default Domain Controllers Policy

Get-GPO -Guid 6ac1786c-016f-11d2-945f-00c04fb984f9

 

Conclusion

Use the default GPOs for the approved specific purposes only.  If you have other settings you need for the same scope of management, create new GPOs and link them with higher precedence than the default GPOs. Under no circumstances should you disable or unlink the GPOs.  If you rename the default GPOs there should be no impact, but your mileage may vary.

 

 

You know you’re getting old when you come across a Usenet post you wrote almost 20 years ago. I came across this little memento while Googling for a much more recent item. Given the vintage of the post, I must have been referring to Exchange 4.0.  Exchange has come a long way since then, although I do kind of miss X.400.

x400_tony

PS. I’m still waiting for an answer to my question. :-)

Over the weekend I opened up my laptop to knuckle down to my chapter reviews for the upcoming update to the excellent Inside Office 365 for Exchange Professionals. If you don’t already have a copy I strongly recommend you make the investments. The E-book is detailed, well researched and written by those who really know their stuff.

But I’m drifting off topic. The nasty surprise for me was that my laptop keyboard didn’t appear to work. This was strange as I’m negotiated past the Ctrl+Alt+Del dialogue, which meant it wasn’t a hardware failure. At first I thought it must be a Windows 10 driver issue. In some of the pre-release builds I’d had issues with the mouse pad drivers and I thought the keyboard issue was something similar. After 10 minutes or so of fruitlessly tinkering with drivers I finally resorted to Google and found the solution quite quickly. It turns out the “Enable Slow Keys” setting, which is part of the Ease of Access keyboard settings, had somehow turned itself on. I was able to confirm this by pressing and holding down a key. The selected character appeared on the screen after a delay.

I’m still not sure how I managed to turn the setting on, but was relieved to be able to turn it off. If you have the same issue, type “filter keys” in the “Search the web and Windows” area and then select the “Ignore brief or repeated keystrokes” option. From there you can turn off “Enable Slow Keys” option, as shown in the screenshot below.

Enable Slow Keys

Hopefully this will help you if you run into the same issue.