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\mike.terrill@domain.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/