User Logon and Account Expiration Date

Hi,

I have come accross a problem with the "Account Expiration Date" and I am
seeking clarification on how the "Account Expiration Date" is evaluated when
a user account logs on to our domain.

From previous reading, I learned that "Account Expiration Date" is stored in
UTC in AD. I have also learned that setting this date via ADUC mmc does not
result in an exact (can be any time during the following day) nor consistent
fashion (depending on the time zone of the the DC on which I set the date).

Therefore,in order to consistently set the date and also set the exact time
of the day, I now set this date via script. The script adjusts for the time
of the computer from which it is executed and hence no matter where I run the
script from, I am always ending up with the exact "Account Expiration Date"
stored in AD that I want.

I always set the date to "Midnight" e.g. #16-Dec-2008 00:00#.

The idea behind that is that I am running a script on a DC at 00:05 everyday
which checks for expired accounts and automatically performs various actions
with these accounts. E.g. running the script on 17-Dec-2008 at 00:05 will
process any account with an earlier expiration date.

All of this works fine.

However, when I use my script to set the date to e.g. #16-Dec-2008 00:00#,
it shows up on my DC in the US (EST) in ADUC mmc as 14-Decemeber-2008.

I understand why it does that but now comes my problem: I then had a user in
the US (EST) trying to lo into his computer on 15-Dec-2008 local time in the
morning and the user was unble to do that.

My sciript that I use to retire user accounts did not process the account
yet which was the right thing but apparently the user was not able to log in
as the ADUC mmc shows the date of 14-DEC-2008 and hence logon was denied on
15-Dev-08.

So does the user logon process convert the date stored in the AD attribute
"accountExpires" back into local time instead of using the UTC date stored in
AD? Does anyone know/ understand this?

Why would the logon process translate the UTC date back into local time?

Your thoughts?

Thanks for your help,

Ralf

Ralf wrote:

> I have come accross a problem with the "Account Expiration Date" and I am
> seeking clarification on how the "Account Expiration Date" is evaluated
> when
> a user account logs on to our domain.
>
> From previous reading, I learned that "Account Expiration Date" is stored
> in
> UTC in AD. I have also learned that setting this date via ADUC mmc does
> not
> result in an exact (can be any time during the following day) nor
> consistent
> fashion (depending on the time zone of the the DC on which I set the
> date).
>
> Therefore,in order to consistently set the date and also set the exact
> time
> of the day, I now set this date via script. The script adjusts for the
> time
> of the computer from which it is executed and hence no matter where I run
> the
> script from, I am always ending up with the exact "Account Expiration
> Date"
> stored in AD that I want.
>
> I always set the date to "Midnight" e.g. #16-Dec-2008 00:00#.
>
> The idea behind that is that I am running a script on a DC at 00:05
> everyday
> which checks for expired accounts and automatically performs various
> actions
> with these accounts. E.g. running the script on 17-Dec-2008 at 00:05 will
> process any account with an earlier expiration date.
>
> All of this works fine.
>
> However, when I use my script to set the date to e.g. #16-Dec-2008 00:00#,
> it shows up on my DC in the US (EST) in ADUC mmc as 14-Decemeber-2008.
>
> I understand why it does that but now comes my problem: I then had a user
> in
> the US (EST) trying to lo into his computer on 15-Dec-2008 local time in
> the
> morning and the user was unble to do that.
>
> My sciript that I use to retire user accounts did not process the account
> yet which was the right thing but apparently the user was not able to log
> in
> as the ADUC mmc shows the date of 14-DEC-2008 and hence logon was denied
> on
> 15-Dev-08.
>
> So does the user logon process convert the date stored in the AD attribute
> "accountExpires" back into local time instead of using the UTC date stored
> in
> AD? Does anyone know/ understand this?
>
> Why would the logon process translate the UTC date back into local time?
>
> Your thoughts?
>
> Thanks for your help,

The best information I have (based on my experimentation) is documented
here:

http://www.rlmueller.net/AccountExpires.htm

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Thanks Richard,

I used your referenced article (which is great, BTW) initially to set up
this whole thing.

I am just having a hard time to understand how MS handles these dates.

If a DC receive a logon request for a user account, I assume it will then
check the "accountExpires" attribute. Because that is UTC is seems to then
"translate" it back into local time for the logon authentication.

