Results 1 to 6 of 6

Thread: User Logon and Account Expiration Date

  1. #1
    Ralf Guest

    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

  2. #2
    Richard Mueller [MVP] Guest

    Re: User Logon and Account Expiration Date

    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
    --



  3. #3
    Ralf Guest

    RE: User Logon and Account Expiration Date

    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


  4. #4
    Richard Mueller [MVP] Guest

    Re: User Logon and Account Expiration Date

    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




  5. #5
    Richard Mueller [MVP] Guest

    Re: User Logon and Account Expiration Date

    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




  6. #6
    Ralf Guest

    Re: User Logon and Account Expiration Date

    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

    >
    >
    >


Similar Threads

  1. Cannot see HP #10 ink cartridges expiration date
    By GoutamB in forum Hardware Peripherals
    Replies: 7
    Last Post: 07-09-2011, 10:37 PM
  2. Get Domain Name Expiration Date
    By Gaige in forum Technology & Internet
    Replies: 7
    Last Post: 12-05-2010, 10:41 AM
  3. How to set Password Expiration Date on Windows Server
    By Robbin M in forum Active Directory
    Replies: 1
    Last Post: 03-07-2009, 04:53 AM
  4. Logon Failure User Account Restriction
    By bawalker@gmail.com in forum Active Directory
    Replies: 4
    Last Post: 25-02-2009, 12:39 AM
  5. Change the expiration date
    By Chad Gross in forum Active Directory
    Replies: 1
    Last Post: 13-12-2008, 10:04 AM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Page generated in 1,711,619,047.57874 seconds with 17 queries