RE: [ActiveDir] accountExpires field
Indeed it is Jason ... I've read of DStime but haven't yet experienced it. Simply using an expiry date of today and performing math on the raw value eventually equates to a roughly accurate result of around 401 years. Thanks. Dean -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Krueger, Jason Sent: Friday, February 15, 2002 10:45 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] accountExpires field It most definitely is FILETIME since you *must* scale the number by 10,000,000 (100 ns = 1e-7 s) in the conversion formula. I do remember reading about DSTIME in Gil's book and unfortunately he is wrong. To be fair he did write that book on one of the earliest versions of W2K and AD so there *may* indeed have been such a beast as DSTIME being used. Perhaps MS thought better of themselves before adding yet another date/time format to the history books? ;) - Jason -Original Message- From: Tony Murray [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 3:21 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] accountExpires field The source I had for the DSTIME information was Gil Kirkpatrick's book, Active Directory Programming. He makes the distinction between DSTIME (expressed as the number of seconds since January 1, 1601) and Win32 FILETIME (expressed as 100-nanosecond ticks since January 1, 1601). Some attributes (e.g. accountExpires and creationTime) are stored as a DSTIME and others are stored as a Win32 FILETIME. You can scale DSTIME to FILETIME by multiplying by 1. Although Gil Kirkpatrick makes a number of references to DSTIME, I haven't been able to find any match for this on the Microsoft web site. I'll send an email to Gil and see if he can give us any further information. Tony -Original Message- From: Dean Wells [mailto:[EMAIL PROTECTED]] Sent: 14 February 2002 19:32 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field IIRC, it's the epoch in the revised Julian calendar that marks the point from which it and the Gregorian calendar maintain the passage of time identically ... I believe this correlation elapses around 2800AD. In addition, I was concerned about the exact interval unit (one second or 100 nanosecond units), it turned out to be 100 nanosecond units. HTH Dean -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Al Lilianstrom Sent: Thursday, February 14, 2002 12:34 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] accountExpires field Thanks for all the help on this one and the code (Jeff and Jason). I really appreciate it. Any reason why MS picked this date? al Tony Murray wrote: Hi Al Apparently, some early versions of the MS documentation incorrectly state that the value is the number of seconds since January 1, 1970. The attribute is expressed as a DSTIME. This is the number of seconds since January 1, 1601. Hope this helps. Tony -- Al Lilianstrom CD/OSS/CSI [EMAIL PROTECTED] List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] accountExpires field
Thanks for the clear explanation, Jason. Tony -- Original Message -- From: Krueger, Jason [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Fri, 15 Feb 2002 10:45:10 -0500 It most definitely is FILETIME since you *must* scale the number by 10,000,000 (100 ns = 1e-7 s) in the conversion formula. I do remember reading about DSTIME in Gil's book and unfortunately he is wrong. To be fair he did write that book on one of the earliest versions of W2K and AD so there *may* indeed have been such a beast as DSTIME being used. Perhaps MS thought better of themselves before adding yet another date/time format to the history books? ;) - Jason -Original Message- From: Tony Murray [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 3:21 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] accountExpires field The source I had for the DSTIME information was Gil Kirkpatrick's book, Active Directory Programming. He makes the distinction between DSTIME (expressed as the number of seconds since January 1, 1601) and Win32 FILETIME (expressed as 100-nanosecond ticks since January 1, 1601). Some attributes (e.g. accountExpires and creationTime) are stored as a DSTIME and others are stored as a Win32 FILETIME. You can scale DSTIME to FILETIME by multiplying by 1. Although Gil Kirkpatrick makes a number of references to DSTIME, I haven't been able to find any match for this on the Microsoft web site. I'll send an email to Gil and see if he can give us any further information. Tony -Original Message- From: Dean Wells [mailto:[EMAIL PROTECTED]] Sent: 14 February 2002 19:32 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field IIRC, it's the epoch in the revised Julian calendar that marks the point from which it and the Gregorian calendar maintain the passage of time identically ... I believe this correlation elapses around 2800AD. In addition, I was concerned about the exact interval unit (one second or 100 nanosecond units), it turned out to be 100 nanosecond units. HTH Dean -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Al Lilianstrom Sent: Thursday, February 14, 2002 12:34 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] accountExpires field Thanks for all the help on this one and the code (Jeff and Jason). I really appreciate it. Any reason why MS picked this date? al Tony Murray wrote: Hi Al Apparently, some early versions of the MS documentation incorrectly state that the value is the number of seconds since January 1, 1970. The attribute is expressed as a DSTIME. This is the number of seconds since January 1, 1601. Hope this helps. Tony -- Al Lilianstrom CD/OSS/CSI [EMAIL PROTECTED] List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] accountExpires field
Have a look at www.sysinternals.com for the Dumpacl utility. This allows you to extract user details into a delimited file from a domain or server including 'last logon time' and lots more. It is free and the resulting data can then be manipulated into a script to finish the job. -Original Message- From: Tom Meunier [mailto:[EMAIL PROTECTED]] Sent: Thursday, 14 February 2002 5:45 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Fun stuff. I have a department manager who wants to issue 100 Exchange mailboxes, then revoke those that haven't logged in in 60 days, so they can be deleted and the licenses re-used. I believe this is what I'm looking at running against every DC I have, then concatenating those results. Unless someone knows an easier way? Oh, for Netware's NLIST utility: NLIST USER WHERE LAST LOGIN TIME LT 12/14/01 (no logon since 12/14/01) NLIST USER WHERE LAST LOGIN TIME NEXISTS (no logon since forever) -Original Message- From: Krueger, Jason [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 10:13 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] accountExpires field From: Al Lilianstrom [mailto:[EMAIL PROTECTED]] Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. This is unfortunately horribly inaccurate. I've reported it to Microsoft a long while back, but I don't think they have yet cleaned up all documenation references that state it as such. Anything in AD that is a Date/Time attribute and uses the INTEGER8 syntax is using the same representation as the FILETIME format (http://www.vbapi.com/ref/f/filetime.html). The 64-bit integer is actually the number of *100-nanosecond* intervals since Jan 1, 1601!!! (no wonder it needs 64 bits!). For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you use the module I developed and have attached (DateTime.pm - put it in your perl\site\lib\Win32 directory) you can convert to a human readable GMT date using this oneliner: perl -MWin32::DateTime -e print scalar gmtime Win32::DateTime-new(big_int = shift)-utc_seconds 1265952240 Sat Mar 2 06:00:00 2002 The module requires Win32::API, Math::BigInt, Date::Manip and a recent version of Perl/ActivePerl. Here's the minimal POD i've put in it so far NAME Win32::DateTime - OO model for Win32 Date/Time conversion SYNOPSIS use Win32::DateTime; # new() valid args: # utc_seconds - epoch seconds # big_int - string decimal representation of 64-bit LargeInteger # filetime- either 8 byte packed struct, 2 integer element array ref # OR Win32::OLE LargeInteger object (from ADO) # systemtime - 16 byte packed struct my $dt = Win32::DateTime-new(utc_seconds = time()); print $dt-utc_seconds; # secs since epoch (midnight 1970 GMT) print $dt-filetime;# filetime structure print $dt-big_int; # big integer object print $dt-big_int_string; # useful in ADO queries print $dt-systemtime; # much like what localtime() returns DESCRIPTION Helps you convert between the many ugly date/time formats that one has to deal with on windows and especially Active Directory. EXPORT None by default. AUTHOR [EMAIL PROTECTED] SEE ALSO Math::BigInt Win32::API Date::Manip If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. Odd behavior, but probably some sort of builtin failsafe since it interpreted the date as somewhere in the 1600's. So after all that - does anyone know exactly how to calculate the number for that field? The basic formula for UTC seconds = FILETIME 100-nanoseconds conversion is utc = floor((filetime - 116,444,736,000,000,000) / 10,000,000) 116,444,736,000,000,000 = number of 100-nanosecond intervals between epoch and Jan 1, 1601 10,000,000 = number of 100-nanosecond intervals in a second Simple formula but requires 64-bit integer math so it's not trivial on 32-bit platform. That's why I needed to use Math::BigInt. I also have conversions = Win32 systemtime format. If you want the gory details you
RE: [ActiveDir] accountExpires field
I am unable to find this utility at the site. There is DUMPACL that shows up in a search either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Lloyd Sent: Friday, February 15, 2002 11:51 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Have a look at www.sysinternals.com for the Dumpacl utility. This allows you to extract user details into a delimited file from a domain or server including 'last logon time' and lots more. It is free and the resulting data can then be manipulated into a script to finish the job. -Original Message- From: Tom Meunier [mailto:[EMAIL PROTECTED]] Sent: Thursday, 14 February 2002 5:45 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Fun stuff. I have a department manager who wants to issue 100 Exchange mailboxes, then revoke those that haven't logged in in 60 days, so they can be deleted and the licenses re-used. I believe this is what I'm looking at running against every DC I have, then concatenating those results. Unless someone knows an easier way? Oh, for Netware's NLIST utility: NLIST USER WHERE LAST LOGIN TIME LT 12/14/01 (no logon since 12/14/01) NLIST USER WHERE LAST LOGIN TIME NEXISTS (no logon since forever) -Original Message- From: Krueger, Jason [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 10:13 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] accountExpires field From: Al Lilianstrom [mailto:[EMAIL PROTECTED]] Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. This is unfortunately horribly inaccurate. I've reported it to Microsoft a long while back, but I don't think they have yet cleaned up all documenation references that state it as such. Anything in AD that is a Date/Time attribute and uses the INTEGER8 syntax is using the same representation as the FILETIME format (http://www.vbapi.com/ref/f/filetime.html). The 64-bit integer is actually the number of *100-nanosecond* intervals since Jan 1, 1601!!! (no wonder it needs 64 bits!). For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you use the module I developed and have attached (DateTime.pm - put it in your perl\site\lib\Win32 directory) you can convert to a human readable GMT date using this oneliner: perl -MWin32::DateTime -e print scalar gmtime Win32::DateTime-new(big_int = shift)-utc_seconds 1265952240 Sat Mar 2 06:00:00 2002 The module requires Win32::API, Math::BigInt, Date::Manip and a recent version of Perl/ActivePerl. Here's the minimal POD i've put in it so far NAME Win32::DateTime - OO model for Win32 Date/Time conversion SYNOPSIS use Win32::DateTime; # new() valid args: # utc_seconds - epoch seconds # big_int - string decimal representation of 64-bit LargeInteger # filetime- either 8 byte packed struct, 2 integer element array ref # OR Win32::OLE LargeInteger object (from ADO) # systemtime - 16 byte packed struct my $dt = Win32::DateTime-new(utc_seconds = time()); print $dt-utc_seconds; # secs since epoch (midnight 1970 GMT) print $dt-filetime;# filetime structure print $dt-big_int; # big integer object print $dt-big_int_string; # useful in ADO queries print $dt-systemtime; # much like what localtime() returns DESCRIPTION Helps you convert between the many ugly date/time formats that one has to deal with on windows and especially Active Directory. EXPORT None by default. AUTHOR [EMAIL PROTECTED] SEE ALSO Math::BigInt Win32::API Date::Manip If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. Odd behavior, but probably some sort of builtin failsafe since it interpreted the date as somewhere in the 1600's. So after all that - does anyone know exactly how to calculate the number for that field? The basic formula for UTC seconds = FILETIME 100-nanoseconds conversion is utc = floor((filetime - 116,444,736,000,000,000) / 10,000,000) 116,444,736,000,000,000 = number of 100-nanosecond intervals between epoch
Re: [ActiveDir] accountExpires field
There is a dumpacl from SomarSoft. See http://www.somarsoft.com/somarsoft_main.htm#DumpAcl for more. al Joe Sargent wrote: I am unable to find this utility at the site. There is DUMPACL that shows up in a search either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Lloyd Sent: Friday, February 15, 2002 11:51 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Have a look at www.sysinternals.com for the Dumpacl utility. This allows you to extract user details into a delimited file from a domain or server including 'last logon time' and lots more. It is free and the resulting data can then be manipulated into a script to finish the job. -Original Message- From: Tom Meunier [mailto:[EMAIL PROTECTED]] Sent: Thursday, 14 February 2002 5:45 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Fun stuff. I have a department manager who wants to issue 100 Exchange mailboxes, then revoke those that haven't logged in in 60 days, so they can be deleted and the licenses re-used. I believe this is what I'm looking at running against every DC I have, then concatenating those results. Unless someone knows an easier way? Oh, for Netware's NLIST utility: NLIST USER WHERE LAST LOGIN TIME LT 12/14/01 (no logon since 12/14/01) NLIST USER WHERE LAST LOGIN TIME NEXISTS (no logon since forever) -Original Message- From: Krueger, Jason [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 10:13 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] accountExpires field From: Al Lilianstrom [mailto:[EMAIL PROTECTED]] Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. This is unfortunately horribly inaccurate. I've reported it to Microsoft a long while back, but I don't think they have yet cleaned up all documenation references that state it as such. Anything in AD that is a Date/Time attribute and uses the INTEGER8 syntax is using the same representation as the FILETIME format (http://www.vbapi.com/ref/f/filetime.html). The 64-bit integer is actually the number of *100-nanosecond* intervals since Jan 1, 1601!!! (no wonder it needs 64 bits!). For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you use the module I developed and have attached (DateTime.pm - put it in your perl\site\lib\Win32 directory) you can convert to a human readable GMT date using this oneliner: perl -MWin32::DateTime -e print scalar gmtime Win32::DateTime-new(big_int = shift)-utc_seconds 1265952240 Sat Mar 2 06:00:00 2002 The module requires Win32::API, Math::BigInt, Date::Manip and a recent version of Perl/ActivePerl. Here's the minimal POD i've put in it so far NAME Win32::DateTime - OO model for Win32 Date/Time conversion SYNOPSIS use Win32::DateTime; # new() valid args: # utc_seconds - epoch seconds # big_int - string decimal representation of 64-bit LargeInteger # filetime- either 8 byte packed struct, 2 integer element array ref # OR Win32::OLE LargeInteger object (from ADO) # systemtime - 16 byte packed struct my $dt = Win32::DateTime-new(utc_seconds = time()); print $dt-utc_seconds; # secs since epoch (midnight 1970 GMT) print $dt-filetime;# filetime structure print $dt-big_int; # big integer object print $dt-big_int_string; # useful in ADO queries print $dt-systemtime; # much like what localtime() returns DESCRIPTION Helps you convert between the many ugly date/time formats that one has to deal with on windows and especially Active Directory. EXPORT None by default. AUTHOR [EMAIL PROTECTED] SEE ALSO Math::BigInt Win32::API Date::Manip If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. Odd behavior, but probably some sort of builtin failsafe since it interpreted the date as somewhere in the 1600's. So after all that - does anyone know
RE: [ActiveDir] accountExpires field
Sorry about the bum steer! It is now bundled with the Hyena product as the Dumpsec suite! This is available from the Somarsoft site which is managed by Sysinternals. Hyena is not a bad Administrative tool for NT/2000 mixed sites if you have not played with it as well! Cheers -Original Message- From: Joe Sargent [mailto:[EMAIL PROTECTED]] Sent: Friday, 15 February 2002 5:02 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field I am unable to find this utility at the site. There is DUMPACL that shows up in a search either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Lloyd Sent: Friday, February 15, 2002 11:51 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Have a look at www.sysinternals.com for the Dumpacl utility. This allows you to extract user details into a delimited file from a domain or server including 'last logon time' and lots more. It is free and the resulting data can then be manipulated into a script to finish the job. -Original Message- From: Tom Meunier [mailto:[EMAIL PROTECTED]] Sent: Thursday, 14 February 2002 5:45 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Fun stuff. I have a department manager who wants to issue 100 Exchange mailboxes, then revoke those that haven't logged in in 60 days, so they can be deleted and the licenses re-used. I believe this is what I'm looking at running against every DC I have, then concatenating those results. Unless someone knows an easier way? Oh, for Netware's NLIST utility: NLIST USER WHERE LAST LOGIN TIME LT 12/14/01 (no logon since 12/14/01) NLIST USER WHERE LAST LOGIN TIME NEXISTS (no logon since forever) -Original Message- From: Krueger, Jason [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 10:13 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] accountExpires field From: Al Lilianstrom [mailto:[EMAIL PROTECTED]] Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. This is unfortunately horribly inaccurate. I've reported it to Microsoft a long while back, but I don't think they have yet cleaned up all documenation references that state it as such. Anything in AD that is a Date/Time attribute and uses the INTEGER8 syntax is using the same representation as the FILETIME format (http://www.vbapi.com/ref/f/filetime.html). The 64-bit integer is actually the number of *100-nanosecond* intervals since Jan 1, 1601!!! (no wonder it needs 64 bits!). For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you use the module I developed and have attached (DateTime.pm - put it in your perl\site\lib\Win32 directory) you can convert to a human readable GMT date using this oneliner: perl -MWin32::DateTime -e print scalar gmtime Win32::DateTime-new(big_int = shift)-utc_seconds 1265952240 Sat Mar 2 06:00:00 2002 The module requires Win32::API, Math::BigInt, Date::Manip and a recent version of Perl/ActivePerl. Here's the minimal POD i've put in it so far NAME Win32::DateTime - OO model for Win32 Date/Time conversion SYNOPSIS use Win32::DateTime; # new() valid args: # utc_seconds - epoch seconds # big_int - string decimal representation of 64-bit LargeInteger # filetime- either 8 byte packed struct, 2 integer element array ref # OR Win32::OLE LargeInteger object (from ADO) # systemtime - 16 byte packed struct my $dt = Win32::DateTime-new(utc_seconds = time()); print $dt-utc_seconds; # secs since epoch (midnight 1970 GMT) print $dt-filetime;# filetime structure print $dt-big_int; # big integer object print $dt-big_int_string; # useful in ADO queries print $dt-systemtime; # much like what localtime() returns DESCRIPTION Helps you convert between the many ugly date/time formats that one has to deal with on windows and especially Active Directory. EXPORT None by default. AUTHOR [EMAIL PROTECTED] SEE ALSO Math::BigInt Win32::API Date::Manip If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using
[ActiveDir] accountExpires field
Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. So after all that - does anyone know exactly how to calculate the number for that field? tia, al -- Al Lilianstrom CD/OSS/CSI [EMAIL PROTECTED] List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] accountExpires field
Hi Al Apparently, some early versions of the MS documentation incorrectly state that the value is the number of seconds since January 1, 1970. The attribute is expressed as a DSTIME. This is the number of seconds since January 1, 1601. Hope this helps. Tony -- Original Message -- From: Al Lilianstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Thu, 14 Feb 2002 09:28:07 -0600 Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. So after all that - does anyone know exactly how to calculate the number for that field? tia, al -- Al Lilianstrom CD/OSS/CSI [EMAIL PROTECTED] List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] accountExpires field
From: Al Lilianstrom [mailto:[EMAIL PROTECTED]] Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. This is unfortunately horribly inaccurate. I've reported it to Microsoft a long while back, but I don't think they have yet cleaned up all documenation references that state it as such. Anything in AD that is a Date/Time attribute and uses the INTEGER8 syntax is using the same representation as the FILETIME format (http://www.vbapi.com/ref/f/filetime.html). The 64-bit integer is actually the number of *100-nanosecond* intervals since Jan 1, 1601!!! (no wonder it needs 64 bits!). For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you use the module I developed and have attached (DateTime.pm - put it in your perl\site\lib\Win32 directory) you can convert to a human readable GMT date using this oneliner: perl -MWin32::DateTime -e print scalar gmtime Win32::DateTime-new(big_int = shift)-utc_seconds 1265952240 Sat Mar 2 06:00:00 2002 The module requires Win32::API, Math::BigInt, Date::Manip and a recent version of Perl/ActivePerl. Here's the minimal POD i've put in it so far NAME Win32::DateTime - OO model for Win32 Date/Time conversion SYNOPSIS use Win32::DateTime; # new() valid args: # utc_seconds - epoch seconds # big_int - string decimal representation of 64-bit LargeInteger # filetime- either 8 byte packed struct, 2 integer element array ref # OR Win32::OLE LargeInteger object (from ADO) # systemtime - 16 byte packed struct my $dt = Win32::DateTime-new(utc_seconds = time()); print $dt-utc_seconds; # secs since epoch (midnight 1970 GMT) print $dt-filetime;# filetime structure print $dt-big_int; # big integer object print $dt-big_int_string; # useful in ADO queries print $dt-systemtime; # much like what localtime() returns DESCRIPTION Helps you convert between the many ugly date/time formats that one has to deal with on windows and especially Active Directory. EXPORT None by default. AUTHOR [EMAIL PROTECTED] SEE ALSO Math::BigInt Win32::API Date::Manip If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. Odd behavior, but probably some sort of builtin failsafe since it interpreted the date as somewhere in the 1600's. So after all that - does anyone know exactly how to calculate the number for that field? The basic formula for UTC seconds = FILETIME 100-nanoseconds conversion is utc = floor((filetime - 116,444,736,000,000,000) / 10,000,000) 116,444,736,000,000,000 = number of 100-nanosecond intervals between epoch and Jan 1, 1601 10,000,000 = number of 100-nanosecond intervals in a second Simple formula but requires 64-bit integer math so it's not trivial on 32-bit platform. That's why I needed to use Math::BigInt. I also have conversions = Win32 systemtime format. If you want the gory details you can examine the module code. Cheers, - Jason PS: If the attachment gets filtered out, let me know and I'll try to post it somewhere. DateTime.pm Description: Binary data
RE: [ActiveDir] accountExpires field
Though I've not manipulated the value personally, I was under the impression it was maintained using Windows Filetime ... a measurement of 100ns intervals since Jan. 1 1601. IIRC, this is the same syntax used by LastLogon and LastLogoff. Dean -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Murray Sent: Thursday, February 14, 2002 10:48 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] accountExpires field Hi Al Apparently, some early versions of the MS documentation incorrectly state that the value is the number of seconds since January 1, 1970. The attribute is expressed as a DSTIME. This is the number of seconds since January 1, 1601. Hope this helps. Tony -- Original Message -- From: Al Lilianstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Thu, 14 Feb 2002 09:28:07 -0600 Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. So after all that - does anyone know exactly how to calculate the number for that field? tia, al -- Al Lilianstrom CD/OSS/CSI [EMAIL PROTECTED] List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] accountExpires field
Thanks for all the help on this one and the code (Jeff and Jason). I really appreciate it. Any reason why MS picked this date? al Tony Murray wrote: Hi Al Apparently, some early versions of the MS documentation incorrectly state that the value is the number of seconds since January 1, 1970. The attribute is expressed as a DSTIME. This is the number of seconds since January 1, 1601. Hope this helps. Tony -- Al Lilianstrom CD/OSS/CSI [EMAIL PROTECTED] List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] accountExpires field
Fun stuff. I have a department manager who wants to issue 100 Exchange mailboxes, then revoke those that haven't logged in in 60 days, so they can be deleted and the licenses re-used. I believe this is what I'm looking at running against every DC I have, then concatenating those results. Unless someone knows an easier way? Oh, for Netware's NLIST utility: NLIST USER WHERE LAST LOGIN TIME LT 12/14/01 (no logon since 12/14/01) NLIST USER WHERE LAST LOGIN TIME NEXISTS (no logon since forever) -Original Message- From: Krueger, Jason [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 10:13 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] accountExpires field From: Al Lilianstrom [mailto:[EMAIL PROTECTED]] Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. This is unfortunately horribly inaccurate. I've reported it to Microsoft a long while back, but I don't think they have yet cleaned up all documenation references that state it as such. Anything in AD that is a Date/Time attribute and uses the INTEGER8 syntax is using the same representation as the FILETIME format (http://www.vbapi.com/ref/f/filetime.html). The 64-bit integer is actually the number of *100-nanosecond* intervals since Jan 1, 1601!!! (no wonder it needs 64 bits!). For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you use the module I developed and have attached (DateTime.pm - put it in your perl\site\lib\Win32 directory) you can convert to a human readable GMT date using this oneliner: perl -MWin32::DateTime -e print scalar gmtime Win32::DateTime-new(big_int = shift)-utc_seconds 1265952240 Sat Mar 2 06:00:00 2002 The module requires Win32::API, Math::BigInt, Date::Manip and a recent version of Perl/ActivePerl. Here's the minimal POD i've put in it so far NAME Win32::DateTime - OO model for Win32 Date/Time conversion SYNOPSIS use Win32::DateTime; # new() valid args: # utc_seconds - epoch seconds # big_int - string decimal representation of 64-bit LargeInteger # filetime- either 8 byte packed struct, 2 integer element array ref # OR Win32::OLE LargeInteger object (from ADO) # systemtime - 16 byte packed struct my $dt = Win32::DateTime-new(utc_seconds = time()); print $dt-utc_seconds; # secs since epoch (midnight 1970 GMT) print $dt-filetime;# filetime structure print $dt-big_int; # big integer object print $dt-big_int_string; # useful in ADO queries print $dt-systemtime; # much like what localtime() returns DESCRIPTION Helps you convert between the many ugly date/time formats that one has to deal with on windows and especially Active Directory. EXPORT None by default. AUTHOR [EMAIL PROTECTED] SEE ALSO Math::BigInt Win32::API Date::Manip If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. Odd behavior, but probably some sort of builtin failsafe since it interpreted the date as somewhere in the 1600's. So after all that - does anyone know exactly how to calculate the number for that field? The basic formula for UTC seconds = FILETIME 100-nanoseconds conversion is utc = floor((filetime - 116,444,736,000,000,000) / 10,000,000) 116,444,736,000,000,000 = number of 100-nanosecond intervals between epoch and Jan 1, 1601 10,000,000 = number of 100-nanosecond intervals in a second Simple formula but requires 64-bit integer math so it's not trivial on 32-bit platform. That's why I needed to use Math::BigInt. I also have conversions = Win32 systemtime format. If you want the gory details you can examine the module code. Cheers, - Jason PS: If the attachment gets filtered out, let me know and I'll try to post it somewhere. List info : http://www.activedir.org/mail_list.htm List FAQ: http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] accountExpires field
Actually, I just had to look at joeware.net for the freeware getuserinfo.exe. SWEET! -Original Message- From: Tom Meunier Sent: Thursday, February 14, 2002 11:45 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] accountExpires field Fun stuff. I have a department manager who wants to issue 100 Exchange mailboxes, then revoke those that haven't logged in in 60 days, so they can be deleted and the licenses re-used. I believe this is what I'm looking at running against every DC I have, then concatenating those results. Unless someone knows an easier way? Oh, for Netware's NLIST utility: NLIST USER WHERE LAST LOGIN TIME LT 12/14/01 (no logon since 12/14/01) NLIST USER WHERE LAST LOGIN TIME NEXISTS (no logon since forever) -Original Message- From: Krueger, Jason [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 10:13 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] accountExpires field From: Al Lilianstrom [mailto:[EMAIL PROTECTED]] Hi, I'm managing AD accounts from a Unix system via LDAP. I'm trying to set the accountExpires field with the proper value. The schema definition for the field is as follows; Syntax - INTEGER8 OID - 1.2.840.113556.1.4.159 Digging deeper I find that this field is the number of seconds since 00:00:00 on Jan 1, 1970 (Unix epoch time) expressed as a large integer. This is unfortunately horribly inaccurate. I've reported it to Microsoft a long while back, but I don't think they have yet cleaned up all documenation references that state it as such. Anything in AD that is a Date/Time attribute and uses the INTEGER8 syntax is using the same representation as the FILETIME format (http://www.vbapi.com/ref/f/filetime.html). The 64-bit integer is actually the number of *100-nanosecond* intervals since Jan 1, 1601!!! (no wonder it needs 64 bits!). For example - if I set an account (using AD UsersComputers) with a account expiration date of Friday March 1, 2002 and then look at that field using ldapsearch the field is accountExpires: 1265952240 If you use the module I developed and have attached (DateTime.pm - put it in your perl\site\lib\Win32 directory) you can convert to a human readable GMT date using this oneliner: perl -MWin32::DateTime -e print scalar gmtime Win32::DateTime-new(big_int = shift)-utc_seconds 1265952240 Sat Mar 2 06:00:00 2002 The module requires Win32::API, Math::BigInt, Date::Manip and a recent version of Perl/ActivePerl. Here's the minimal POD i've put in it so far NAME Win32::DateTime - OO model for Win32 Date/Time conversion SYNOPSIS use Win32::DateTime; # new() valid args: # utc_seconds - epoch seconds # big_int - string decimal representation of 64-bit LargeInteger # filetime- either 8 byte packed struct, 2 integer element array ref # OR Win32::OLE LargeInteger object (from ADO) # systemtime - 16 byte packed struct my $dt = Win32::DateTime-new(utc_seconds = time()); print $dt-utc_seconds; # secs since epoch (midnight 1970 GMT) print $dt-filetime;# filetime structure print $dt-big_int; # big integer object print $dt-big_int_string; # useful in ADO queries print $dt-systemtime; # much like what localtime() returns DESCRIPTION Helps you convert between the many ugly date/time formats that one has to deal with on windows and especially Active Directory. EXPORT None by default. AUTHOR [EMAIL PROTECTED] SEE ALSO Math::BigInt Win32::API Date::Manip If you convert that number (in seconds) to a date you get December 31st, 1969 as it is larger than expected by any of the perl code I've used. If you convert the date, Friday March 1, 2002 to seconds since the epoch you get 1014962400 seconds. If you plug that number in as a expiration date via a ldapmodify to an account the date AD UC returns is Thursday Feb 14, 2002. Setting to any date using epoch seconds seems to set to the current date. Odd behavior, but probably some sort of builtin failsafe since it interpreted the date as somewhere in the 1600's. So after all that - does anyone know exactly how to calculate the number for that field? The basic formula for UTC seconds = FILETIME 100-nanoseconds conversion is utc = floor((filetime - 116,444,736,000,000,000) / 10,000,000) 116,444,736,000,000,000 = number of 100-nanosecond intervals between epoch and Jan 1, 1601 10,000,000 = number of 100-nanosecond intervals in a second Simple formula but requires 64-bit integer math so it's not trivial on 32-bit platform. That's why I needed to use Math::BigInt. I also have conversions = Win32 systemtime format. If you want the gory details you can examine the module code. Cheers, - Jason PS: If the attachment gets filtered out, let me know and I'll try to post it somewhere. List info : http://www.activedir.org/mail_list.htm List FAQ: http
