July 4, 2019
Lately, I have been doing some side projects for a friend’s small business (about 40 PCs across 3 locations). The goal was to get them switched over from an old Windows 2008 R2 domain to a domain-less Azure AD environment running on Windows 10 and utilizing Microsoft 365 Business. Every now and then I am faced with a challenge on how to do something that is so easy to do in a domain environment, like create a network share and grant users access. My Internet searches came up empty, so I put on my thinking cap and started testing different options.
Now before someone starts leaving angry comments below saying just use OneDrive for Business, yes – I am all in favor of this approach. However, there still is the need to have certain file shares, even if to pull files off from a network location so they can be then stored in a user’s OneDrive. The issue I was dealing with was recovering a large amount of data and it made sense to put it on a network share for end users to pull.
Most of you are probably familiar with the method of creating a share in Explorer. So let’s give this a shot – in this example I am trying to create a share called MyShare and configure it so that my AAD credentials have access to it. Under Advanced Sharing, I am going to create a share just using the same name of the folder – MyShare:
Clicking on Permissions, I am then going to try and my AAD credentials and this is where the problems begin. Attempting to add a new user (the default is Everyone), I can see that the object type is already configured for User, Groups, or Built-in security principals – Great!
Clicking on Locations is where we start to see an issue – the only choice is the local machine:
Alright, well maybe the system is smart enough to know that it is AAD joined and we can just enter the AAD credentials. Let’s start with the email, after all, this is what we use to sign on to the system. Nope, it has no idea about my AAD credentials:
Maybe if we put AzureAD in front of the email account. Nope, it does not understand that either:
Let’s see if we can do this with PowerShell instead. Go ahead and create the share with the default permissions (we will adjust those later) and open an elevated PowerShell. Start off by running the following command to verify that the share you just created exists:
Now, let’s try adding my account with the AzureAD prefix first using the following command:
Grant-SmbShareAccess -Name MyShare -AccountName “AzureAD\email@example.com” -AccessRight Full
We see that it was able to add it successfully. Now let’s look at the share permissions back in Explorer:
And just like the PowerShell command result showed, it added my Azure AD account to the share permissions with full control (feel free to remove Everyone from either PowerShell or the UI).
Now I can access the share from another AAD joined machine that I am signed on to with my AAD credentials.
Originally posted on https://miketerrill.net/
7 thoughts on “How to create a network share in an AAD only environment”
Pingback: How to add AAD users to the Remote Desktop Users Group | Mike's Tech Blog
I wish MS would integrate AAD directly into Win10 so you could select it from the Location field. So one would be able to select local machine, local domain or AAD domain, as the case may be… That would be the ultimate in hybrid functionality :-).
Pingback: Azure AD参加したデバイスでのAzure ADユーザーサインインについて | Always on the clock
I’ve been searching for a few days how to share a folder on my computer with any of my organization’s AzureAD members(coming from Office 365 subscription) and I found your great post! That is exactly what I wanted to. Thank you!
Thanks for this article! On Windows-11, this looked like it was going to work (the steps above worked as described), but I still get prompted from a different AAD computer for credentials, and my credentials don’t work when I enter them in that prompt (AzureAD\firstname.lastname@example.org, with correct password). Could this be something different with Windows-11? Also (ironically), the folder that I am trying to share locally is actually a OneDrive for Business folder, so maybe that is the problem here? Thanks again!
Absolutely brilliant! It’s difficult to understand why Microsoft doesn’t think that customers would want to be able to do this with the GUI. I should have known that PowerShell was the secret! Unfortunately, I’m PowerShell inept…so I rely on good folks like yourself to help in cases like this. Keep up the great work!
This worked for one of my clients but not another? Its baffling that Microsoft doesn’t have a better system for dealing with network shares and AzureAD