"Your password expires in X days"

[aerospacemango]

I have a question, that has been vexing the department for a couple of days now, and which we don't have the answer to.

 

Our Principle would like his password NOT to expire. This seems easier said than done , at the moment!

 

We've put him into an OU in GP, that doesn't need to change the password, and ticked the box in the properties. He still gets the email.

 

We've tried putting him into a GP unit that doesn't take the Default Domain Policy. He still gets the email.

 

Could it be that the email is spurious?

 

Or is there something obvious that we've missed?

 

All help gratefully received!!!

[gl3nnym]

I have never known an email reminder to tell you to change your password on a windows network. New to me.

Anyhow, I take it you ticked the "password never expires" box? Surely if this is done then regardless of the email his password should never need to be reset should it?

 

Maybe it's me that's missing something.

[JJonas]

I think you need server 2008 to set different password expiration rules for different OU's otherwise everybody takes the default policy. To get round it you would need to turn it off for everyone - not a good idea or do what gl3nnym suggests.

[Martin]

Have you checked the e-mail headers to see where it actually came from - sounds suspicious to me!

 

mb

[aerospacemango]

Anyhow, I take it you ticked the "password never expires" box? Surely if this is done then regardless of the email his password should never need to be reset should it?

 

Yep, that's deffo ticked! I went through the account yesterday, and checked everything was as it should be.

 

I'm all for letting it go for the next 3 days, and seeing whether it actually DOES expire.

[gl3nnym]

Yeah give it a go. Worst comes to worst then the principal won't have his account for about 2 minutes until you reset it again but if that box is ticked then I don't see why it would expire. I would be interested to see how it turns out.

[aerospacemango]

Have you checked the e-mail headers to see where it actually came from - sounds suspicious to me!

 

mb

 

Seems like our system developer had written a reminder script for the passwords.

 

So they're from a system admin account.

 

We're NOT going to let it count down, as my boss is getting significant static from the top man about this! So, I have to find out what the problem is!

[gl3nnym]

We're NOT going to let it count down, as my boss is getting significant static from the top man about this! So, I have to find out what the problem is!

 

How are you supposed to effectively troubleshoot the problem if you are not allowed a little trial and error? Maybe the script is buggy? Scripting is not my area of expertise i'm afraid.

[aerospacemango]

How are you supposed to effectively troubleshoot the problem if you are not allowed a little trial and error?

 

That's my point entirely!

 

But, that's the rules!!

[srochford]

I suspect the script sending the email is reading the password age and if it's greater than (say) 80 days, is sending the email.

 

What it needs to do is check "is the 'password never expires' set"? If yes then skip this user else check the age and send the email. That way users who have password set to never expire won't get confusing emails.

 

I'd be interested to know what your auditors have to say about a principal with a non-expiring password!

[aerospacemango]

I suspect the script sending the email is reading the password age and if it's greater than (say) 80 days, is sending the email.

 

What it needs to do is check "is the 'password never expires' set"? If yes then skip this user else check the age and send the email. That way users who have password set to never expire won't get confusing emails.

 

I'd be interested to know what your auditors have to say about a principal with a non-expiring password!

 

This is what we're looking at, at the mo. The script does exactly what you say, and we're looking to put the exception in.

 

As for the auditors....that's my boss's problem, not mine! I, personally, don't think that it is right. The Principle should be setting the example, not extricating himself from protocols. But, I don't make the decisions.......!!!!

[gl3nnym]

@srochford I agree. Chances are it's all down to the script not checking it.

@aerospacemango Let us know how you get on.

[aerospacemango]

Ok, so we've been through the script with a fine toothcomb, and it seems to be something to do with the passwordchange date, and how it views it.

 

We are not going to let it run through, but are building a separate account to do this with. Apparently, we can't risk upsetting the big cheese/head honcho!!!

 

I was pretty certain that he wouldn't be locked out, as AD would have the final say.

 

Testing will continue!!

[srochford]

Can you post the script? Should be easy for someone to see the logic of what it's doing and then say "that looks OK" or "Oops!"

[p858snake]

If AD has picked up thats close to the reset date it may of flagged the account and changes won't take into effect till its reset? Like for example when a password does expire than you set it not to after the fact. Edited June 23, 2010 by p858snake