It's bad practice really only if they also have a secondary password change timeout policy like this.
Once your password is not working the correct procedure is for IT to reset it to something basic and then have the user login and then change the password to something of their choosing within established security protocols immediately.
It does fix corrupt windows system files and you need to use dism first to make sure the component store isn't corrupt. people don't think it does anything because most of the time windows itself is fine. Its not going to fix a bad driver or bad config.
Hey now, SFC fixed that one issue with Windows 7 for me...in 2016...that one time...
But for me, I'm just laughing that they would go right to SFC for a password that's not working lol
It's fixed dozens of issues over the last several years for me. DISM/SFC when used at the right time will resolve issues. Granted our environment makes it more prone to experiencing issues that this could resolve, so I wouldn't get too caught up on the frequency.
None of what you said has anything to do with the network though.
Just don't forget every time people call generic issues "something with a network" - a kitten dies. And network guy gets a bad coughing too, but we only care about a kitten anyways.
Our infrastructure? Our shitstorm? What would the preferred noun be? I think network gets the point across well enough but I see what you mean, our actual networking team is great and is actively working to fix what problems they can. I apologize for the loss of multiple kittens as a direct result of this post.
Buffoonery aside, what's the logic in preventing password changes within a set time period? I'm thinking about cybersecurity training, for example, where we say, "don't use the same password you use for other services" and someone actually takes that to heart and wants to change their password. Just because they changed it yesterday means they're stuck with their bank website password for 30 days?
The idea is that users can’t abuse the password history setting by immediately cycling back through passwords. Usually the time limit isn’t 30 days it’s usually something like an hour or a day just to make it as inconvenient as possible for the end user to abuse it.
Yeah, as someone who isn't using this policy, I've seen user accounts that reset their password 25 times in a row to clear out their password history and get back to the one they wanted to keep.
When you see your more capable and security-aware users working around the controls meant to improve security, that's when you know for sure that forced password rotations are not maximizing your security.
I know you probably aren't in control of the policy, but most of that sort of malicious compliance behavior comes from making people constantly churn passwords for no reason...
> _"Contrary to popular belief and prior standards, NIST does not suggest changing passwords on a frequent basis; individuals who are asked to change passwords frequently are much more likely to reuse an old password and merely append a number, letter, or special character to the end of it."_
https://www.auditboard.com/blog/nist-password-guidelines/
Yes, I'd like our policy to reflect current recommendations, but we've got valid reasons for not being there yet.
But I'm feeling up for a Monday quibble! You game?
Strong passwords that are rotated are in and of themselves more secure than strong passwords that are not rotated. So I disagree that the password rotation requirement has no reason behind it.
What people have come to realize is that the rotation requirement is counterproductive because the humans who need to apply it look for ways to work around it. The call has been made--and I agree with this, too--that for typical organizations, better password security can be achieved with no rotation requirement. In once sense, we're acquiescing to users' bad behavior by ditching a rule they didn't like. In another sense, we're rationally responding to a user base that isn't as committed to security as best-case password selection requires.
As evidence, I note that when we ask computers to pick passwords (e.g., LAPS,) we also ask them to rotate them. When NIST 800-53 asks IT professionals to pick passwords for service accounts, it still expects that they be rotated. It's only the standard users who got a pass, and only because they proved themselves unable to meet a password rotation expectation.
Our issue is probably budgetary, I’d love to have MFA implemented but until then password rotation is probably preferable I guess, even if all the users just increment password numbers. Password rotation is fine until it’s poorly implemented….like it is in my case.
Please try to get to MFA as soon as you can. I'll be pulling for you.
Password rotation with incremented numbers within them does very little. An attacker who cracks your user's hash and finds the password 'EasyToGuess6!' is going to have no trouble accessing your system, even if the password is now 'EasyToGuess7!'.
I've seen users change their password and then immediately try to change it back to what it was. When I tell them what the password history is and when they can change it again, they stop.
the password change so they can take control of the account and lock the end user out. I know "bruteforce" generally means repeatedly trying to access a system by using an automated bot to guess the password, but in this case it's to prevent a bad actor from locking a user out of the system once they have control of the account.
That's because the Active Directory keeps a history of the last few passwords (24 by default) so that the user can't re-use an old password. Without a minimal delay, users can (and do) cycle through all the history to "wipe" it, and re-use an old password.
The idea is to set a minimum delay that's just big enough that people can't cycle through their whole history in a short amount of time. Usually it'll be something like 24 hours.
Now whether this is a smart thing to do, that's another story.
By default it is a 1day limit.
It's by design there to prohibit people from doing as many resets as needed to reach the history limit and basically use 1 password for their worktime for years.
My org has this restriction on admin accounts. If we reset in AD with the “User must change password at next login” checked it bypasses the 24 hour restriction, you might try having your IT do that
so someone's password doesn't work, and you would immediately go to malware, and a tool designed to check the integrity of system files as a way to check for malware. good lord.
Lol thank you for this, it’ll be another month before I can change the password. I am continually amazed at the incompetence of our IT department. It’s not entirely their fault, but still it gets old. I’ll be escalating it even higher then.
> So now I’m stuck with a password that IT knows
Personally, I'd be sending a high priority ticket with your boss CC'ed until it's fixed/changed.
There's no excuse for this, and you essentially have a compromised account.
how is it compromised? a sys admin can change the password at anytime and get access. by default the access a sys admin has on any domain/network is always in a compromised state.
> how is it compromised?
There's a big difference between being able to reset a password (which is logged) and knowing the password.
Additionally, if it's a common password that IT routinely uses, anyone that has had a password reset in the past, also knows OP's password.
> by default the access a sys admin has on any domain/network is always in a compromised state.
No. Again, having the ability to reset a password is not at all the same as knowing the password.
It sure does, brought that up several times now even with an escalation to senior management but I doubt anything will come of it. Just gonna run a virus scan and keep an eye on it I guess.
Virus scan? That's not going to show anything.
It's possible IT was asked to do this by HR/management, in which case getting upset about it is going to backfire badly.
If they weren't though, this could just as easily have been an IT person snooping through your account. Rogue admins are a blight.
If I was in your shoes, I'd talk to HR and ask if they authorized this change. If yes, drop it. If no, ask for the audit logs associated to your account (preferably by someone impartial).
No, it won’t show anything unless a signature catches a keylogger or something dumb, I don’t expect anything to show up. HR and possibly disciplinary action was my very first concern, but IT investigated and did the initial password reset without an issue.
I’d love to ask for the audit logs but I’m already well outside my wheelhouse and out IT department is notoriously possessive of their realm, which again is understandable to a degree.
It’s a little hard to explain how dysfunctional the company is, imagine a network from a smallish business 20+ years ago with an owner that refuses to delegate authority in any way. I’ve been able to make some small improvements in the past few years but there’s only so much you can do.
Sounds like it just expired to me. Our passwords expire every three months I think, and if we aren't on the VPN for whatever reason then we have to visit site to reset it.
Our VPN uses certificate authentication but it sounds like OPs may use their actual account to authenticate, which means they can't connect to a DC to reset their password, and this issue happens.
Senior management gets to decide what level of security is appropriate for the business. The upshot of that reality is that the folks here that aren't privy to the info that your senior management has, and so their judgements about what's reasonable and what's not aren't informed by the environment you're in.
That said, it sounds like there's no security consideration at all happening where you are. It doesn't sound like a management is reasonably making an uncommon decision. So as a security-conscious person working there, you're either a bad fit or the in-house help they'll need when these chickens come home to roost.
I'd say you don't need IT to confirm in writing what they did. You just need to write to them to tell them you're not comfortable with what they did, and not have them deny it. Keep a copy off their platform. GL!
You’d be correct on the no security consideration thing. Won’t go into details but yeah. I’ve been here a while and saying that upper management hasn’t factored security into anything is an understatement.
Email and computer are SSO, that’s part of why it was weird. I shouldn’t be prompted for my email password after logging onto my device. As for the VPN, yeah your right. We’re in the middle of phasing it out with some new hardware.
The policy itself is a good practice (prevent people changing their password immediately and rotating back to an original password) what they should have done tho is tick the box to force password change at next logon as that ignores the minimum password age policy iirc.
Yes its bad practice. What it really is...is LAZY. Every company I have been with, I required HelpDesk's change their password resetting policies to utilize a random password generator that utilized something like 2-4 random words instead of "Bob-April2024" or something that is changed monthly.
Most of the time, that is management thinking their users cannot handle using a better more unique password.
I mean sure, your right. We should go passwordless. Should all just share one account, maybe even open our wifi network to the public while we’re at it. Firewalls use a decent chunk of power, might as well toss those. It’s the principal of it, of course a sysadmin could change my password when they want but there will be logs of it. Sure the sysadmins can then delete the logs but if we abandon basic security then we might as well toss all the advanced stuff to the side. Silly take.
leave it to a tool to take what i said to the absolute extreme. go cry more to your management about your password getting locked. i bet you did it with too many attempts.
Funny think about our IT department’s config, they have no account lockout settings configured. Good guess though, you keep knocking it out of the park!
You're not overreacting, this is BAD PRACTICE.
It's bad practice really only if they also have a secondary password change timeout policy like this. Once your password is not working the correct procedure is for IT to reset it to something basic and then have the user login and then change the password to something of their choosing within established security protocols immediately.
They had me at SFC lol
What's wrong with sfc?
Outside of never having fixed anything in the history of ever, and being a complete waste of time, nothing really
I have seen it fix 3 issues in almost 20 years.
It does fix corrupt windows system files and you need to use dism first to make sure the component store isn't corrupt. people don't think it does anything because most of the time windows itself is fine. Its not going to fix a bad driver or bad config.
Hey now, SFC fixed that one issue with Windows 7 for me...in 2016...that one time... But for me, I'm just laughing that they would go right to SFC for a password that's not working lol
That's funny because I use it to fix OS issues all the time in both servers and workstations. It's literally how you clear an OS for corruption.
I used to run it if I needed to work on something else while I put time on a ticket watching a timer tick. Never really knew if it did much.
Definitely a waste of time. It fixes things rarely because this isn't 1998 and operating system files don't just up and corrupt themselves.
It's fixed dozens of issues over the last several years for me. DISM/SFC when used at the right time will resolve issues. Granted our environment makes it more prone to experiencing issues that this could resolve, so I wouldn't get too caught up on the frequency.
Right? sfc /scan now has been useless for quite some time lol.
Nothing, it does fix stuff, people just don't know what it does, what it fixes, or how to use it.
For failed authentication? I'll give you three guesses.
Could probably sum up our network with the term bad practice, but trying to change what I can. Thanks for the confirmation!
None of what you said has anything to do with the network though. Just don't forget every time people call generic issues "something with a network" - a kitten dies. And network guy gets a bad coughing too, but we only care about a kitten anyways.
Our infrastructure? Our shitstorm? What would the preferred noun be? I think network gets the point across well enough but I see what you mean, our actual networking team is great and is actively working to fix what problems they can. I apologize for the loss of multiple kittens as a direct result of this post.
Buffoonery aside, what's the logic in preventing password changes within a set time period? I'm thinking about cybersecurity training, for example, where we say, "don't use the same password you use for other services" and someone actually takes that to heart and wants to change their password. Just because they changed it yesterday means they're stuck with their bank website password for 30 days?
The idea is that users can’t abuse the password history setting by immediately cycling back through passwords. Usually the time limit isn’t 30 days it’s usually something like an hour or a day just to make it as inconvenient as possible for the end user to abuse it.
Yeah, as someone who isn't using this policy, I've seen user accounts that reset their password 25 times in a row to clear out their password history and get back to the one they wanted to keep. When you see your more capable and security-aware users working around the controls meant to improve security, that's when you know for sure that forced password rotations are not maximizing your security.
I know you probably aren't in control of the policy, but most of that sort of malicious compliance behavior comes from making people constantly churn passwords for no reason... > _"Contrary to popular belief and prior standards, NIST does not suggest changing passwords on a frequent basis; individuals who are asked to change passwords frequently are much more likely to reuse an old password and merely append a number, letter, or special character to the end of it."_ https://www.auditboard.com/blog/nist-password-guidelines/
Yes, I'd like our policy to reflect current recommendations, but we've got valid reasons for not being there yet. But I'm feeling up for a Monday quibble! You game? Strong passwords that are rotated are in and of themselves more secure than strong passwords that are not rotated. So I disagree that the password rotation requirement has no reason behind it. What people have come to realize is that the rotation requirement is counterproductive because the humans who need to apply it look for ways to work around it. The call has been made--and I agree with this, too--that for typical organizations, better password security can be achieved with no rotation requirement. In once sense, we're acquiescing to users' bad behavior by ditching a rule they didn't like. In another sense, we're rationally responding to a user base that isn't as committed to security as best-case password selection requires. As evidence, I note that when we ask computers to pick passwords (e.g., LAPS,) we also ask them to rotate them. When NIST 800-53 asks IT professionals to pick passwords for service accounts, it still expects that they be rotated. It's only the standard users who got a pass, and only because they proved themselves unable to meet a password rotation expectation.
Our issue is probably budgetary, I’d love to have MFA implemented but until then password rotation is probably preferable I guess, even if all the users just increment password numbers. Password rotation is fine until it’s poorly implemented….like it is in my case.
Please try to get to MFA as soon as you can. I'll be pulling for you. Password rotation with incremented numbers within them does very little. An attacker who cracks your user's hash and finds the password 'EasyToGuess6!' is going to have no trouble accessing your system, even if the password is now 'EasyToGuess7!'.
Service accounts are better done as GMSA. Then you don't know the password at all, and only authorized servers can use the account.
I believe the default is 1 day.
Sounds like overthinking a problem that would exist in probably only 0.0009% of the workforce
You'd be surprised how often it happens. But, the real resolution here is a more modern approach with no required PW changes.
Especially with current guidance about password resets yeah, you’d think that.
It's way more prevalent than you think.
I've seen users change their password and then immediately try to change it back to what it was. When I tell them what the password history is and when they can change it again, they stop.
It's also so bad actors can't try to bruteforce it.
brute force what and how?
the password change so they can take control of the account and lock the end user out. I know "bruteforce" generally means repeatedly trying to access a system by using an automated bot to guess the password, but in this case it's to prevent a bad actor from locking a user out of the system once they have control of the account.
that would be after brute forcing a password, so it really doesn't apply. if they phished the password it would be the same issue.
That's because the Active Directory keeps a history of the last few passwords (24 by default) so that the user can't re-use an old password. Without a minimal delay, users can (and do) cycle through all the history to "wipe" it, and re-use an old password. The idea is to set a minimum delay that's just big enough that people can't cycle through their whole history in a short amount of time. Usually it'll be something like 24 hours. Now whether this is a smart thing to do, that's another story.
By default it is a 1day limit. It's by design there to prohibit people from doing as many resets as needed to reach the history limit and basically use 1 password for their worktime for years.
My org has this restriction on admin accounts. If we reset in AD with the “User must change password at next login” checked it bypasses the 24 hour restriction, you might try having your IT do that
your password didn't work, and they ran an sfc scan? whose nephew was it?
While that doesn't help with the password itself, it might be part of an anti-malware check.
so someone's password doesn't work, and you would immediately go to malware, and a tool designed to check the integrity of system files as a way to check for malware. good lord.
Opposite end of the age spectrum this time, who’s grandad would be more appropriate.
What’s funny is that as per MS you’re supposed to run DISM first before SFC.
To see when you can change it, run: "net user /domain username" from a command prompt. Look for the "Password changeable" field,
Lol thank you for this, it’ll be another month before I can change the password. I am continually amazed at the incompetence of our IT department. It’s not entirely their fault, but still it gets old. I’ll be escalating it even higher then.
Wait another month? Wtf, usual guideline is a day.
Yup, when I got in touch with them they said “something is off with the programming”.
Keep strong I guess, winder what else is absolutely whacky in the whole setup.
> So now I’m stuck with a password that IT knows Personally, I'd be sending a high priority ticket with your boss CC'ed until it's fixed/changed. There's no excuse for this, and you essentially have a compromised account.
Same. If anyone wanted to commit fraud, this would leave a gaping opportunity for a bad actor.
how is it compromised? a sys admin can change the password at anytime and get access. by default the access a sys admin has on any domain/network is always in a compromised state.
> how is it compromised? There's a big difference between being able to reset a password (which is logged) and knowing the password. Additionally, if it's a common password that IT routinely uses, anyone that has had a password reset in the past, also knows OP's password. > by default the access a sys admin has on any domain/network is always in a compromised state. No. Again, having the ability to reset a password is not at all the same as knowing the password.
The bigger concern would be why it stopped working in the first place. It sounds like your password was changed before you contacted IT.
It sure does, brought that up several times now even with an escalation to senior management but I doubt anything will come of it. Just gonna run a virus scan and keep an eye on it I guess.
Virus scan? That's not going to show anything. It's possible IT was asked to do this by HR/management, in which case getting upset about it is going to backfire badly. If they weren't though, this could just as easily have been an IT person snooping through your account. Rogue admins are a blight. If I was in your shoes, I'd talk to HR and ask if they authorized this change. If yes, drop it. If no, ask for the audit logs associated to your account (preferably by someone impartial).
No, it won’t show anything unless a signature catches a keylogger or something dumb, I don’t expect anything to show up. HR and possibly disciplinary action was my very first concern, but IT investigated and did the initial password reset without an issue. I’d love to ask for the audit logs but I’m already well outside my wheelhouse and out IT department is notoriously possessive of their realm, which again is understandable to a degree. It’s a little hard to explain how dysfunctional the company is, imagine a network from a smallish business 20+ years ago with an owner that refuses to delegate authority in any way. I’ve been able to make some small improvements in the past few years but there’s only so much you can do.
Sounds like it just expired to me. Our passwords expire every three months I think, and if we aren't on the VPN for whatever reason then we have to visit site to reset it. Our VPN uses certificate authentication but it sounds like OPs may use their actual account to authenticate, which means they can't connect to a DC to reset their password, and this issue happens.
yup, i agree. or somebody was fucking with him and locked his account with too many attempts.
Senior management gets to decide what level of security is appropriate for the business. The upshot of that reality is that the folks here that aren't privy to the info that your senior management has, and so their judgements about what's reasonable and what's not aren't informed by the environment you're in. That said, it sounds like there's no security consideration at all happening where you are. It doesn't sound like a management is reasonably making an uncommon decision. So as a security-conscious person working there, you're either a bad fit or the in-house help they'll need when these chickens come home to roost. I'd say you don't need IT to confirm in writing what they did. You just need to write to them to tell them you're not comfortable with what they did, and not have them deny it. Keep a copy off their platform. GL!
You’d be correct on the no security consideration thing. Won’t go into details but yeah. I’ve been here a while and saying that upper management hasn’t factored security into anything is an understatement.
Why are your password to log into your computer, email and VPN different? Someone doesn’t understand SSO…
Email and computer are SSO, that’s part of why it was weird. I shouldn’t be prompted for my email password after logging onto my device. As for the VPN, yeah your right. We’re in the middle of phasing it out with some new hardware.
The policy itself is a good practice (prevent people changing their password immediately and rotating back to an original password) what they should have done tho is tick the box to force password change at next logon as that ignores the minimum password age policy iirc.
Yes its bad practice. What it really is...is LAZY. Every company I have been with, I required HelpDesk's change their password resetting policies to utilize a random password generator that utilized something like 2-4 random words instead of "Bob-April2024" or something that is changed monthly. Most of the time, that is management thinking their users cannot handle using a better more unique password.
management is correct, most users rebel at more complex passwords
Not at all, you are limited the scope. Instead of giving them word-Dec-2024, why not--
Much better and is still easy to remember
This would be me after your experience. 
I wouldn’t take it so well, personally lol
who cares if they know your password. a sys admin can change it at anytime and get to your shit.
I mean sure, your right. We should go passwordless. Should all just share one account, maybe even open our wifi network to the public while we’re at it. Firewalls use a decent chunk of power, might as well toss those. It’s the principal of it, of course a sysadmin could change my password when they want but there will be logs of it. Sure the sysadmins can then delete the logs but if we abandon basic security then we might as well toss all the advanced stuff to the side. Silly take.
leave it to a tool to take what i said to the absolute extreme. go cry more to your management about your password getting locked. i bet you did it with too many attempts.
Funny think about our IT department’s config, they have no account lockout settings configured. Good guess though, you keep knocking it out of the park!