We seem to be having issues with timestamps in the EE DB, I think (?). Occasionally wehave users whose Windows pw change doesn't sync with their EE pw when changed at client. And yes, we've checked all the policies, settings, communications, etc... In fact the local client log shows the change being sent up to the server, it just never takes. We solve it by creating a new pw-only token and they are back on their way with SSO functioning as expected. I have no way to view that token timestamp (that I know of) so I don't know for sure if this is the case.
But today we found a machine object that stopped checking in with the EE server. The audit log shows it was syncing as expected until two days ago. Then the last sync timestamp in the audit trail shows a date of 1/27/2010 (future dated by exactly one mionth). That was the last audit entry though the machine was online and well-connected for the past two days. I forced a sync this morning, it worked, and the audit log shows the correct date for the sync. Now the machine is back to checking-in on schedule. The client and server both have their clocks set correctly, haven't been changed, and both use the same trusted internal NTP server as time source. They're even in the same timezone.
We're running 5.2.2 all around. Doing audit trail maintenance nightly, keeping pretty lean. This one was found quite by accident--I can use SbAdmCl to monitor for these errors. Mostly becoming concerned I have a larger problem. Any suggestions for things to check? The SSO issue I describe is generating helpdesk calls. Not a lot, but enough that it's quite annoying.
Could this happen if user was checking calendar and saved wrong computer time (month) by mistake?
How often do you EE sync?
I have seen a lot of weird sync timestamps; occuring both: far in the past and in the distant future.
I blame local computer time for those anomalies.on 12/29/09 6:06:45 PM EST
most token timestamp issues are caused by someone using EEM with the wrong time, and thus setting a timestamp in the future directly in the user policy. This can be mitigated by using the connection option to set the eem time with the server, but of course if the user has the wrong locale settings, or turns that off, they can create a "sticky" token which won't get overwritten by user changes for a long time until the real time catches up. Recreating the token will solve this, resetting it won't.
I finally tracked down this user with the future timestamp. I'm going to say it's highly improbable that she changed her own calendar--when I showed her what I was asking it was all news that it could even be done. Nonetheless, it's possible. It hasn't recurred since then so I'll chalk it up to EE gremlins and let it go. Most of our user SSO password sync issues I'm going to chalk up to the issue described in KB66015. Since that is "working as expected" we'll have to live with it. Hopefully 6.1 improves on all this.
>>Most of our user SSO password sync issues I'm going to chalk up to the issue described in KB66015.
>>Since that is "working as expected" we'll have to live with it. Hopefully 6.1 improves on all this.
this sucks, doesn't it also defeat the repeated password settings?
I suppose it could bypass the control. Unlikely intentionally but theoretically possible. Here's a scenario where it really sucked:. When we rolled out the client we started out with Autoboot enabled. 80% through the rollout an admin accidentally changed the $autoboot$ password (I know, I know, don't get me started on that one...) Anyhow, a couple hours later when the first calls started coming in the admin realized his mistake, tinkled in his shorts, and quickly changed the password back. Unfortunately, the damage was done. The bad password synced out ot scores of machines before it was caught. Even though the password was changed back on the server it was repeatedly set back to the incorrect password for the reason described earlier in this thread. For the rest of the rollout we had to run a script every 10 minutes to set the password back to the correct one so that users still on autoboot didn't see the pre-boot login screen. Fortunately we've completed the rollout and everyone is now intentionally seeing the pre-boot login. Ugh.
Oh, to answer your question, we're synching hourly. I'd like to change this but our laptop users are so infrequently connected to the internal network we miss too many syncs when we lengthen this period. We're looking at putting an EE server in our DMZ to overcome this then maybe we can change it.