Accessing Data on Azure Storage Account using SFTP

The Secure File Transfer Protocol or SFTP has been one of the most secure and reliable ways to exchange files between two systems for as long as I can remember. Especially for system-to-system communications that require authentication using keys.

Storage accounts on the other hand are a more modern way to handle data, providing blob service along with the traditional SMB and NFS file shares. SMB and NFS are not suitable for communications over the public internet leaving us with blob as the only option - apart from deploying a Linux machine.  

Fortunately, Microsoft decided to add SFTP support to the blob service of the storage account. To enable the SFTP support for your storage account, you have to enable the hierarchical namespace feature and of course, the SFTP support, as shown in the below screenshot:

To confirm that the functionality has been enabled for your storage account, you may check the Settings of the storage account where a new blade named SFTP should be available:

SFTP access is only available for the blob service of the storage account. You can access containers and blobs, but not files in shares.

Using Storage Explorer I've created two containers named home and data respectively. I've also created a directory within home named user1 that will serve as the home directory of our first SFTP user.

The only way to authenticate against the storage account - at least up until now - is to use local users. These are accounts that are configured on the storage account, much like local users on a Linux machine. The ability to authenticate using Azure AD is being considered but not yet available.

To create a local user, navigate to the SFTP blade and click on the Add local user button:

In the new window, you have to specify the username and the authentication method. There are two options available, password and key. We'll go with the password option to keep things simple:

When you click next, you'll be presented with a screen to select the permissions to assign to the user on the containers that are currently available on the storage account:

Here I've decided to grant permission on both containers (data & home). On data I've assigned only the read permission, compared to home where I've granted all permissions.

You can optionally assign a home directory to the user in the format {container}/{directory}. I've created the user1 directory in the home container earlier for that particular reason!

The next screen is very important since it contains the password of the account that has been created and there is no other way to recover it:

Use the copy button to copy the password to a secure location! The user has now been created and we're ready to connect.

In the SFTP blade, we can now see the new user and the connection string we can use in order to connect to the storage account:

The first part of the connection string is the username and the second is the name of the server to connect to. Although not shown here, the name of the server is actually the blob endpoint of the storage account.

play

There is however another important thing I would like to mention. In the above example, we've set the user's home directory inside the home container. When the connection is established, the storage account will direct the connection to the appropriate container. If the home folder is not specified or we would like to connect to another container, we have to specify it in the connection string and the username part in particular. In our case it would be cpolydorousftp.data.user1@cpolydorousftp.blob.core.windows.net following the format  {myaccount}.{mycontainer}.{myusername}@{myaccount}.blob.core.windows.net, just like below:

At the time of the writing of this post, the SFTP support is still in preview. The GA version of the functionality may differ.

You have now connected to the blob service using SFTP!

Popular posts from this blog

Domain Controller Machine Password Reset

Image
On my lab environment, I've configured two Active Directory sites since most enterprises have offices in more that one places. My lab however is not running 24/7 and the domain controllers in the second site are rarely turned on in order to save resources. This leads to issues with the Active Directory replication such as the "The target principal name is incorrect" error when I execute:  repadmin /syncall /AdeP. To remedy the issue, we have to reset the machine password of the domain controller that has been offline. First off, we are going to stop and disable the Kerberos Key Distribution Center (kdc) service on the problematic domain controller, in our case DC4. There may be some tickets in the cache so we should also clear them using klist purge Now it's time to change the machine password of the domain controller using the command netdom resetpwd /s:dc3 /ud:lab\administrator /pd:* Replace the "lab\administrator" with an account on your...
Keep reading

Managing Active Directory User Certificates using PowerShell

I first came across user certificates when I was working with email certificates a few years ago and I have to admit that I had trouble updating the certificates on the objects! Most organizations have a Microsoft Active Directory Certification Authority that issues the certificates used internally. When a certificate is issued to a user, the Microsoft Certificate Service saves the public key in Active Directory. The userCertificate attribute is a multi-valued attribute that contains the DER-encoded X509v3 certificates issued to the user. Although we rarely need to pay attention to this attribute, there are cases where we have to update it. To make things easier, I've written PowerShell functions to Get, Remove, Import and Export the certificates on that field. To get the list of certificates for an object, use the Get-ActiveDirectoryObjectCertificate function: PS C:\> Get-ActiveDirectoryObjectCertificate -UserPrincipalName cpolydorou@lab.local DistinguishedName  ...
Keep reading

Configuring a Certificate on Exchange Receive Connector

Today's article is about configuring Exchange receive connectors with specific certificates. Out of the box, Exchange uses self signed certificates to provide TLS secured mail flow. This will definitely be an issue if you expose the SMTP protocol to client computers since they won't trust the certificate. In this article we are going to configure a certificate that was issued by a third part authority to the Client Frontend receive connector. We'll start with getting the thumbprint of the certificate using the Get-ExchangeCertificate cmdlet: [PS] C:\> Get-ExchangeCertificate Thumbprint                               Subject ----------                               ------- 241B864DC82C664FECBA18B8D54987AAFB65B4C2 CN=*.lab.com, ... D4D210886B34E690191A1F008C78FDD0E7325DD4 CN=Exchange2013A 960171662EB26116...
Keep reading