Before Contoso users can access Azure Files, they must first authenticate, as anonymous access is not supported.
As the lead systems engineer, you need to know the authentication methods supported by Azure Files, described in the following table:

Authentication Method	Description
Identity-based authentication via SMB	Preferred for accessing Azure Files, it provides a seamless Single Sign-On (SSO) experience similar to local file shares. It supports Kerberos authentication using identities from Microsoft Entra ID (formerly Azure AD) or AD DS.
Access key	An older and less flexible option. An Azure Storage account has two access keys that can be used to make requests, including to Azure Files. Access keys are static and provide full control over Azure Files. They must be secured and not shared with users, as they bypass all access control restrictions. It is recommended not to share keys and to use identity-based authentication whenever possible.
SAS token (Shared Access Signature)	SAS is a dynamically generated URI based on the storage access key. It provides restricted access rights to an Azure Storage account. Restrictions include permissions, start and expiry dates, allowed IP addresses, and allowed protocols. With Azure Files, a SAS token is used only for access via the REST API from code.

Use identity-based authentication

You can enable identity-based authentication on Azure Storage accounts.
The first step is to configure the Active Directory (AD) source for the storage account.
For Windows, you can choose from the following three AD sources:

• On-premises AD DS
• Microsoft Entra Domain Services (formerly Azure Active Directory Domain Services)
• Microsoft Entra Kerberos (only for hybrid identities)

To use AD DS or Microsoft Entra Kerberos, you must ensure that on-premises AD DS is synchronized with Microsoft Entra ID via Microsoft Entra Connect or Microsoft Entra Connect cloud sync.

Once identity-based authentication is enabled for a storage account, users can access files on the Azure file share with their login credentials.
When a user attempts to access data in Azure Files, the request is sent to AD DS or Microsoft Entra ID based on the selected AD source.
If authentication succeeds, the AD source returns a Kerberos token.
The user then sends a request containing this token, and the Azure file share uses this token to authorize the request.

Configure Azure file share permissions

If you have enabled identity-based authentication, you can use Azure role-based access control (RBAC) to manage access rights to Azure file shares.
The following table lists the built-in roles for Azure Files:

Azure RBAC Role	Description
Storage File Data SMB Share Contributor	Read, write, and delete access to Azure file shares via SMB.
Storage File Data SMB Share Elevated Contributor	Read, write, delete, and modify NTFS permissions via SMB. This role provides full control over the Azure file share.
Storage File Data SMB Share Reader	Read-only access to the Azure file share via SMB.
Storage File Data Privileged Reader	Full read access to all share data for all configured storage accounts, regardless of NTFS permissions set at the file/folder level.
Storage File Data Privileged Contributor	Read, write, modify ACLs, and delete access to all share data for all configured storage accounts, regardless of NTFS permissions set at the file/folder level.

If necessary, you can also create and use custom RBAC roles.
However, RBAC roles grant access only to the share.
To access files, the user must also have permissions at the folder and file level.

Azure file shares enforce standard Windows file permissions at the folder and file level.
You can mount the share and configure permissions via SMB, just like local file shares.

Data encryption

All data stored in an Azure Storage account (including Azure file shares) is always encrypted at rest using Storage Service Encryption (SSE).
Data is encrypted when written to Azure datacenters and automatically decrypted when accessed.

By default, encryption uses Microsoft-managed keys, but you can choose to use your own encryption key.

All Azure Storage accounts also have encryption in transit enabled by default, ensuring that all data is encrypted during transfer between the Azure datacenter and your device.

Unencrypted access via SMB 2.1, SMB 3.0 without encryption, or HTTP is not allowed by default, and clients cannot connect to Azure file shares without encryption.
This can be configured for an Azure Storage account and applies to all services in the storage account.

Create Azure file shares

Azure Files is deployed as part of an Azure Storage account.
The settings specified when creating the storage account (such as location, replication, and connectivity method) also apply to Azure Files.

Some storage account settings, such as performance and account type, may limit the options available for Azure Files.
For example, if you want to use premium file shares (which use SSDs), you must select premium performance and the FileStorage account type when creating the account.

Once the Azure Storage account is created, you can create an Azure file share via:

• The Azure portal
• Azure PowerShell
• Azure CLI
• REST API

You can also create an Azure Storage account via Windows Admin Center when deploying Azure File Sync.

To create a standard Azure SMB file share, follow these steps:
(If you create a premium file share, you must also specify the provisioned capacity.)

1. Sign in to the Azure portal and select the appropriate storage account
2. In the service menu, under Data Storage, select File shares
3. In the details pane, on the toolbar, select + File share
4. In the New file share pane, enter the desired name and select an access tier
5. Select Review + create, then click Create

Next unit: Configure connectivity to Azure Files