Password rotation time different than configured

Password rotation time different than configured

avatar

We use password rotation within the PAM module where we configure to reset the password for our privileged accounts on a daily base.
This is configured to reset every day at 05:00 a.m. but Devolutions is resetting this at 07:00 a.m.

Is this a known issue and can this be fixed?

All Comments (9)

avatar

Hello,

Thank you for reaching out!

My name is William and I'm here to assist you in any way I can.

Would it be possible to confirm if you have a time difference between the Devolutions Server and you machine or the domain controller? Also where are you seeing that the password reset is done at 7AM is this from the web interface of the Devolutions Server?

Best regards,

avatar

Hi William,

There is no time difference. I see this time in the web interface of Devolutions Server. As you can see here we configured this account to rotate at 04:00:



And in the logging you see this:



And in our audit tool of our Active Directory this is the time the password is changed:

db359ced-160b-413c-8a1a-e0909c1b402e.png

00664086-4a3f-4108-a359-14175f480b28.png

5b0af58e-2535-4d07-a419-8aec43b934fa.png

avatar

Hello,

Would it be possible to confirm if the time difference might be between your server and PC from which you are accessing the web interface of the Devolutions Server?

Also could you confirm the timezone configured on the Devolutions Server?

Best regards,

avatar

Everything is the same. All are synchronized with NTP. If there are time differences you can't login into your domain and have alot of issues.
Our timezone is UTC +1 (Amsterdam, Europe).

I guess you can reproduce this on your end setting this timezone?

avatar

Hello,

Thank you for your patience, our development team confirmed that they foot the root of the issue and are working on a fix. This will be included in the next release of Devolutions Server.

Best regards,

avatar

Hi William,

This is still not fixed. It seems this is related to summer/wintertime.

avatar

Hello,

Thank you for your feedback. Would it be possible to confirm this information:

  • The version of your Devolutions Server
  • The timezone configured under Administration > System Settings > General > Time-based usage
  • The timezone on the Windows server hosting the Devolutions Server


Best regards,

avatar

Hi William,

I think this information is important: when I reset the scheduler after summer/wintertime reset the scheduletime is correct again.
Is there a way to auto fix this without restarting the scheduler?

avatar

Hello,

Thank you for the additional details — that observation about the schedule correcting itself after a restart is very helpful.

At this point, we don’t have enough evidence to confirm the exact root cause or whether this behaviour is expected or a defect, especially around daylight saving time handling. The fact that restarting the scheduler temporarily resolves the issue suggests there may be a timing or caching inconsistency, but we need more data to validate this.

To move this forward, I’d like to gather a bit more information:

  • The exact version of your Devolutions Server
  • The timezone configured under Administration > System Settings > General > Time-based usage
  • The Windows timezone on the server hosting Devolutions Server
  • Confirmation of when the DST change occurred vs when the schedule started drifting
  • If possible, a short extract of logs around a rotation event before and after restarting the scheduler


Regarding your question: at the moment, there is no built-in mechanism to automatically resync the scheduler after a DST change without a restart.

Once we have the information above, we can determine whether this is a known limitation, a configuration issue, or something we need to escalate further.

Best regards,