Active Directory password expiration - changing in staggered groups
I can't test this without causing problems for a lot of people. I'd like to enable on a Group Policy for password expiration for my hundreds of Active Directory users, but avoid having a Hell Day for everyone.
Let's say most users have 100+ days since password change. If I set Group Policy now so that passwords expire after 100 days, I expect most will be blocked immediately. But I'd like to have a cohort change password today, and another cohort change password next week, etc. Then, after the compliant have changed passwords and everyone is duly notified, I can enable the Group Policy.
Does AD's password expiration depend on the creation of the rule in Group Policy? Will everyone's trigger on the same day later? Or staggered in the cohorts I mentioned?
windows passwords group-policy
add a comment |
I can't test this without causing problems for a lot of people. I'd like to enable on a Group Policy for password expiration for my hundreds of Active Directory users, but avoid having a Hell Day for everyone.
Let's say most users have 100+ days since password change. If I set Group Policy now so that passwords expire after 100 days, I expect most will be blocked immediately. But I'd like to have a cohort change password today, and another cohort change password next week, etc. Then, after the compliant have changed passwords and everyone is duly notified, I can enable the Group Policy.
Does AD's password expiration depend on the creation of the rule in Group Policy? Will everyone's trigger on the same day later? Or staggered in the cohorts I mentioned?
windows passwords group-policy
1
You should be able to with a PowerShell script, determine when the password was changed, for a given user. You can then determine, how many days ago this was, and confine any changes to the parameters you set. What have you tried? You can then at any point in time you decide change the policy
– Ramhound
Feb 20 at 2:00
1
This isn't an answer, but be aware that the latest revision of NIST 800-63b explicitly advises against regular password changes - because it compels people to use predictable mnemonic strategies. For example, if passwords must be changed every 90 days and standard complexity is required, the most common pattern is "[Season][YYYY]!" (Spring2019!, Summer2019!, etc.) For obvious reasons, password crackers cut through these like a hot knife through butter - and the NIST authors have caught on to that fact. Instead, encourage random passphrases, and rotate when needed (departures, compromise, etc)
– Royce Williams
Feb 20 at 7:16
Thanks for your comments and the answer below. Active Directory users have a field with the date the password was last set. The system calculates "Does the current user's password need to be reset?" comparing that field and the current date. As long as system clocks are working, it's fine. I'll proceed with scripts as suggested. Probably like these : oxfordsbsguy.com/2013/11/25/…
– Christopher Hostage
Feb 20 at 21:10
add a comment |
I can't test this without causing problems for a lot of people. I'd like to enable on a Group Policy for password expiration for my hundreds of Active Directory users, but avoid having a Hell Day for everyone.
Let's say most users have 100+ days since password change. If I set Group Policy now so that passwords expire after 100 days, I expect most will be blocked immediately. But I'd like to have a cohort change password today, and another cohort change password next week, etc. Then, after the compliant have changed passwords and everyone is duly notified, I can enable the Group Policy.
Does AD's password expiration depend on the creation of the rule in Group Policy? Will everyone's trigger on the same day later? Or staggered in the cohorts I mentioned?
windows passwords group-policy
I can't test this without causing problems for a lot of people. I'd like to enable on a Group Policy for password expiration for my hundreds of Active Directory users, but avoid having a Hell Day for everyone.
Let's say most users have 100+ days since password change. If I set Group Policy now so that passwords expire after 100 days, I expect most will be blocked immediately. But I'd like to have a cohort change password today, and another cohort change password next week, etc. Then, after the compliant have changed passwords and everyone is duly notified, I can enable the Group Policy.
Does AD's password expiration depend on the creation of the rule in Group Policy? Will everyone's trigger on the same day later? Or staggered in the cohorts I mentioned?
windows passwords group-policy
windows passwords group-policy
asked Feb 20 at 1:52
Christopher HostageChristopher Hostage
3,6841129
3,6841129
1
You should be able to with a PowerShell script, determine when the password was changed, for a given user. You can then determine, how many days ago this was, and confine any changes to the parameters you set. What have you tried? You can then at any point in time you decide change the policy
– Ramhound
Feb 20 at 2:00
1
This isn't an answer, but be aware that the latest revision of NIST 800-63b explicitly advises against regular password changes - because it compels people to use predictable mnemonic strategies. For example, if passwords must be changed every 90 days and standard complexity is required, the most common pattern is "[Season][YYYY]!" (Spring2019!, Summer2019!, etc.) For obvious reasons, password crackers cut through these like a hot knife through butter - and the NIST authors have caught on to that fact. Instead, encourage random passphrases, and rotate when needed (departures, compromise, etc)
– Royce Williams
Feb 20 at 7:16
Thanks for your comments and the answer below. Active Directory users have a field with the date the password was last set. The system calculates "Does the current user's password need to be reset?" comparing that field and the current date. As long as system clocks are working, it's fine. I'll proceed with scripts as suggested. Probably like these : oxfordsbsguy.com/2013/11/25/…
– Christopher Hostage
Feb 20 at 21:10
add a comment |
1
You should be able to with a PowerShell script, determine when the password was changed, for a given user. You can then determine, how many days ago this was, and confine any changes to the parameters you set. What have you tried? You can then at any point in time you decide change the policy
– Ramhound
Feb 20 at 2:00
1
This isn't an answer, but be aware that the latest revision of NIST 800-63b explicitly advises against regular password changes - because it compels people to use predictable mnemonic strategies. For example, if passwords must be changed every 90 days and standard complexity is required, the most common pattern is "[Season][YYYY]!" (Spring2019!, Summer2019!, etc.) For obvious reasons, password crackers cut through these like a hot knife through butter - and the NIST authors have caught on to that fact. Instead, encourage random passphrases, and rotate when needed (departures, compromise, etc)
– Royce Williams
Feb 20 at 7:16
Thanks for your comments and the answer below. Active Directory users have a field with the date the password was last set. The system calculates "Does the current user's password need to be reset?" comparing that field and the current date. As long as system clocks are working, it's fine. I'll proceed with scripts as suggested. Probably like these : oxfordsbsguy.com/2013/11/25/…
– Christopher Hostage
Feb 20 at 21:10
1
1
You should be able to with a PowerShell script, determine when the password was changed, for a given user. You can then determine, how many days ago this was, and confine any changes to the parameters you set. What have you tried? You can then at any point in time you decide change the policy
– Ramhound
Feb 20 at 2:00
You should be able to with a PowerShell script, determine when the password was changed, for a given user. You can then determine, how many days ago this was, and confine any changes to the parameters you set. What have you tried? You can then at any point in time you decide change the policy
– Ramhound
Feb 20 at 2:00
1
1
This isn't an answer, but be aware that the latest revision of NIST 800-63b explicitly advises against regular password changes - because it compels people to use predictable mnemonic strategies. For example, if passwords must be changed every 90 days and standard complexity is required, the most common pattern is "[Season][YYYY]!" (Spring2019!, Summer2019!, etc.) For obvious reasons, password crackers cut through these like a hot knife through butter - and the NIST authors have caught on to that fact. Instead, encourage random passphrases, and rotate when needed (departures, compromise, etc)
– Royce Williams
Feb 20 at 7:16
This isn't an answer, but be aware that the latest revision of NIST 800-63b explicitly advises against regular password changes - because it compels people to use predictable mnemonic strategies. For example, if passwords must be changed every 90 days and standard complexity is required, the most common pattern is "[Season][YYYY]!" (Spring2019!, Summer2019!, etc.) For obvious reasons, password crackers cut through these like a hot knife through butter - and the NIST authors have caught on to that fact. Instead, encourage random passphrases, and rotate when needed (departures, compromise, etc)
– Royce Williams
Feb 20 at 7:16
Thanks for your comments and the answer below. Active Directory users have a field with the date the password was last set. The system calculates "Does the current user's password need to be reset?" comparing that field and the current date. As long as system clocks are working, it's fine. I'll proceed with scripts as suggested. Probably like these : oxfordsbsguy.com/2013/11/25/…
– Christopher Hostage
Feb 20 at 21:10
Thanks for your comments and the answer below. Active Directory users have a field with the date the password was last set. The system calculates "Does the current user's password need to be reset?" comparing that field and the current date. As long as system clocks are working, it's fine. I'll proceed with scripts as suggested. Probably like these : oxfordsbsguy.com/2013/11/25/…
– Christopher Hostage
Feb 20 at 21:10
add a comment |
1 Answer
1
active
oldest
votes
Don’t use AD password expiration to do this initially.
Instead, use powershell, or even AD Users and Computers to flag a certain subset of users to change their password at next logon.
If you use AD Users and Computers you can multi-select users, then right-click and set properties in bulk.
If you use powershell, you could additionally check when the last time the password was changed and if over a certain time, flag the account for a password change.
Once everyone is updated, like you said, enable the group policy to set password expiration.
In powershell, you’ll use a combination of get-aduser
and set-aduser
to accomplish this task.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1407668%2factive-directory-password-expiration-changing-in-staggered-groups%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Don’t use AD password expiration to do this initially.
Instead, use powershell, or even AD Users and Computers to flag a certain subset of users to change their password at next logon.
If you use AD Users and Computers you can multi-select users, then right-click and set properties in bulk.
If you use powershell, you could additionally check when the last time the password was changed and if over a certain time, flag the account for a password change.
Once everyone is updated, like you said, enable the group policy to set password expiration.
In powershell, you’ll use a combination of get-aduser
and set-aduser
to accomplish this task.
add a comment |
Don’t use AD password expiration to do this initially.
Instead, use powershell, or even AD Users and Computers to flag a certain subset of users to change their password at next logon.
If you use AD Users and Computers you can multi-select users, then right-click and set properties in bulk.
If you use powershell, you could additionally check when the last time the password was changed and if over a certain time, flag the account for a password change.
Once everyone is updated, like you said, enable the group policy to set password expiration.
In powershell, you’ll use a combination of get-aduser
and set-aduser
to accomplish this task.
add a comment |
Don’t use AD password expiration to do this initially.
Instead, use powershell, or even AD Users and Computers to flag a certain subset of users to change their password at next logon.
If you use AD Users and Computers you can multi-select users, then right-click and set properties in bulk.
If you use powershell, you could additionally check when the last time the password was changed and if over a certain time, flag the account for a password change.
Once everyone is updated, like you said, enable the group policy to set password expiration.
In powershell, you’ll use a combination of get-aduser
and set-aduser
to accomplish this task.
Don’t use AD password expiration to do this initially.
Instead, use powershell, or even AD Users and Computers to flag a certain subset of users to change their password at next logon.
If you use AD Users and Computers you can multi-select users, then right-click and set properties in bulk.
If you use powershell, you could additionally check when the last time the password was changed and if over a certain time, flag the account for a password change.
Once everyone is updated, like you said, enable the group policy to set password expiration.
In powershell, you’ll use a combination of get-aduser
and set-aduser
to accomplish this task.
answered Feb 20 at 5:23
AppleoddityAppleoddity
7,86521226
7,86521226
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1407668%2factive-directory-password-expiration-changing-in-staggered-groups%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
You should be able to with a PowerShell script, determine when the password was changed, for a given user. You can then determine, how many days ago this was, and confine any changes to the parameters you set. What have you tried? You can then at any point in time you decide change the policy
– Ramhound
Feb 20 at 2:00
1
This isn't an answer, but be aware that the latest revision of NIST 800-63b explicitly advises against regular password changes - because it compels people to use predictable mnemonic strategies. For example, if passwords must be changed every 90 days and standard complexity is required, the most common pattern is "[Season][YYYY]!" (Spring2019!, Summer2019!, etc.) For obvious reasons, password crackers cut through these like a hot knife through butter - and the NIST authors have caught on to that fact. Instead, encourage random passphrases, and rotate when needed (departures, compromise, etc)
– Royce Williams
Feb 20 at 7:16
Thanks for your comments and the answer below. Active Directory users have a field with the date the password was last set. The system calculates "Does the current user's password need to be reset?" comparing that field and the current date. As long as system clocks are working, it's fine. I'll proceed with scripts as suggested. Probably like these : oxfordsbsguy.com/2013/11/25/…
– Christopher Hostage
Feb 20 at 21:10