Passwords expiring in the middle of the day

jadams

2[H]4U
Joined
Mar 14, 2010
Messages
4,086
For some reason our users' passwords have been expiring i the middle of the day which causes widespread "panic".

I will concede it is annoying when some of our apps that require LDAP no longer allows a user to authenticate.

So how can i get the passwords to expire overnight so that a prompt to change them would happen in the morning upon booting up their PC's?
 
If you are using AD, you can use the following link to setup a warning of when thier password will expire.
 
Get smarter users? :) Our passwords expire at anytime of the day, but generally we receive notifications starting ~10 days prior, and most people choose new passwords before their old one actually expires. Are your users getting notifications? (ours are usually via an email system, but also on windows machines you get the pop-up notification that your password will expire soon)
 
Get smarter users? :) Our passwords expire at anytime of the day, but generally we receive notifications starting ~10 days prior, and most people choose new passwords before their old one actually expires. Are your users getting notifications? (ours are usually via an email system, but also on windows machines you get the pop-up notification that your password will expire soon)


How do you set the email part up?
 
How do you set the email part up?

How are your passwords being maintained/enforced? My company uses Microsoft Exchange, a password portal synchronizes passwords for all company sites/services and Windows credentials. Since email is via MS Exchange, there's an option within Exchange to email users XX days in advance of a password expiring, and at YY frequency. The user can go to the password portal through Exchange, or they can simply reset their Windows Account password (where the new password gets pushed to all other credentialed sites). Other than that sort of configuration, I'm not sure the best way. How are your accounts being maintained?
 
For some reason our users' passwords have been expiring i the middle of the day which causes widespread "panic".

That just means the last time they changed their password was in the middle of the day.

The password expiration limit is reset the moment they change their password.
Therefore, it will expire in the middle of the day; unless they change it after hours.
 
That's interesting, I've setup/seen many domains before and never seen this issue. Have not dealt with anything past 2003 though, as an admin or a user. Is this anything after 2003? Wonder if it's different in those versions and maybe you have to set the time they expire at, so people get the prompt in the morning. Every place I've worked or managed you'd get a prompt when you first log in. Though, if you don't log out often enough and it happens to expire while still logged in then it does cause weird issues.

Are users always staying logged in and never rebooting? Maybe you need to try to get them to log out and back in at least once a week. Or even every 2 weeks. If I recall the expiry notice comes up 14 days ahead of time. Of course if they always say no up until the day it expires there will be some issues.
 
For some reason our users' passwords have been expiring i the middle of the day which causes widespread "panic".

I will concede it is annoying when some of our apps that require LDAP no longer allows a user to authenticate.

So how can i get the passwords to expire overnight so that a prompt to change them would happen in the morning upon booting up their PC's?
Hi jadams,

Based on your requirement-" So how can i get the passwords to expire overnight so that a prompt to change them would happen in the morning upon booting up their PC's?"

To solve your requirement, you can reset multiple user passwords to a common password and force them to change their passwords the next time they logon as shown in the below dsmod command

dsmod user "CN=John Doe,CN=Users,DC=microsoft,DC=com" "CN=Jane Doe,CN=Users,DC=microsoft,DC=com" -pwd A1b2C3d4 -mustchpwd yes
 
Is there a reason you Necro'ed this thread from last August?
 
Hi jadams,

Based on your requirement-" So how can i get the passwords to expire overnight so that a prompt to change them would happen in the morning upon booting up their PC's?"

To solve your requirement, you can reset multiple user passwords to a common password and force them to change their passwords the next time they logon as shown in the below dsmod command

dsmod user "CN=John Doe,CN=Users,DC=microsoft,DC=com" "CN=Jane Doe,CN=Users,DC=microsoft,DC=com" -pwd A1b2C3d4 -mustchpwd yes

I would not advocate doing that, because that leaves a window of time when the user's account is vulnerable to being hijacked by any disgruntled individual who knows the common 'reset' password. Depending on what exactly you're doing, this will most likely be very difficult for you to log accountability for this, too, so when someone does hijack someone else's account, you probably won't be able to figure out who it was with certainty.
 
I would not advocate doing that, because that leaves a window of time when the user's account is vulnerable to being hijacked by any disgruntled individual who knows the common 'reset' password. Depending on what exactly you're doing, this will most likely be very difficult for you to log accountability for this, too, so when someone does hijack someone else's account, you probably won't be able to figure out who it was with certainty.
We store the last 4 of our users SS number in an extension attribute. When we do mass resets like this we typically will combine their last name and the last 4 of their social as their password.

