|
Posted by Roger Abell [MVP] on June 28, 2007, 3:09 am
If you were Registered and logged in, you could reply and use other advanced thread options
> We're using a W2K3 Domain with password policy to force the users to
> change
> there passwords after a few weeks. The domain login is used to access some
> SQL-Servers (in the same domain). So far, so good - that's works fine.
>
> But after a few weeks, the users get a "hint" that tells them to change
> their password in a few days. Good users do that at last one or two days
> _before_ the password finally expires - but there are always some stupid
> ones
> who don't.
>
> What happens, is the following: For example, the user logs on to the
> domain
> at 8:00 AM. The password expires on the same day, but on 10:00 AM. During
> log-on, the password still is valid, so the user is NOT forced to change
> the
> password right now - instead everything works fine for the moment...
> Two hours later, the password expires. The user still is logged on to his
> machine, but neither can access the network nor SQL-Servers (because the
> password is expired...)
>
> How can I solve this? I propose 3 solutions - but for none of them do I
> really know how:
>
> 1.) The Password should not expire at 10:00 AM, but at e.g. 11:59 PM
> 2.) The user is force to change the password during log-on at 8:00 AM,
> reagrding that it will expire on the same day (or "in less than x hours)
> 3.) The users finally uses his/her brain... But that's the most impossible
> one ;-)
>
> Bart Simpson
>
Of those, you are probably stuck with selection 3.
Perhaps they will be good monkeys and learn :-)
Is not the saying something like burn me once shame on you,
burn me twice shame on me ?
I am glad you did not mention option 4, remove password
expiration. Perhaps option 5 might help the monkeys out,
that is, use a longer expiration period - perhaps they are
delaying in order to get the most days due to the high amount
of password change if done every MaxPwdAge - WarnDays.
Also, the issue might be lessened if they were using an access
that relied on Kerberos, as apparently they are reauthenticating
via NTLM rather than presenting a service ticket to access
the SQL, and that reauthentication is failing.
| 
XML site map