a talented ad guru brought this up to my attention. i thought it was something strange and important enough for everyone (the three of you that may actually read my blog) ...
you may be aware of this but dst doesn't affect kerberos at all since kerberos only uses utc. there is still potential for problems, however. if a user moves their clock forward (or backward) instead of letting the dst rules adjust it, then they'll run into kerberos failures in the form of krb_err_time_skew. anything beyond a 5 minute skew is determined to be a replay attack... and subsequently not honored. so with that in mind, you think... domain-joined resources will reset their times to the domain time. unfortunately, this only occurs in 8 hour intervals.
of course, if the user just manages to change their time zone, this will not cause the same effect. they'll be fine. the time zone is a local offset which does not affect the utc value like utilizing the date/time applet to change the time forward/backward.
hope this helps!
UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress. if you are using the v2 toolkit, PLEASE read this blog post before proceeding. here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can
Comments
Post a Comment