Active Directory Domain Policy - Local Policy - User Rights Assignments and Security Options Best Practices

Hi,

The Default Domain Policy is there as just that - a default. It has no hardening as such, although MS may have improved it a little since Windows NT.
The key thing with the default domain policy is that you can make it as secure or as slack as you want. Conventional wisdom is you only edit the password length and similar settings and leave it alone.

Whilst that still stands, the modern advice is to add ANY *security* setting that you want ALL machines to apply and not just password policies. I can't find the link to cross-reference this but it was from a reliable source.

The next key point is passwords. Just because you have set a default domain policy of say passwords must be 12 chars, it doesn't mean that the sensitive accounts (Domain Admins) get the same setting. On the contrary it is wise to enforce a stronger password policy on an "Admins OU" that apply to Tier 0 accounts.

As regards locking down Windows 10 "properly" that is really whatever your security team decide is secure. It is very hard to prescribe any settings because every business is different. That said a very good starting point is to get Microsoft's Security Compliance Manager (aka SCM). This comes with 1000s of settings that MS and leading security people have agreed is secure.

Download: https://www.microsoft.com/en-us/download/details.aspx?id=53353
It includes baselines for every OS and has explanations of settings as well as supporting documents to read. It gives a very good idea of where to start and you can export a custom baseline to use in your environment. There is a catch though - MS have decided to scrap it (last June).

Instead they provide security baselines in a zip file.
Download 1703: https://blogs.technet.microsoft.com/secguide/2017/08/30/security-baseline-for-windows-10-creators-update-v1703-final/

You can *still* use SCM, but they are not providing any more baselines for it - just the zip files.

On a general note, the website above is worth a read to understand what MS are thinking. It seems they are moving away from GPOs and expecting people to use MDM and DSC instead.

Ref: https://activedirectorypro.com/group-policy-best-practices/
and this too: https://activedirectorypro.com/active-directory-security-best-practices/

Best Practise for securing AD (Microsoft)
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory

Pay *particular* heed of this page (near the end) - Stopping Domain Admins logging on to PCs:
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f--securing-domain-admins-groups-in-active-directory

It's a lot of reading but then it's a big subject. SCM was as close to "apply this - now you're much more secure" so it's a shame they stopped development of it.

Mike

Here are some tips that can help you to ensure the security of Active Directory:

Follow a lean model for AD administration
Create a security policy and implement it
Audit Active Directory
Document the way you construct the Active Directory
Stay updated with the software
Have some precautionary measures in place
Cleanup regularly
Have powerful passwords everywhere

Get in detailed here:
https://www.lepide.com/blog/nine-simple-tips-to-secure-the-active-directory/
https://www.lepide.com/blog/security-best-practices-for-active-directory/

So, I am trying to figure out if the defined local policies, which appear to be the defaults, needs to be updated to properly secure all joined machines to the AD domain.

Without looking at your policy I can tell you without a doubt that you need to change settings to secure your domain-joined computers.
The CIS benchmarks define a set of security settings that need to be implemented to properly harden your environment.
https://www.cisecurity.org/

Okay, I am a bit baffled with at the moment how Group Policy is setup for our Domain, and our Windows 10 machines do not seem to inherit settings defined within the Default Domain Policy of which should propagate down to all domain joined member servers and workstations.

Below you can see the policy settings defined for Audit Policy within the Default Domain Policy.


So, on my machine see all the audit local policy settings are set "No Auditing".  rsop.msc displays the correct policy settings defined within the Default Domain Policy.


I ran gpupdate /force and rebooted my computer and it made no difference.  This same issue applies to all other PCs on the network.  Member servers appear to have the correct audit policy as defined within the Default Domain Policy.

Active Directory 2012 is healthy replicating between two DCs, and no issues with DNS either.

This morning I modified the Default Domain Policy Advanced Audit Policy Configuration, and I can see it applied on my workstation by running:

Auditpolicy.exe /get /category:*


However, secpol.msc shows no auditiing as displayed in the previous screenshot.

