Identity and Access Control
In this unit, you learn about how to authenticate users and provide access to Azure file shares. Azure Files supports identity-based authentication for customers accessing file shares over SMB. In addition, SMB users can also authenticate using a storage account key. NFS file shares rely on network-level authentication and are therefore only accessible via restricted networks. Using an NFS file share always requires some level of networking configuration. File share access over REST APIs uses shared access signatures and storage account keys for specific data management operations.
Identity-based authentication: Customers can use identity-based access via the Kerberos authentication protocol. Active Directory services store user account information such as usernames, passwords, contact information and so on. Azure Files integrates with common directory services to verify the user account details and enable successful authentication. For SMB, identity-based authentication is the most secure and recommended option.
Storage account key: A user with the storage account key can access Azure file shares with superuser permissions over SMB and REST. Ideally, only super user administrators should use storage account keys because they bypass all access restrictions. For file shares used by enterprise customers, storage account keys aren't scalable or safe mechanisms for organization-wide access and are therefore not recommended. The recommended security best practice is to avoid sharing storage account keys and use identity-based authentication.
Shared access signature: Customers accessing over REST can use a shared access signature (SAS) to authenticate with Azure Files. Shared access signatures are used in specific scenarios where independent software vendors develop REST API applications and use Azure Files as a storage solution. They're also used when internal partners need access over REST for data management operations. A shared access signature is a URI that grants restricted access rights to Azure Storage resources. You can use a shared access signature to give clients access to certain storage account resources without having to give them access to your storage account key.
Identity-based authentication
Azure Files supports identity-based authentication for SMB file shares using the Kerberos protocol. When an identity associated with a user or application running on a client attempts to access data in Azure file shares, the request is sent to the domain service to authenticate the identity. If authentication is successful, it returns a Kerberos token. The client sends a request that includes the Kerberos token, and Azure file shares use that token to authorize the request. Azure file shares only receive the Kerberos token, not access credentials.
Azure Files supports the following authentication methods for SMB file shares:
On-premises Active Directory Domain Services (AD DS): Enabling AD DS authentication for an Azure file share allows users to authenticate using their on-premises AD DS credentials. The on-premises AD DS must be synchronized to Microsoft Entra ID using Microsoft Entra Connect sync. Only hybrid users that exist in both on-premises AD DS and Microsoft Entra ID can be authenticated and authorized for Azure file share access. The customer needs to set up their domain controllers and domain join their machines or virtual machines (VMs). The domain controllers can be hosted on premises or on VMs, but the clients need to have a line of sight to the domain controllers, either on an on-premises network or on the same virtual network.
Microsoft Entra Domain Services: For Microsoft Entra Domain Services authentication, customers should enable Domain Services and then domain join the VMs they want to access file data from. The domain joined VMs must reside in the same virtual network as Domain Services. However, customers don't need to create the identity in Domain Services to represent the storage account. The enablement process creates the identity in the background. In addition, all users that exist in Microsoft Entra ID can be authenticated and authorized. The user can be cloud only or hybrid. The platform manages the sync from Microsoft Entra ID to Domain Services without requiring any user configuration.
Microsoft Entra Kerberos for hybrid user identities: Azure Files supports Microsoft Entra Kerberos (formerly Azure AD Kerberos) authentication for hybrid user identities, which are on-premises AD identities that are synced to the cloud. This configuration uses Microsoft Entra ID to issue Kerberos tickets to access the file share over SMB. This means end users can access Azure file shares over the internet without requiring a line of sight to domain controllers from Microsoft Entra hybrid joined and Microsoft Entra joined VMs. In addition, with this capability, Azure Virtual Desktop customers can create an Azure file share to store user profile containers that hybrid user identities can access.
AD authentication for Linux clients: Authentication for Linux clients is supported via AD DS or Microsoft Entra Domain Services.
Common use cases for identity-based authentication
The following are some common scenarios for using identity-based authentication:
Migrating from on-premises file servers to Azure Files: Replacing on-premises file servers is a common IT transformation use case for many customers. Using on-premises AD DS to enable a seamless migration to Azure files not only provides a good user experience, but also allows users to access the file share and data using their current credentials by domain joining their machines.
Moving enterprise applications to the cloud: As customers move their on-premises native applications to the cloud, identity-based authentication with Azure Files eliminates the need to change your authentication mechanisms to support cloud applications.
Backup and disaster recovery: Azure Files can act as the backup storage system for on-premises file servers. Configuring proper authentication helps enforce access controls during disaster recovery scenarios.