This way we can tell everyone what their password is, without anyone actually knowing each others passwords.
"Attention users, the new password is your last name and the last 4 of your social"
 
We store the last 4 of our users SS number in an extension attribute. When we do mass resets like this we typically will combine their last name and the last 4 of their social as their password.

This way we can tell everyone what their password is, without anyone actually knowing each others passwords.
"Attention users, the new password is your last name and the last 4 of your social"

....Which can work, depending on what else you use your SSN for. I've worked at a few places where part of verifying your identity to say, a help desk tech you're on the phone with involved providing the last for digits of your SSN. Now if you know the last four digits of one's social security number, there's probably a few options for what wrong-doing you might choose to do, but if you overhear your colleague say "1357" while on the phone with the help desk, you can jump to conclusions about the significance of that number, and if everybody's getting password resets involving their SSN, it's pretty easy to just try Mr. Jameson's password before he gets in. So if you don't use the user's SSN to verify lots of things already, that's probably fine, though I still don't like the risk of having a large window of time during which the user's password is something other than something they set themselves.

This is why I generally don't consider replacing someone's password when not requested by this user to do so to be a good practice. If the user requests a password reset, that's fair because they told you to do it and because they'll most likely reset it immediately. If they haven't made it into work yet and there's a 3 hour window where a mischievous individual can gain access to someone's account on a shared workstation and have it look like it was 'business as usual' until the user actually shows up and can't change their password correctly, that's bad, because the user could be exploited through no fault of their own, and with access to their account, the wrongdoer could do untold amounts of damage.

User accounts are also just a very powerful thing to protect so loosely. If the right account got into the wrong hands, millions of dollars could be jeopardized. I prefer in-person password resets with photo IDs whenever logistically possible for this very reason, and I'd much rather just allow their passwords to expire and force them to log out than do a manual password reset so that they must change it at login. I don't think having a large 'window of opportunity' where the user's password is at best easy to guess (and realistically, already determinable by a plotting wrongdoer) is anything less than a ticking time bomb.
 
Last edited:
....Which can work, depending on what else you use your SSN for. I've worked at a few places where part of verifying your identity to say, a help desk tech you're on the phone with involved providing the last for digits of your SSN. Now if you know the last four digits of one's social security number, there's probably a few options for what wrong-doing you might choose to do, but if you overhear your colleague say "1357" while on the phone with the help desk, you can jump to conclusions about the significance of that number, and if everybody's getting password resets involving their SSN, it's pretty easy to just try Mr. Jameson's password before he gets in. So if you don't use the user's SSN to verify lots of things already, that's probably fine, though I still don't like the risk of having a large window of time during which the user's password is something other than something they set themselves.

This is why I generally don't consider replacing someone's password when not requested by this user to do so to be a good practice. If the user requests a password reset, that's fair because they told you to do it and because they'll most likely reset it immediately. If they haven't made it into work yet and there's a 3 hour window where a mischievous individual can gain access to someone's account on a shared workstation and have it look like it was 'business as usual' until the user actually shows up and can't change their password correctly, that's bad, because the user could be exploited through no fault of their own, and with access to their account, the wrongdoer could do untold amounts of damage.

User accounts are also just a very powerful thing to protect so loosely. If the right account got into the wrong hands, millions of dollars could be jeopardized. I prefer in-person password resets with photo IDs whenever logistically possible for this very reason, and I'd much rather just allow their passwords to expire and force them to log out than do a manual password reset so that they must change it at login. I don't think having a large 'window of opportunity' where the user's password is at best easy to guess (and realistically, already determinable by a plotting wrongdoer) is anything less than a ticking time bomb.
I work for a school. It's mostly to reset teachers passwords on the first day of school because they haven't been at work all summer and they all forgot them.
 
We store the last 4 of our users SS number in an extension attribute. When we do mass resets like this we typically will combine their last name and the last 4 of their social as their password.

This way we can tell everyone what their password is, without anyone actually knowing each others passwords.
"Attention users, the new password is your last name and the last 4 of your social"

You store the last 4 digits of SSN in AD? You know anyone with a valid login can query for it. I wouldn't like the last 4 digits of my SSN being "exposed" to other employees.
 
You store the last 4 digits of SSN in AD? You know anyone with a valid login can query for it. I wouldn't like the last 4 digits of my SSN being "exposed" to other employees.
awesome. And let me know how exactly that's going to affect anything?
When you call your cable company they ask for your social, when you call your power company they ask for your social.
Trust me, a lot less qualified people are looking at your social or parts of it in other industries computer systems. We don't even store the entire thing, just the last 4. AND we store it in an obscure extension attribute that no one outside IT even knows what numbers in that field represent.
 
