If you have ever explored the differences between Active Directory (AD DS) and Azure Active Directory (Azure AD), you would have found that Azure Active Directory doesn't support the Kerberos authentication protocol, but Active Directory does.
Kerberos is used to authenticate your account with an Active Directory domain controller, so the SMB protocol is then happy for you to access file shares on Windows Server. This is just one example - many, many applications including ones your organization may have written some time ago, rely on Kerberos authentication.
For a deep dive of how the local Windows logon process works, including when and how Kerberos kicks in, visit Deep dive: logging on to Windows.
To host a Windows Server in Azure that needs to use Kerberos, or for older applications, you would create an Azure Active Directory Domain Services (Azure AD DS) managed domain. This directory synchronises accounts from Azure AD, which in turn can be synchronising accounts from your on-premises Active Directory domain. Then, you can domain-join your Azure virtual machines and apply your group policies, without needing to deploy Active Directory domain controllers into Azure. Now, there are a few limitations with Azure AD DS, but this is the standard way to get Kerberos support in Azure. 
You only really want to be doing this if you have no other option to modernise your applications, or to buy you the time to do so. In his article "Why we built Azure AD Kerberos", Steve Syfuhs mentions that Kerberos as used by Active Directory, relies on passwords and doesn't support capabilities like FIDO, multi-factor authentication or conditional access. There are some solutions to help with some of those capabilities on-premises, but they are complicated, compared to ticking a check box in Azure AD.
Let's look at a specific use case - Profile containers using FSLogix for Azure Virtual Desktop
In a virtualized desktop or remote desktop world, we're using a service where more than one person can log onto a server and get their own, temporary remote session - you can configure the default desktop settings and icons, they can run applications just like they are running them on a PC, and this is really helpful for centralising access to non-browser line-of-business apps that you don't want to install and run locally on every single computer. Microsoft has been providing virtualization like this since Remote Desktop Services was released in Windows NT 4.0 Terminal Server Edition in 1996.
With a user login to a Windows desktop comes the concept of a user profile - the configuration of the environment for that user, which can include things like desktop background colour, screen saver, autocomplete entries etc. On a local computer, that user profile is stored on the local disk. If you've set up "roaming profiles", you can store those settings on the server instead, mapped to a network drive file share (usually called the user's "home" drive), so those settings follow them no matter which domain-joined computer in your organisation they log on to.
FSLogix is specifically designed for holding user profiles for non-persistent virtual environments (virtual desktops) in a network share location, while hiding the fact that the profile is on a network share. This is important to some applications that need the user profile to be stored locally.
So if the virtual desktop environment is Azure Virtual Desktop and we want to put the user profiles in a file share, we could use something like Azure Files, right? Azure Files supports the SMB file sharing protocol, and if we wanted to connect to Azure Files from a Windows PC we could - because with a little configuration, Azure Files can decrypt the ticket that our Windows client got when it authenticated with Active Directory, and happily let us in.
Except our Azure Virtual Desktop hasn't authenticated you with Active Directory unless you've domain-joined or Azure AD domain-joined it and it has "line of sight" access to your Active Directory domain controllers via a VPN, or it can talk to Active Directory Domain Controllers you're running as virtual machines in Azure. Ugh, that's a bunch of extra infrastructure dependencies and management you're trying to move away from. To solve this, the Identity team took a look at the Ticket Granting Tickets used for hybrid authentication with FIDO.
The authentication process
Depending on your level of authentication knowledge, now would be a great time to go back to these two articles for reference:
Deep dive: Logging on to Windows
Deep dive: Windows hybrid join single-sign on to Active Directory
But to catch you up, this diagram below shows the Windows Local Security Authority announcing it has some credentials, to find out which authentication packages know about Azure AD, and the Cloud Authentication Provide package (CloudAP) answering - using it's AAD plugin to go talk to Azure AD using the OAuth protocol.
When the user credentials are validated, an Oauth Primary Refresh Token (PRT) is issued. This PRT is issued to a specific user on a specific device and it contains a Device ID and a Session Key.
Ticket Granting Tickets and realms
Kerberos doesn't use PRTs though, it uses TGTs (Ticket Granting Tickets - in particular the krbtgt).
Microsoft added a special cloud-minted Kerberos TGT to the authentication process for FIDO security keys - But it still references your on-premises servers and is intended to be exchanged for a full on-prem TGT, so it doesn't have all the components we need. So the team invented a Cloud TGT!
The Azure AD Kerberos authentication process
Windows authenticates with Azure AD and gets: a PRT AND a Cloud TGT (plus a Partial TGT if they logged on with a FIDO key).
Challenge is, you're only supposed to have one primary TGT, to one realm (your on-prem AD). So during this process, we also tell the client to map to a different realm for cloud resources and we capture the Azure AD tenant details.
*.windows.net = KERBEROS.MICROSOFTONLINE.COM
Now, when you log into Azure Virtual Desktop, authenticate and get your PRT and Cloud TGT, Azure Virtual Desktop is going to call up FSLogix to load your user profile from the Azure Files share (e.g. \\mystuff.file.core.windows.net). And yes, that looks like an SMB file share, because it is, so SMB goes looking for a Kerberos ticket for cifs/mystuff.file.core.windows.net.
Because we gave Windows that mapping during the Azure AD authentication process, it knows not to contact an Active Directory domain controller for *.windows.net resources. Instead, the Kerberos stack places the Cloud TGT in the cache as well as the realm mapping, and adds a "KDC Proxy" map between the realm mapping and the Azure AD tenant details.
This means that for our ticket request, Kerberos sees cifs/mystuff.file.core.windows.net, *.windows.net maps to KERBEROS.MICROSOFTONLINE.COM and there's a KDC Proxy mapping of that realm to https://login.microsoftonline.com/tenantid/kerberos
The KDC Proxy protocol is how we transfer Kerberos over the internet.
And Azure AD gets our Ticket Granting Service-Request (TGS-REQ).
Azure AD then:
Verifies that our Cloud TGT matches the Azure AD tenant id we're looking up;
Queries that the user exists;
Looks up the requested Service Principal Name (of the Azure Files resource we’ve previously registered as an Application in Azure AD),
generates a ticket;
Encrypts the ticket to the Azure Files storage keys which are stored in its service principal name;
And bundles it all up in a TGS-REP and returns it.
When the Kerberos stack gets back the Ticket Granting Service Reply (TGS-REP) it:
Strips out the ticket;
Generates an Application Request (AP-REQ) and hands it to SMB;
Then the SMB protocol stuffs the AP-REQ into a header and sends the SMB hello to Azure Files.
Azure Files receives the hello, decrypts the ticket (using its storage keys) and you're good to go! FSLogix can now read the user profile in the Azure File Share and load your Azure Virtual Desktop session.
SMB, Azure Files and AVD have no idea that the Kerberos ticket never actually saw Active Directory.
Note: The current public preview of this service does require that your uses exist in an on-premises Active Directory and have been synced to Azure AD using Azure AD connect. Cloud-only uses created solely in Azure AD are not supported ... yet, but soon.
How to implement Azure Files for FSLogix and Azure Virtual Desktop
If you want a step-by-step on how to configure Azure Files etc to get this all working, check out Dean Cefola's video:
You can follow Create a profile container with Azure Files and Azure Active Directory (preview) for the PowerShell commands you'll need.
Many thanks to Steve Syfuhs for the opportunity to expand on his great technical explanation and add some pictures!