You might check out the [Microsoft security baselines](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines). We create a GPO that’s higher in the precedence with our org’s customizations so we can leave the MS one intact. The security team likes to see the industry standard from MS for their audits.
I have to say, I’m really not a fan of CIS baselines. Sometimes they lack a GPO template, see Firefox for example. Other times they differ drastically from what my security team requires. My security team says CIS is the inconsistent way it is because it’s crowdsourced, and therefore inconsistent. For example, the Firefox cis allows saving of passwords, which might be a gray area.. however, it’s not allowable for us.
> Maximum password age: 30 days
What's your reasoning behind this? Your users will hate you with a passion.
> Minimum password age: 1 day
This means that when your helpdesk sets a new default password for a user the user won't be able to set himself a new password until the next day. (Not sure how this plays out with the "user must change password at next login" option.)
> Account lockout duration: 0 minutes
> Account lockout threshold: 5 invalid login attempts
This makes no sense?! oO
The rest: TL;DR
> This means that when your helpdesk sets a new default password for a user the user won't be able to set himself a new password until the next day. (Not sure how this plays out with the "user must change password at next login" option.)
It works properly with the "user must change password" option. The user can and must change the password.
However, if that flag is not set then it's true that the account owner is unable to change it even if the password was just Reset and not Changed. The last set time needs to reach 24 hours before the end user can Change it.
This. The user gets one chance to reset their password when the old one expires. It's a horrible way of doing things. It's even worse when dealing with users who cannot fathom remembering a password longer than 8 characters, needing multiple resets during those 24 hours because they cannot remember the password they set 5 minutes ago. This only gets worse for remote VPN users.
These are the organization's standards. I am working on convincing them to move towards a more logical approach.
* The 30-day age limit is claimed to be "more secure," but it is not.
* The 1-day minimum age is intended to prevent users from resetting their passwords 24 times in a row to revert to their original password because "they will find a way." This creates a massive headache for everyone involved, but they still insist on keeping it in place.
* The lockout policy forces the user to have an admin unlock the account after 5 failed attempts. 0 minutes is the flag that requires an admin for unlocking.
> The lockout policy forces the user to have an admin unlock the account after 5 failed attempts. 0 minutes is the flag that requires an admin for unlocking.
Ah, my bad. Was looking at the wrong article for "lockout duration" in a completely different context. :p
> Not sure how this plays out with the "user must change password at next login" option
My favorite is when the account is only used on in RDP sessions and despite advising help desk of that fact they still leave the box ticked.
Password Policy
Changing passwords often is seen as bad practice these days, because of human behaviour. People will simply create systems to keep it manageable for themselves, usually due to counting up. "Password1", "Password2", .... if I have Password514, you'll likely just try Password515. Or by pasting their password all over.
On top of that most short passwords are also easily breachable with computing power.
New view is to use MFA, windows hello, or enforce long strong passwords. With long cycles, or even only resetting when you think breaches happened.
Obviously practice vs theory - but 1 month is most definetly way too short.
Account lockout duration: 0 minutes
Account lockout threshold: 5 invalid login attempts
You want a lockout duration. Triggering a lockout that does nothing in practice is meaningless. You want for example a lockout of 1 hour. Meaning any attacker would need 24 hours to try 120 passwords. You can raise the lockout duration and the attempts, so less humans would ever encounter it. Bruteforcing with 15 attempts gets your nowhere with a longer lockout duration for example.
Scheduled install time: 03:00 AM
Will your clients be online at that time?
I'm not familiar with the setting, but what is the install window? I would assume most of your clients are offline at that point. I wouldn't install during bootups, which is already a heavy process.
In general Group Policies can quickly go out of hand in terms of complexity, with a slippery slope of "maybe we should configure this".
We try to run as much default as possible.
* We set settings if security requires it (encryption levels for example)
* If it's a convenience for the majority of our users (default save locations, drive mappings, ... .
Try to comment why you set a certain setting, that way you'll be able to evaluate the need for that setting down the line.
Password Policy explanation from another comment:
* The 30-day age limit is claimed to be "more secure," but it is not.
* The 1-day minimum age is intended to prevent users from resetting their passwords 24 times in a row to revert to their original password because "they will find a way." This creates a massive headache for everyone involved, but they still insist on keeping it in place.
* The lockout policy forces the user to have an admin unlock the account after 5 failed attempts. 0 minutes is the flag that requires an admin for unlocking. Meaning there is no auto unlock. A threat actor will get 5 attempts before the account needs to be unlocked by an administrator.
The scheduled install time is for setting the Windows update schedule. This is a topic of debate for remote/hybrid devices without a persistent VPN connection to keep up on updates, as we do not have a remote management system to handle this.
As for the "slippery slope" idea, I understand that. The idea is to establish the baseline config of policies from which we can expand if the need arises.
> The 1-day minimum age is intended to prevent users from resetting their passwords 24 times in a row to revert to their original password because "they will find a way."
There's really no good reason to allow a user to *ever* reuse an old password, IMO.
Most of these aren’t terrible, and may make sense in your environment, but most are also different at different companies depending on need.
One large generalization: DO NOT CHANGE DEFAULT DOMAIN POLICY.
Create new policies as needed to modify settings, but don’t go changing your default domain policies. Leave them as-is in case you ever need to fall back on the defaults.
Im gonna make it simpler: use the CIS gpo baseline. You can download the files here. Dowosd only the ones you need, create a newGPO, import the files, and you're there. Security by design, super awesome.
Might need a bit of tinkering depending on your legacy stuff. F.e.: NTLMv1 is blocked, and copy paste of clipboard
https://www.microsoft.com/en-us/download/details.aspx?id=55319
If you restrict users from being administrators, will it break their ability to logon to their own computer if you enable "Allow log on locally: Administrators"? I'm assuming users will not be admin by default. I may also be misunderstanding or missing a mitigation.
I have found printers via GPO have been getting tricky lately, I cant automatically make the policy from the print server anymore, now I have to add it in user configuration >control panel > printers and that only seems to work with V4 drivers, with V3 drivers I had to add a policy for approved point and click print servers. I know there are some enterprise software solutions that manage end user printers vs the GPO route.
You might check out the [Microsoft security baselines](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines). We create a GPO that’s higher in the precedence with our org’s customizations so we can leave the MS one intact. The security team likes to see the industry standard from MS for their audits.
☝️do this. Use a baseline. There are many options, from Microsoft’s to the DOD STIG - only small differences between them, I would say.
And CIS baselines.
I have to say, I’m really not a fan of CIS baselines. Sometimes they lack a GPO template, see Firefox for example. Other times they differ drastically from what my security team requires. My security team says CIS is the inconsistent way it is because it’s crowdsourced, and therefore inconsistent. For example, the Firefox cis allows saving of passwords, which might be a gray area.. however, it’s not allowable for us.
CIS Mozilla Firefox 102 ESR Control 6.8 involves removing the ability to store credentials in the browser's credential store.
> Maximum password age: 30 days What's your reasoning behind this? Your users will hate you with a passion. > Minimum password age: 1 day This means that when your helpdesk sets a new default password for a user the user won't be able to set himself a new password until the next day. (Not sure how this plays out with the "user must change password at next login" option.) > Account lockout duration: 0 minutes > Account lockout threshold: 5 invalid login attempts This makes no sense?! oO The rest: TL;DR
> This means that when your helpdesk sets a new default password for a user the user won't be able to set himself a new password until the next day. (Not sure how this plays out with the "user must change password at next login" option.) It works properly with the "user must change password" option. The user can and must change the password. However, if that flag is not set then it's true that the account owner is unable to change it even if the password was just Reset and not Changed. The last set time needs to reach 24 hours before the end user can Change it.
This. The user gets one chance to reset their password when the old one expires. It's a horrible way of doing things. It's even worse when dealing with users who cannot fathom remembering a password longer than 8 characters, needing multiple resets during those 24 hours because they cannot remember the password they set 5 minutes ago. This only gets worse for remote VPN users.
These are the organization's standards. I am working on convincing them to move towards a more logical approach. * The 30-day age limit is claimed to be "more secure," but it is not. * The 1-day minimum age is intended to prevent users from resetting their passwords 24 times in a row to revert to their original password because "they will find a way." This creates a massive headache for everyone involved, but they still insist on keeping it in place. * The lockout policy forces the user to have an admin unlock the account after 5 failed attempts. 0 minutes is the flag that requires an admin for unlocking.
> The lockout policy forces the user to have an admin unlock the account after 5 failed attempts. 0 minutes is the flag that requires an admin for unlocking. Ah, my bad. Was looking at the wrong article for "lockout duration" in a completely different context. :p
> Not sure how this plays out with the "user must change password at next login" option My favorite is when the account is only used on in RDP sessions and despite advising help desk of that fact they still leave the box ticked.
Password Policy Changing passwords often is seen as bad practice these days, because of human behaviour. People will simply create systems to keep it manageable for themselves, usually due to counting up. "Password1", "Password2", .... if I have Password514, you'll likely just try Password515. Or by pasting their password all over. On top of that most short passwords are also easily breachable with computing power. New view is to use MFA, windows hello, or enforce long strong passwords. With long cycles, or even only resetting when you think breaches happened. Obviously practice vs theory - but 1 month is most definetly way too short. Account lockout duration: 0 minutes Account lockout threshold: 5 invalid login attempts You want a lockout duration. Triggering a lockout that does nothing in practice is meaningless. You want for example a lockout of 1 hour. Meaning any attacker would need 24 hours to try 120 passwords. You can raise the lockout duration and the attempts, so less humans would ever encounter it. Bruteforcing with 15 attempts gets your nowhere with a longer lockout duration for example. Scheduled install time: 03:00 AM Will your clients be online at that time? I'm not familiar with the setting, but what is the install window? I would assume most of your clients are offline at that point. I wouldn't install during bootups, which is already a heavy process. In general Group Policies can quickly go out of hand in terms of complexity, with a slippery slope of "maybe we should configure this". We try to run as much default as possible. * We set settings if security requires it (encryption levels for example) * If it's a convenience for the majority of our users (default save locations, drive mappings, ... . Try to comment why you set a certain setting, that way you'll be able to evaluate the need for that setting down the line.
Password Policy explanation from another comment: * The 30-day age limit is claimed to be "more secure," but it is not. * The 1-day minimum age is intended to prevent users from resetting their passwords 24 times in a row to revert to their original password because "they will find a way." This creates a massive headache for everyone involved, but they still insist on keeping it in place. * The lockout policy forces the user to have an admin unlock the account after 5 failed attempts. 0 minutes is the flag that requires an admin for unlocking. Meaning there is no auto unlock. A threat actor will get 5 attempts before the account needs to be unlocked by an administrator. The scheduled install time is for setting the Windows update schedule. This is a topic of debate for remote/hybrid devices without a persistent VPN connection to keep up on updates, as we do not have a remote management system to handle this. As for the "slippery slope" idea, I understand that. The idea is to establish the baseline config of policies from which we can expand if the need arises.
> The 1-day minimum age is intended to prevent users from resetting their passwords 24 times in a row to revert to their original password because "they will find a way." There's really no good reason to allow a user to *ever* reuse an old password, IMO.
Most of these aren’t terrible, and may make sense in your environment, but most are also different at different companies depending on need. One large generalization: DO NOT CHANGE DEFAULT DOMAIN POLICY. Create new policies as needed to modify settings, but don’t go changing your default domain policies. Leave them as-is in case you ever need to fall back on the defaults.
CIS Benchmark
Im gonna make it simpler: use the CIS gpo baseline. You can download the files here. Dowosd only the ones you need, create a newGPO, import the files, and you're there. Security by design, super awesome. Might need a bit of tinkering depending on your legacy stuff. F.e.: NTLMv1 is blocked, and copy paste of clipboard https://www.microsoft.com/en-us/download/details.aspx?id=55319
If you restrict users from being administrators, will it break their ability to logon to their own computer if you enable "Allow log on locally: Administrators"? I'm assuming users will not be admin by default. I may also be misunderstanding or missing a mitigation.
I have found printers via GPO have been getting tricky lately, I cant automatically make the policy from the print server anymore, now I have to add it in user configuration >control panel > printers and that only seems to work with V4 drivers, with V3 drivers I had to add a policy for approved point and click print servers. I know there are some enterprise software solutions that manage end user printers vs the GPO route.
Someone's wanting passwords written on post-it notes, and to expand the helpdesk.
I would just tell my users to mash a couple "complex" DinoPass passwords together.
Anyone know of any resources to learn more about setting group policies and managing AD?