Most Common Mistakes in Active Directory and Domain Services – Part 1


As a Premier Field Engineer (PFE) at Microsoft, I encounter new challenges on a daily basis. Every customer has its own uniqueness, and each environment is different from the other.

And yet, there are several things I repeatedly encounter over and over again. Common mistakes that IT administrators make because lack of knowledge or changes in products they are not aware of.

This blog post is the first part of a series which will cover several of those mistakes. So… Let’s get started!

Series:

Mistake #1: Configuring Multiple Password Policies for Domain Users Using Group Policy

When reviewing Group Policy settings, I often find Group Policies Objects (GPOs) that contain ‘Password Policy’ settings.

For example, when looking into a “Servers Policy” GPO, I can see that it has Password Policy settings defined, including Maximum password age, Minimum password length and so on.

When I ask the customer about it, he tells me that this policy was built to set a different password policy for some admins accounts or any other group of users.

As you already know (or might have guessed), this is NOT the correct way to configure different Password Policies in your environment. Here’s why:

  • Password Policy settings in GPO affect computers, not users.
  • When you change your Domain User password, the password change takes place on the Domain Controllers.
  • Therefore, the Password Policy that takes effect is the one applied on your Domain Controllers, usually by the ‘Default Domain Policy” GPO.
  • More accurate, the Domain Controller that holds the PDC Emulator FSMO role is the one responsible for applying the Password Policy for the domain level.
  • In terms of Group Policy, there can be only one password policy for domain users.

Bottom Line: Configure a GPO with password policy and link it to an Organizational Unit (OU) won’t change the password policy for users within this OU.

Do It Right: Use FGPP.

Mistake #2: Removing “Authenticated Users” from the Group Policy Object Security Filtering

In June 2016, Microsoft released a security update that changes the security context with which user group policies are retrieved.

Before that update, user group policies were retrieved by using the user’s security context. After installing the update, user group policies are retrieved by using the computer's security context.

Therefore, you should always make sure that any Group Policy in your environment could be retrieved by the relevant computer accounts.

Because a lot of people are not aware of this change, I usually find Group Policies with missing permissions that are not being applied at all.

When changing Group Policy Security Filtering scope from “Authenticated Users” to any other group, the “Authenticated Users” (which contains computers account as well) are removed from the Group Policy delegation tab. As a result, computer accounts don’t have the necessary “Read” permissions in order to access and retrieve group policies.

In recent versions of Group Policy Management, a warning message appears when removing the default “Authenticated Users” from the “Security Filtering” tab:

That is why you must validate that any Group Policy has the “Authenticated Users” or “Domain Computers” groups with “Read” permissions. Make sure that that you specify “Read” permission only, without selecting the “Apply group policy” permissions (otherwise any user or computer will apply this Group Policy).

The following PowerShell function can help you identify GPOs with missing permissions (missing both 'Authenticated Users' and ‘Domain Computers' groups):

Bottom Line: Group Policies with missing permissions for computers account (“Authenticated Users”, “Domain Computers” or any other group that includes the relevant computers) will NOT be applied.

Do It Right: When changing Group Policy Security Filtering, make sure you add the “Authenticated Users” group in the delegation tab and provide it with “Read” permission only.

Mistake #3: Creating a DNS Conditional Forwarder as a Non-Active Directory Integrated Zones

When creating a DNS conditional forwarder using the DNS management console (GUI), it’s created, by default, as a non-Active Directory integrated zone, meaning that it’s saved locally in the server’s registry.

Creating a non-Active Directory integrated zone raises a few problems:

  • Non-Active Directory zones do NOT replicate between the Active Directory Integrated DNS servers, therefore these zones might become out of sync when configured over two or more DNS servers.
  • Non-Active Directory zones can be easily forgotten and abandoned when replacing Domain Controllers as part of an upgrade or restore procedures.
  • In many cases, Non-Active Directory zones for conditional forwarder are defined on a single server, which causes inconsistent behavior between servers in terms of DNS resolving.

You can easily change this and create the zone as an Active Directory integrated zone by selecting the option “Store this conditional forwarder in Active Directory”.

Using PowerShell, you can specify the parameter ‘ReplicationScope’ with either ‘Forest’ or ‘Domain’ scope to store the conditional forwarder zone in Active Directory:

Bottom Line: Avoid using non-Active Directory integrated zones unless you have a really good reason.

Do It Right: When creating conditional forwarder using either PowerShell or the GUI, make sure to create it as an Active Directory-integrated forwarder.

 

Continue reading part 2 of the series.

Comments (13)

  1. Saggiehaim says:

    Great article! thanks for sharing.
    Ran the GPO script and found few GPO’s to fix.
    waiting for part 2.

    1. Hi Saggie,

      Thank you for your feedback.
      I’m glad to hear you found this article and PowerShell script useful.
      Part 2 is on its way 🙂

      1. Hi,
        Thanks for sharing this kind of articles.
        Really appreciated.
        Thanks

        1. Hi Ganesh,

          Thank you for your feedback. I’m happy to see that you find it relevant.
          Part 2 of the series is coming soon 🙂

  2. Okechukwu N says:

    Thanks for sharing this article at this time. It’s very helpful.

  3. Avishek-MS says:

    Great Article..thank for sharing this.
    Small query About Mistake #2, Removing “Authenticated Users” from the Group Policy Object Security Filtering: When technician add any Groups/Object under security filter automatically that group/object will get read access. In that scenario, my experience says that “Authenticated Users” or “Domain Computers” don’t require to add it again. What’s your opinion on this?

    1. Hi Avishek,
      Thank you for your comment.

      Regarding your question:

      New GPOs are created with “Authenticated Users” in the Security Filtering as default.
      Any object that you managed under the Security Filtering will automatically get both ‘Read’ and ‘Apply Group Policy’ permissions.
      Removing an object from the “Security Filtering” list will completely remove the object from the delegation tab as well.

      So, to summarise this…

      1.If the technician is editing the Security Filtering list by just adding a new group (without removing the ‘Authenticated Users’ object), nothing will happen. It just not make sense because all users and computers are already have permissions to read and apply this GPO.
      2.If the technician is editing the Security Filtering list by adding the relevant group and removing the ‘Authenticated Users’ object, he must manually add the ‘Authenticated Users’ object to the delegation tab and provide it with ‘Read’ permission only.

      Hope it’s now clear.

  4. Great Article! Omer thanks for sharing it. as a non AD guy that use AD on daily base that script helped me already.
    and my #1 mistake (until today) was to remove Authenticate Users from filtering!
    Thanks A lot

  5. Great article Omer! I have shared it with AD admin friends from my old job and found out errors.

    1. Thanks for the feedback Oren! I’m glad you found it helpful!

  6. Great article , even though I was aware few of these things, it was a quick recap. Appreciate your time.

  7. AdminSan says:

    Excelent article, really useful.
    However I have a small question over this:
    “Mistake #2: Removing “Authenticated Users” from the Group Policy Object Security Filtering”

    What if you need to make some configuration over a list of people only (let’s say set a different proxy). How do you filter it if not by using an especific group?

    Also I ran the script and returned all the GPOs over my Domain. After freaking out I discovered that some of them alredy had Authenticated User on them. Why can this be happening?

    Thanks in advance!!

Skip to main content