Now what happens if I have a user in the Pacific time zone with an
additional 3 hours time difference? If that user authenticates against a DC
in the EST time zone, there is another discrepancy ...

The only thing I can think of right now is to adjust the "accountExpires"
date for my "most Western" time zone when storing it in AD. This will allow
the users to log on as they are still within the same local date.

And my script processing expired accounts will have to look at the date
portion only, negelcting the "Time" so that a date comparison will still
process the account.

Not exaclty nice but I guess that will do the job, don't you think?

"Ralf" wrote:

> Hi,
>
> I have come accross a problem with the "Account Expiration Date" and I am
> seeking clarification on how the "Account Expiration Date" is evaluated when
> a user account logs on to our domain.
>
> From previous reading, I learned that "Account Expiration Date" is stored in
> UTC in AD. I have also learned that setting this date via ADUC mmc does not
> result in an exact (can be any time during the following day) nor consistent
> fashion (depending on the time zone of the the DC on which I set the date).
>
> Therefore,in order to consistently set the date and also set the exact time
> of the day, I now set this date via script. The script adjusts for the time
> of the computer from which it is executed and hence no matter where I run the
> script from, I am always ending up with the exact "Account Expiration Date"
> stored in AD that I want.
>
> I always set the date to "Midnight" e.g. #16-Dec-2008 00:00#.
>
> The idea behind that is that I am running a script on a DC at 00:05 everyday
> which checks for expired accounts and automatically performs various actions
> with these accounts. E.g. running the script on 17-Dec-2008 at 00:05 will
> process any account with an earlier expiration date.
>
> All of this works fine.
>
> However, when I use my script to set the date to e.g. #16-Dec-2008 00:00#,
> it shows up on my DC in the US (EST) in ADUC mmc as 14-Decemeber-2008.
>
> I understand why it does that but now comes my problem: I then had a user in
> the US (EST) trying to lo into his computer on 15-Dec-2008 local time in the
> morning and the user was unble to do that.
>
> My sciript that I use to retire user accounts did not process the account
> yet which was the right thing but apparently the user was not able to log in
> as the ADUC mmc shows the date of 14-DEC-2008 and hence logon was denied on
> 15-Dev-08.
>
> So does the user logon process convert the date stored in the AD attribute
> "accountExpires" back into local time instead of using the UTC date stored in
> AD? Does anyone know/ understand this?
>
> Why would the logon process translate the UTC date back into local time?
>
> Your thoughts?
>
> Thanks for your help,
>
> Ralf

The value of the accountExpires attribute is in UTC. If you use the
AccountExpirationDate property method it converts the value you supply to
UTC, taking your time zone bias into account. You can assign any date and
time with AccountExpirationDate. If you use AccountExpirationDate to assign
the value "16-Dec-2008 00:00:00", the method will convert this to UTC for
you and assign the corresponding value to accountExpires. The account will
actually expire at midnight the morning of December 16, 2008, in your time
zone. I've tested this and it is exact to the minute. If your time zone is
EST, the value assigned to accountExpires will adjusted by 5 hours, or
"16-Dec-2008 05:00:00 UTC". In this case, ADUC will show "End of December
15, 2008", which really means anytime during the following day. The only
thing AccountExpirationDate does not adjust for is Daylight Savings Time
changes.

If you are using AccountExpirationDate, do not adjust for your time zone.
This may account for what you see.

If you assigned the expiration date "16-Dec-2008" last summer (when daylight
savings time was in affect), the value saved for accountExpires would
correspond to "16-Dec-2008 04:00:00 UTC", since the current local time zone
bias would be 4 hours instead of 5. The account will actually expire at this
time in UTC, but in December when the local time zone bias is 5 hours, this
will correspond to 11:00 PM the previous day (one hour earlier than
expected). Thus, to be exact, you must adjust for daylight savings time
changes. When you assign the expiration date during the previous summer, use
AccountExpirationDate and assign "16-Dec-2008 01:00:00". Similarily, if
today you want to assign an expiration date of "15-Jun-2009 00:00:00", use
AccountExpirationDate and assign "14-Jun-2009 23:00:00".

