AD Permitted Logon Times and .NET

good day.

i need some help with AD and the permitted logon times within c# (4.0).  I am able to retrieve the permittedLogonTimes for a specific user.  I have the following set up within AD:

Not Permitted:  04:00 - 05:00, 05-06, 06-07, 07-08, 11-12, 12-13, and 13:00 - 14:00.

I have the following values from the byte array (Day of Week = Wednesday).

byte[10] = 225 ( 11100001 )
byte[11] = 248 ( 11111000 )
byte[12] = 255 ( 11111111 )

Evaluating the binary values and applying them to the appropriate time slots, i am consistently three (3) hours off.  

byte[10] 11100001 indicates no access from 01:00 - 02:00, 02:00 - 03:00, 03:00 - 04:00, and 04:00 - 05:00 - each is three hours off.

I am in the EST time zone (with daylight savings time) - GMT is currently -4.

can anyone help me figure out why the three hour difference?  any help would be appreciated.

Who is Participating?
Paul MacDonaldConnect With a Mentor Director, Information SystemsCommented:
While you note you're in the Eastern Time Zone, is it possible your DC (or the client machine) is set to be on Pacific Time?

This guy ( also notes his mask is GMT-8 (PST), but I'm not sure if that's coincidence or what.  He did develop a tool to do the coversion however:
freezingHotAuthor Commented:
our DC is set for EST.

I went through that article, as that is what got me started, but the code he supplies doesn't do exactly what i need it to do.

i can do some sort of "offset" for the three hours; however, I don't feel great about doing that as I don't understand why it is off three hours.  further, i don't know if that would be consistent and when DST is over - will it be four (4) hours off or two (2) hours off.

not a whole lot on the web regarding this topic.
Paul MacDonaldDirector, Information SystemsCommented:
No there isn't.  Since the guy in the article saw the same offset, I wonder if the .NET Framework returns Pacific Time for some reason.  You'd think it would return local (or GMT), but...

Testing DST would be as easy as setting the date to December and running the code thereafter.
freezingHotAuthor Commented:
according to another article that I found, it is stored as UTC.  just begs the question as to why i am only three hours behind and not four.

i checked the time zones settings on our AD and it is correct (if it wasn't we would have other problems).

thanks for the feedback, though.
freezingHotAuthor Commented:
i found a really nice powershell script file to retrieve and parse the logon time, if anyone is interested.

he has other powershell scripts files for AD.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.