It’s Deja Vu All Over Again… Timing… Timing… Timing… Azure Storage Keys and Your Computer’s Clock

<

p class=”MsoNormal”>

The demo code for my upcoming book on Windows Azure storage inexplicably
began reporting that “The remote server returned an error: (403) Forbidden” on
every operation. Investigating the problem using the integrated Visual Studio
2012 Server Explorer to view objects in cloud storage was also problematic…
Visual Studio reported that the “current storage account key is invalid”, and
instructed me to create a new one. The new storage account key also failed, and
so did associating a new management X.509 certificate to the subscription.

Having remembered conversations that I shared with Jeffrey
Richter on clock skew and credentials in the cloud, I checked my notebook
computer’s clock and discovered that it was slow by several minutes. My
computer was set to synchronize with time.nist.gov, but when I attempted to
perform a manual update I received a connection error with the service. In an
attempt to rectify this secondary condition, I switched my notebook’s time
source to the time.windows.com time server and synchronized again. Viola!… with
my notebook’s clock time more closely aligned with the Windows Azure storage
service’s clock time… my credentials began working again.

This can be a tricky condition to diagnose because every
error message given by the client library’s interpretation of the 403 status
code points you towards something having to do with your storage account or its
storage keys rather than the real trouble, which is your computer’s clock. Here’s
what’s going on: the Windows Azure client library computes an Authorization
HTTP header by hashing elements of the request using your storage account key.
One of these headers (x-ms-date) is the UTC date and time of the request according
to the client computer’s clock. This header is included in every HTTP request
for a storage operation, and the value of this header is used by the Windows Azure
storage service to determine if the request is older than 15 minutes. When the
client’s clock is significantly retarded from coordinated time, the credentials
are deemed expired and Windows Azure storage service ignores the request and returns
a 403 status code. This security feature provides protection against replay
attacks.

 

Stay Informed

Sign up for the latest blogs, events, and insights.

We deliver solutions that accelerate the value of Azure.
Ready to experience the full power of Microsoft Azure?

Atmosera is thrilled to announce that we have been named GitHub AI Partner of the Year.

X