I hope I got the time zone bias right in the above.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"Ralf" <Ralf@discussions.microsoft.com> wrote in message
news:DD1407C4-BF8B-457A-A9A4-1AD282226061@microsoft.com...
> Thanks Richard,
>
> I used your referenced article (which is great, BTW) initially to set up
> this whole thing.
>
> I am just having a hard time to understand how MS handles these dates.
>
> If a DC receive a logon request for a user account, I assume it will then
> check the "accountExpires" attribute. Because that is UTC is seems to then
> "translate" it back into local time for the logon authentication.
>
> Now what happens if I have a user in the Pacific time zone with an
> additional 3 hours time difference? If that user authenticates against a
> DC
> in the EST time zone, there is another discrepancy ...
>
> The only thing I can think of right now is to adjust the "accountExpires"
> date for my "most Western" time zone when storing it in AD. This will
> allow
> the users to log on as they are still within the same local date.
>
> And my script processing expired accounts will have to look at the date
> portion only, negelcting the "Time" so that a date comparison will still
> process the account.
>
> Not exaclty nice but I guess that will do the job, don't you think?
>
> "Ralf" wrote:
>
>> Hi,
>>
>> I have come accross a problem with the "Account Expiration Date" and I am
>> seeking clarification on how the "Account Expiration Date" is evaluated
>> when
>> a user account logs on to our domain.
>>
>> From previous reading, I learned that "Account Expiration Date" is stored
>> in
>> UTC in AD. I have also learned that setting this date via ADUC mmc does
>> not
>> result in an exact (can be any time during the following day) nor
>> consistent
>> fashion (depending on the time zone of the the DC on which I set the
>> date).
>>
>> Therefore,in order to consistently set the date and also set the exact
>> time
>> of the day, I now set this date via script. The script adjusts for the
>> time
>> of the computer from which it is executed and hence no matter where I run
>> the
>> script from, I am always ending up with the exact "Account Expiration
>> Date"
>> stored in AD that I want.
>>
>> I always set the date to "Midnight" e.g. #16-Dec-2008 00:00#.
>>
>> The idea behind that is that I am running a script on a DC at 00:05
>> everyday
>> which checks for expired accounts and automatically performs various
>> actions
>> with these accounts. E.g. running the script on 17-Dec-2008 at 00:05 will
>> process any account with an earlier expiration date.
>>
>> All of this works fine.
>>
>> However, when I use my script to set the date to e.g. #16-Dec-2008
>> 00:00#,
>> it shows up on my DC in the US (EST) in ADUC mmc as 14-Decemeber-2008.
>>
>> I understand why it does that but now comes my problem: I then had a user
>> in
>> the US (EST) trying to lo into his computer on 15-Dec-2008 local time in
>> the
>> morning and the user was unble to do that.
>>
>> My sciript that I use to retire user accounts did not process the account
>> yet which was the right thing but apparently the user was not able to log
>> in
>> as the ADUC mmc shows the date of 14-DEC-2008 and hence logon was denied
>> on
>> 15-Dev-08.
>>
>> So does the user logon process convert the date stored in the AD
>> attribute
>> "accountExpires" back into local time instead of using the UTC date
>> stored in
>> AD? Does anyone know/ understand this?
>>
>> Why would the logon process translate the UTC date back into local time?
>>
>> Your thoughts?
>>
>> Thanks for your help,
>>
>> Ralf

I think you are correct. During logon AD takes the value of accountExpires
in UTC and converts to the time zone of the user (probably the time zone of
the DC they authenticate to). If you are in the Eastern time zone (where the
time zone bias is 5 hours now) and use the AccountExpirationDate property
method to assign the value "Dec-16-2008 00:00:00", the value assigned to
accountExpires will be "Dec-16-2008 05:00:00" in UTC. When the user logs
onto a machine in the Pacific time zone, the UTC value will convert to
"Dec-15-2008 21:00:00", since the Pacific time zone bias is 8 hours (3 hours
difference).

