Why my Domain Password Policy Not Applying?

Back in 2009 I published a very popular article "The Low-Down on Password Policies" which has been viewed by thousands of IT Professionals and referenced by application vendors in online documentation such as SysOp Tools Software.

http://clintboessen.blogspot.com.au/2009/12/low-down-on-password-policies.html

In this post we are going to talk about password policies further and cover off what appears to be a bug but is actually "by design".

My customer had a handful of domain controllers with a single 2008 R2 domain controller and three Server 2012 R2 domain controllers.  The PDC Emulator resides on Server 2008 R2.

The Server 2008 R2 domain controller was applying the password policy correctly however the 2012 R2 domain controllers were not (or so I thought).

Running an rsop.msc on the 2008 R2 domain controller (the PDC) shows the policy being applied from the Default Domain Policy.

 

 The 2012 R2 domain controllers the resultant set of policy displayed no policies being applied.

The same was experienced running an "gpresult /v" on the 2008 R2 or 2012 R2 domain controllers.

"gpresult /v" on 2008 R2:

 

"gpresult /v" on 2012 R2:

 

 

The account policies above are the domain Kerberos policy, not the password policy.

 

The password policy simply did not apply to the 2012 servers.  After further investigation in my test lab, I saw that only the domain controller running the PDC emulator displays the password policy when performing a Resultant Set of Policy.

 

This means every domain controller in a domain will not display the password policy from a resultant set of policy apart from the primary domain controller.

 

How do I check if the password policy is applying correctly on my domain controllers?

 

There are two commands which check the password policy:

• net accounts (checks local password policies on a server)
• net accounts /domain (checks the domain password policy on a server)

 

 

 

Domain Policy always wins over a local policy.

 

Computer Role: Backup means it is not a Primary Domain Controllers (PDC).

 

So in summary... if you see a password policy not applying to a domain controller when you check Group Policy, this is normal behaviour and is by design unless the server is the PDC emulator.

Exchange 2013 - Could not find any available Global Catalog in forest

I was contracted to redesign a companies AD Sites and Services Topology - it was never setup correctly and despite being a 500 user organisation with 13 branch sites, they were still running of the "Default-First-Site-Name" which is generated automatically by Active Directory for a new domain.

As part of the new design, I updated the Default-First-Site-Name to a name which reflects their main datacentres then went through the process creating the additional site objects, site links and subnet objects.

After renaming Default-First-Site-Name I also updated the AutodiscoverSiteScope on the Client Access Servers in the Exchange 2013 cluster to reflect the new site name (as required for correct site SCP lookups).

After approximately 30 minutes, the IT Department complained they were no longer able to work on Exchange 2013 servers - all commands in the Exchange Management Shell failed with:

Could not find any available Global Catalog in forest

Oh dear!

After a quick investigation, the issue was only isolated to Exchange 2013 management tools and Outlook clients were not affected by the Site Object rename.

In order to force Exchange Server to redetect Active Directory Sites and Services topology, a restart of the "Microsoft Exchange Active Directory Topology" service is required on all Exchange servers.  Unfortunately almost every Exchange Service is dependent on this service!

As a result, we needed to wait until after business hours where we rebooted every Exchange 2013 server in the cluster.

This resolved the problem.

Windows DNS Forwarder Population

A customer contacted me today asking why when they promoted all these domain controllers, they had old DNS forwarders automatically configured on each server.

When DCPROMO installs the DNS Server service it also activates, by default, the auto-configuration of the DNS Server service. This auto-configuration process configures the forwarders list, the root-hints and the resolver, among other things, like creating the zones if required.

During the automatic configuration of the Forwarders, the following process occurs:

1. Try to copy the forwarders list from a peer DNS server. A peer DNS server is any DNS server that has a copy of this DC domain’s zone. To get the peer server list the process queries for the NS list of the domain’s zone and then contacts each server returned on the list until it finds one from which it can copy the forwarders list. Once the process finds a peer from which it can copy the forwarders list it skips the next step. If no peer is found (because the NS query returned empty), none of them could be contacted, or none of them has forwarders configured, then move to step #2.
2. If the previous step was not able to provide a forwarders list, then use as forwarders all the DNS Servers that are currently listed in the resolver for all the adapters, without any specific order.
3. If none of the previous two steps can provide a forwarders list, then the new DNS server will not have forwarders configured.

If you have different DNS Forwarders configured for various sites on your network, the DNS server will automatically configure itself to one at random so make sure you check the forwarders after promoting a new server!