Also, I tried running the powershell command Get-GPResultantSetOfPolicy, and it states the term 'Get-GPResultantSetOfPolicy' is not recognized as the name of a cmdlet, function, script...

I figured out the problem not being able to run Get-GPResultantSetOfPolicy poweshell command.  I attached the results for your review.
GPOtest.html

Hi,

The result reads fine. I know there is a huge amount of info to cover (which I have covered at length above). The key to what you are seeing, at least as I understand it is:

Local security Policy - is meant to apply to machines that are in workgroups, either deliberately or because they have not yet joined a domain
Local Group Policy editor - is a tool to apply and enforce security policy settings in workgroup machines

The emphasis here is "local". The first tool is to view/edit actual settings, the second is to enforce those settings. When I set auditing using GPEdit the settings apply and appear in local security policy but I have to close the MMC and open it again - probably because there is no "refresh" button.

On a Domain, all the local security policies will be overwritten if defined. If they are not defined (Set) then the local policy settings will apply. As I said to verify this behaviour, I would set something and then check the logs.
 
From MS
On devices that are joined to a domain, auditing settings for the event categories are undefined by default. On domain controllers, auditing is turned on by default.

and
After your audit policy is configured, events will be recorded in the Security log. Open the Security log to view these events.
Ref: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/create-a-basic-audit-policy-settings-for-an-event-category


I would not worry about what you are seeing local security policy at all. I would concentrate on 2 things:

1) creating a hardened baseline for workstations
2) create a hardened baseline for servers

Also, do not fall into the trap of giving Domain Admins privileges out like candy. It's easy but fatal. Instead create tiered admins so that people who do server admin cannot ever logon to workstations with their higher power accounts. Likewise and more obvious don't allow workstation admins to logon to servers. The reason why is easy to explain - passthehash.

The only reason to worry about the local policy settings is if you have machines that are not domain joined, or machines that take "too long" not domain joined during the build process. The latter is very remote risk  though.

From the report BTW:
Extensions Configured
Audit Policy Configuration
{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}
Security
Registry

which shows audit policy is indeed applying.

Final note: to apply local security policy during a build Microsoft supply a command line tool called LocalGPO (aka LGPO) which was orginally part of SCM. You use SCM, generate the policies you want, export as XML and then create a package to apply that during your build (using MDT or SCCM). Obviously you can use the tool any time you like, not just during a build.
Just to confuse people MS now have "Microsoft Compliance Toolkit" - https://www.microsoft.com/en-us/download/details.aspx?id=55319 - that includes Windows 10 baselines and the LGPO tool, which I guess replaces the SCM product swapping the main GUI with the Policy Analyzer.

Mike

The problem is during a security assessment we got hit with inconsistencies with local policies being inconsistent on domain controllers and domain joined servers and workstations.  Let me give you another example, the Default Domain Controller Policy is defined as:

Audit Account Logon Events:  Success, Failure
Audit Account Management:  Success, Failure
Audit Directory Service Access:  Success, Failure
Audit Logon Events:  Success, Failure
Audit Object Access:  No Auditing
Audit Policy Change:  Success, Failure
Audit Privilege User:  No Auditing
Audit Process Tracking:  No Auditing
Audit System Events:  Success

I ran rsop.msc on both DCs, and it reflects the same settings as displayed above.  Also, the source GPO is "Default Domain Controllers Policy".
 
However, when I view the DCs local policies, the only Audit Policy that is consistent with the above GPO is Audit Account Logon Events - "Success, Fail".  All other Audit Policy settings indicate "No Auditing".  When I try and change any of the audit policies within local policy its states its enforced by a GPO and cannot be changed.

So, the security assessment indicated in the case the local policy - audit policy are not consistent.  I am trying to fix it so that it is consistent.  I also tried enabling/disabling the Default Domain Controller Policy - Security Options - Audit: Force audit policy subcategory settings, but it made no difference as far have the local policy settings reflect the same settings as defined within GPO.

Hi,