Also, don't forget that the local time zone bias changes when Daylight
Savings Time is in affect (the value is reduced by 1 hour). If you assign
the value "Dec-16-2008 00:00:00" the previous summer, when the Eastern time
zone bias is 4 hours, the UTC value assigned to accountExpires will be
"Dec-16-2008 04:00:00". Now for a user in the Pacific time zone in December,
2008, this will convert to "Dec-15-2008 20:00:00". The accountExpires values
do not change when Daylight savings changes, but the local time zone bias
does.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"Ralf" <Ralf@discussions.microsoft.com> wrote in message
news:DD1407C4-BF8B-457A-A9A4-1AD282226061@microsoft.com...
> Thanks Richard,
>
> I used your referenced article (which is great, BTW) initially to set up
> this whole thing.
>
> I am just having a hard time to understand how MS handles these dates.
>
> If a DC receive a logon request for a user account, I assume it will then
> check the "accountExpires" attribute. Because that is UTC is seems to then
> "translate" it back into local time for the logon authentication.
>
> Now what happens if I have a user in the Pacific time zone with an
> additional 3 hours time difference? If that user authenticates against a
> DC
> in the EST time zone, there is another discrepancy ...
>
> The only thing I can think of right now is to adjust the "accountExpires"
> date for my "most Western" time zone when storing it in AD. This will
> allow
> the users to log on as they are still within the same local date.
>
> And my script processing expired accounts will have to look at the date
> portion only, negelcting the "Time" so that a date comparison will still
> process the account.
>
> Not exaclty nice but I guess that will do the job, don't you think?
>
> "Ralf" wrote:
>
>> Hi,
>>
>> I have come accross a problem with the "Account Expiration Date" and I am
>> seeking clarification on how the "Account Expiration Date" is evaluated
>> when
>> a user account logs on to our domain.
>>
>> From previous reading, I learned that "Account Expiration Date" is stored
>> in
>> UTC in AD. I have also learned that setting this date via ADUC mmc does
>> not
>> result in an exact (can be any time during the following day) nor
>> consistent
>> fashion (depending on the time zone of the the DC on which I set the
>> date).
>>
>> Therefore,in order to consistently set the date and also set the exact
>> time
>> of the day, I now set this date via script. The script adjusts for the
>> time
>> of the computer from which it is executed and hence no matter where I run
>> the
>> script from, I am always ending up with the exact "Account Expiration
>> Date"
>> stored in AD that I want.
>>
>> I always set the date to "Midnight" e.g. #16-Dec-2008 00:00#.
>>
>> The idea behind that is that I am running a script on a DC at 00:05
>> everyday
>> which checks for expired accounts and automatically performs various
>> actions
>> with these accounts. E.g. running the script on 17-Dec-2008 at 00:05 will
>> process any account with an earlier expiration date.
>>
>> All of this works fine.
>>
>> However, when I use my script to set the date to e.g. #16-Dec-2008
>> 00:00#,
>> it shows up on my DC in the US (EST) in ADUC mmc as 14-Decemeber-2008.
>>
>> I understand why it does that but now comes my problem: I then had a user
>> in
>> the US (EST) trying to lo into his computer on 15-Dec-2008 local time in
>> the
>> morning and the user was unble to do that.
>>
>> My sciript that I use to retire user accounts did not process the account
>> yet which was the right thing but apparently the user was not able to log
>> in
>> as the ADUC mmc shows the date of 14-DEC-2008 and hence logon was denied
>> on
>> 15-Dev-08.
>>
>> So does the user logon process convert the date stored in the AD
>> attribute
>> "accountExpires" back into local time instead of using the UTC date
>> stored in
>> AD? Does anyone know/ understand this?
>>
>> Why would the logon process translate the UTC date back into local time?
>>
>> Your thoughts?
>>
>> Thanks for your help,
>>
>> Ralf

Thanks for all your input.

The additional problem I have is the the expiration dates are set from
different time zones.

But based on this discussion, I think I know how to adjust my setup now to
make it compliant with my company's guidelines.

Regards,

Ralf

"Richard Mueller [MVP]" wrote:

