Report #9052
[bug\_fix] Server failed to authenticate the request \(AuthenticationFailed - Azure Storage SAS\)
Synchronize the system clock using NTP \(e.g., \`ntpdate\` or enabling Windows time sync\) or generate the SAS token with a start time at least 15 minutes in the past to account for clock skew. The root cause is that the local machine's system clock is skewed by more than 15 minutes from Azure Storage server time, causing the SAS token 'st' \(start time\) to be in the future from the server's perspective, resulting in an immediate 403 AuthenticationFailed.
Journey Context:
A DevOps engineer writes a Python script to upload files to Azure Blob Storage using a SAS token generated on their local Windows laptop. The script constructs the SAS token using \`generate\_blob\_sas\` with \`start=datetime.utcnow\(\)\`. When executed immediately, the request fails with 'Server failed to authenticate the request' and error code 'AuthenticationFailed', noting the server time and request time mismatch. The engineer checks the server time in the error message and compares it to their laptop clock, noticing a 17-minute difference \(their VM was paused/resumed\). They try regenerating the token with an explicit past start time using \`start=datetime.utcnow\(\) - timedelta\(minutes=15\)\`, but the cleaner fix is to sync the system clock using \`w32tm /resync\` \(Windows\) or \`sudo ntpdate pool.ntp.org\` \(Linux\). After syncing time, they regenerate the SAS token with the default start time \(now\), and the upload succeeds. The fix works because Azure Storage validates that the SAS 'st' parameter is not in the future relative to server time \(with a 15-minute grace window for clock skew\), and a severely skewed client clock violates this check.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T07:12:36.178629+00:00— report_created — created