I can see what you mean but I don't see it as being important. Local policies only apply to workgroups and machine not in a domain. On any Windows PC, Audit Policy (in Local security policy) defaults to No Auditing. If you never join a domain and then use local gpedit or secpol you can change the settings. As *soon* as you join the machine to a domain, you CANNOT edit any Local Polciies\Audit Policy settings. I just tried in a dev /lab.

Note you have to define Domain audit policies for it to do this. If you blank out (revert all domain audit policies to "no auditing") then and only then does the local audit policy become editable. This experiment was on 2012R2.

So, if you really, really want to edit the local policy settings to match your domain settings you will have to do that. Note though it's a futile exercise as the domain policies apply anyway, so it really doesn't matter what settings are set in the local policy MMC, as that's NOT what applies. RSOP, gpresult, get-gpresults all tell you the same answer - that auditing is applied and working via the domain policy you have defined NEVER local policies unless you remove the machine from the domain that is.

The first paragraph of this : https://www.itprotoday.com/management-mobility/figuring-out-which-gpo-s-policy-taking-precedence
says what I've said above. Local policies are only valid for standalone (workgroup) machines.

I would concentrate on creating the settings you think best and validating they work. In looking I found the domain policy has even more lock-down:
https://blogs.technet.microsoft.com/canitpro/2017/03/29/step-by-step-enabling-advanced-security-audit-policy-via-ds-access/
since 2008R2.

Mike

I agree entirely.  rsop clearly displays the policy applied, so even though the local policy displays settings as "Not Defined" is not an issue.  I am speaking of DCs, member servers and workstations. The security auditors feel different.

I was thinking about this last night - I think you need new auditors and/or a second opinion at least to go back to them with. There is no problem that I can see here and the insistence is just making work which is distracting from actually working to secure the business. Their job ought to be 1) finding holes 2) giving you tools/help to fill the holes.  Too often I see pen-testers come and run MBSA/Metasploit hand over a report that says "you have 120 patches missing - that will be £50K please." It's beyond exasperating. They do more than that, but too often it's not much more and I don't think it's good enough. Security is a huge subject and we need sensible advice and guidance on where to focus efforts in building defences into systems.

I can't think what else to say as I have explained what I know and given evidence from independent sources & MS.

I will leave you with this good advice on general tips to follow:
https://activedirectorypro.com/active-directory-security-best-practices/

If pen-testers were to provide something like this it would feel so much better at least.

Mike

Local policies only apply to workgroups and machine not in a domain

This is not true. Do you mean the auditing part?

Hi Shaun,

I was trying to keep it simple and maybe got carried away. I can see that first sentence is not true without a key caveat! Let me re-phrase it:

1) On a workgroup or standalone PC there is no Domain GPO, so no domain policies can apply
2) On a workgroup or standalone PC there is only local policies possible, so only local policies apply

3) On a Domain PC there are both local policies and domain policies.
4) On a Domain PC both local and domain policies apply, but for any setting, the Domain Policy wins over Local Policy settings, making local policies irrelevant.
5) if a setting is Undefined in the Domain Policy but is defined in a Local Policy instead, then that Local Policy *will* apply.

So what I meant by the first sentence was "only local policies apply to workgroups and machines not in a domain because there is no domain and thus no domain policy". If there is a domain there is a domain policy and that will apply it's domain settings, overriding the local policies. In the auditing case, it locks the local settings entirely.

Let me know if you agree or not with it put like that.

Mike

We got hit bad with the Security Policy Assessment - Policy Consistency.  As you can from the summary we had very low scores for the Audit Policy and User Rights Assignment.



So, as you can see from the details listed below, both Prometheus and Chronos (Domain Controllers) indicate "No Auditing" when in fact the Default Domain Controller Policy has auditing enabled and even advanced auditing.  When I view the local policies on both DCs, they indicate no auditing for each policy, and I can't change them to match default domain controller policy either.  I have not yet looked into the User Rights Assignment since I first wanted to deal with Auditing throughout the AD domain.

Thank you Mike

Thanks for all your feedback.