> I think you are correct. During logon AD takes the value of accountExpires
> in UTC and converts to the time zone of the user (probably the time zone of
> the DC they authenticate to). If you are in the Eastern time zone (where the
> time zone bias is 5 hours now) and use the AccountExpirationDate property
> method to assign the value "Dec-16-2008 00:00:00", the value assigned to
> accountExpires will be "Dec-16-2008 05:00:00" in UTC. When the user logs
> onto a machine in the Pacific time zone, the UTC value will convert to
> "Dec-15-2008 21:00:00", since the Pacific time zone bias is 8 hours (3 hours
> difference).
>
> Also, don't forget that the local time zone bias changes when Daylight
> Savings Time is in affect (the value is reduced by 1 hour). If you assign
> the value "Dec-16-2008 00:00:00" the previous summer, when the Eastern time
> zone bias is 4 hours, the UTC value assigned to accountExpires will be
> "Dec-16-2008 04:00:00". Now for a user in the Pacific time zone in December,
> 2008, this will convert to "Dec-15-2008 20:00:00". The accountExpires values
> do not change when Daylight savings changes, but the local time zone bias
> does.
>
> --
> Richard Mueller
> MVP Directory Services
> Hilltop Lab - http://www.rlmueller.net
> --
>
> "Ralf" <Ralf@discussions.microsoft.com> wrote in message
> news:DD1407C4-BF8B-457A-A9A4-1AD282226061@microsoft.com...
> > Thanks Richard,
> >
> > I used your referenced article (which is great, BTW) initially to set up
> > this whole thing.
> >
> > I am just having a hard time to understand how MS handles these dates.
> >
> > If a DC receive a logon request for a user account, I assume it will then
> > check the "accountExpires" attribute. Because that is UTC is seems to then
> > "translate" it back into local time for the logon authentication.
> >
> > Now what happens if I have a user in the Pacific time zone with an
> > additional 3 hours time difference? If that user authenticates against a
> > DC
> > in the EST time zone, there is another discrepancy ...
> >
> > The only thing I can think of right now is to adjust the "accountExpires"
> > date for my "most Western" time zone when storing it in AD. This will
> > allow
> > the users to log on as they are still within the same local date.
> >
> > And my script processing expired accounts will have to look at the date
> > portion only, negelcting the "Time" so that a date comparison will still
> > process the account.
> >
> > Not exaclty nice but I guess that will do the job, don't you think?
> >
> > "Ralf" wrote:
> >
> >> Hi,
> >>
> >> I have come accross a problem with the "Account Expiration Date" and I am
> >> seeking clarification on how the "Account Expiration Date" is evaluated
> >> when
> >> a user account logs on to our domain.
> >>
> >> From previous reading, I learned that "Account Expiration Date" is stored
> >> in
> >> UTC in AD. I have also learned that setting this date via ADUC mmc does
> >> not
> >> result in an exact (can be any time during the following day) nor
> >> consistent
> >> fashion (depending on the time zone of the the DC on which I set the
> >> date).
> >>
> >> Therefore,in order to consistently set the date and also set the exact
> >> time
> >> of the day, I now set this date via script. The script adjusts for the
> >> time
> >> of the computer from which it is executed and hence no matter where I run
> >> the
> >> script from, I am always ending up with the exact "Account Expiration
> >> Date"
> >> stored in AD that I want.
> >>
> >> I always set the date to "Midnight" e.g. #16-Dec-2008 00:00#.
> >>
> >> The idea behind that is that I am running a script on a DC at 00:05
> >> everyday
> >> which checks for expired accounts and automatically performs various
> >> actions
> >> with these accounts. E.g. running the script on 17-Dec-2008 at 00:05 will
> >> process any account with an earlier expiration date.
> >>
> >> All of this works fine.
> >>
> >> However, when I use my script to set the date to e.g. #16-Dec-2008
> >> 00:00#,
> >> it shows up on my DC in the US (EST) in ADUC mmc as 14-Decemeber-2008.
> >>
> >> I understand why it does that but now comes my problem: I then had a user
> >> in
> >> the US (EST) trying to lo into his computer on 15-Dec-2008 local time in
> >> the
> >> morning and the user was unble to do that.
> >>
> >> My sciript that I use to retire user accounts did not process the account
> >> yet which was the right thing but apparently the user was not able to log
> >> in
> >> as the ADUC mmc shows the date of 14-DEC-2008 and hence logon was denied
> >> on
> >> 15-Dev-08.
> >>
> >> So does the user logon process convert the date stored in the AD
> >> attribute
> >> "accountExpires" back into local time instead of using the UTC date
> >> stored in
> >> AD? Does anyone know/ understand this?
> >>
> >> Why would the logon process translate the UTC date back into local time?
> >>
> >> Your thoughts?
> >>
> >> Thanks for your help,
> >>
> >> Ralf
>
>
>