There's a difference between being asked the last four digits of your SSN vs. it being exposed for anyone on your network to find out. That's a risk and you're liable. How about you post the last four digits of your SSN for all to see?

Also under FERPA, SSNs, even portions of it, are defined as personally identifiable information and may not be publicly disclosed without consent.

Although I would agree with you that the risk impact may be low, it still doesn't mean you should do it. But hey if security through obscurity works for you, you deserve a pat on the back, bud.
 
Just set your passwords to never expire and auto unlock the accounts when they get put in wrong too many times :D
 
awesome. And let me know how exactly that's going to affect anything?

Well, if people can in fact query them freely, as he claims, that's not good. Lots of places use the last 4 digits of people's SSN for verifying identity. I don't care if my employer stores the last 4 digits, but I don't want them to make it available to everybody who can log in there. In other words, if someone is going store last 4 SSN digits, they should store it securely. If you're giving away the last 4 digits of peoples' SSNs, a careful hacker can gain access to lots of personal accounts and systems, because they can 'prove' that they're the accountholder.

Basically, if you wouldn't send an email with your legal name, phone number and your last 4 digits of your SSN to everybody at your work, you probably shouldn't be storing them in a way that anybody with a login can query against.

When you call your cable company they ask for your social, when you call your power company they ask for your social.

...Which is not a problem, if they store them correctly.

Trust me, a lot less qualified people are looking at your social or parts of it in other industries computer systems.

...There's plenty of people who are arsonists and rapists. That doesn't make it okay for people to shoplift, though. Personally identifiable information needs to be secured, and I don't care how low-risk people may 'think' their system is.

We don't even store the entire thing, just the last 4.

The last 4 digits can still get you places though. Nothing wrong with storing them...but if they're query-able, like versello pointed out, they're not secure.

AND we store it in an obscure extension attribute that no one outside IT even knows what numbers in that field represent.

Obscurity is not security, and it's certainly not a replacement for encryption. If your mapping is linear (I.E. One-to-one and onto in case you were asleep for your matrix algebra class), it would take a clever person all of about 5 minutes to figure out your 'obscure' mapping. They have a big hint, after all: If they have one in the system, they're already going to have 3 or 4 of the characters as freebies.

If you're going to store them (again, nothing wrong with storing them. It's how you're storing them which matters), it would be very courteous if you did so in a way that's actually secure. You might trust your colleagues, but I don't. Private studies in my sector indicate that a majority of security breaches come internally within the organization. There are bad people everywhere, in every kind of job, in every industry, so even though you're managing securities accounts or high-value hedge funds you should still try to be properly security conscious.
 
Last edited:
jesus you people get all bent out of shape about this.
They are NOT queryable. I wasn't even going to waste my time arguing with that idiot but you people don't seem to understand how this stuff works.

The extension attribute that we use to store the last 4 of their SSN is flagged as confidential in the schema. This means that someone can't just load up LDAP browser and query for their attribute on all users.
more info: http://serverfault.com/questions/181669/where-do-i-store-sensitive-data-within-active-directory

Also, to his FERPA violation accusation, you do realize that FERPA applies to STUDENTS right? We don't store SSN's (or partials) of our students in AD. They are stored within our SIS database and follow all proper FERPA guidelines.
 
Just to add a little a something. Generally speaking when a csr asks for the last 4 digits of your SSN they don't actually see the your last 4. What they do is enter what you provide them. That input is then hashed and compared to the hash that is stored in the system. If it matches then your gtg. The system stores the hash not the actual numbers. This is the normal and accepted way of doing this. CSRs nor IT staff should ever have access to that information.
 
jesus you people get all bent out of shape about this.

Exposure of personally identifiable information is something people will get bent out of shape about. It's something which in some industries can result in multi-million dollar fines and even jail time.

Just to add a little a something. Generally speaking when a csr asks for the last 4 digits of your SSN they don't actually see the your last 4. What they do is enter what you provide them. That input is then hashed and compared to the hash that is stored in the system. If it matches then your gtg. The system stores the hash not the actual numbers. This is the normal and accepted way of doing this. CSRs nor IT staff should ever have access to that information.

I agree. This is the way I would prefer to have this information stored...store it one-way, using a hash. If it's the last 4 digits of your SSN, you have no need to actually 'retrieve' this value, only determine whether or not what the user supplied matches what you have on record.
 
Back
Top