The below script which I modified from Philippe’s comment here should cover both internal, cloud and B2B invited users. The original script was using -objectid rather than -searchstring which works better and is more accurate for the internal and cloud accounts, but doesn’t work at all for B2B accounts.
The AppID can be obtained from this command:
Get-AzureADApplication -SearchString “Display Name for App”
Put the corresponding AppID into the below script, and you’re good to go. You’ll get prompted for Azure AD credentials as per usual. You can also get this
This is designed for a single user addition, but you could easily import the email addresses from a CSV file, and do a ‘for each’ on each entry like I did here.
# The UserPrincipalName or ObjectId of the user$userId = "email@example.com"# The AppId (a.k.a. "client ID") of the app to assign the user to$appId = "AppIDGoesHere"# Connect to Azure ADConnect-AzureAD -Confirm# Get the user to be added$user = Get-AzureADUser -searchstring $userId# Get the service principal for the app you would like to assign the user to $servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"# Create the app role assignmentnew-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId -PrincipalId $user.ObjectId -ResourceId $servicePrincipal.ObjectId -Id ([Guid]::Empty)
Note: If you try this and get the error below, it’s because the app is already assigned.
new-AzureADUserAppRoleAssignment : Error occurred while executing NewUserAppRoleAssignment StatusCode: BadRequest ErrorCode: Request_BadRequest Message: One or more properties are invalid. At Z:\script.ps1:17 char:1 + new-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId ` + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [New-AzureADUserAppRoleAssignment], ApiException + FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewUser AppRoleAssignment
I keep forgetting some of the main URLs I need for Microsoft’s online cloud based services. Instead of going direct to where I want, I log into one point I know and follow the bouncing ball to get to my destination – hardly efficient.
Instead, here’s my list of important Azure and Office 365 URLs to get where you want. The ones that require your domain as part of the URL aren’t hotlinks.
Azure AD B2B has been a lifesaver for me, in giving external clients access to SharePoint Online portals.
There’s a great TechNet article on how it works and how to do it, as well as a great Channel 9 video demoing how it works if you want to dive deeper, but here’s an overview:
Azure AD B2B lets you invite external people via their email address, to use your Azure resources. For me, that’s SharePoint Online, but you can grant access to other Azure resources too.
The process is really simple – you need to fill out a very basic CSV file with each person’s email address and full name, along with a few basic details such as the site you want them to be redirected to, and an ID of the resource you’re granting access to.
The people you’re inviting don’t need their own Azure AD instance which is the best part – if they do, then they just get invited to your instance with the set permissions… but if they don’t, on the fly a pseudo-Azure AD gets set up by Microsoft for the domain their email address is on, and again they’ll get invited to your instance.
This method eliminates the need to do extensive account management, all you have to worry about is inviting them and giving them the permissions they need (which I do via group membership). Password resets they can do themselves, and get a code sent to their email address to use as part of the reset process.
On top of this, there’s no licensing required, which means if you are already covered for SharePoint Online through your Office 365 sub, this is a very cheap way to make customer facing portals to share information with, that’s locked down and hosted in the HA environment of Office 365.
I was surprised at how simple it was to invite, and even from the end user’s perspective of receiving the invitation – the process is very easy.
At the time of writing, Azure AD B2B is in public preview and may have a few bugs.
I ran into a problem where a user couldn’t sign into Intune, which uses Azure Active Directory to authenticate users.
After checking the user in question on the Azure Active Directory portal, I noticed the domain was wrong:
The user was being synced from On Premise Active Directory, so I had a look via Users and Computers to see what was going on. The user’s User Principal Name domain field was set differently to other users – instead of the proper mydomain.com, it was set to mydomain.local – another valid internal domain to Active Directory, but not one that Azure Active Directory knew about:
The unknown domain caused Azure Active Directory to disregard it, and instead use it’s default tennancy domain of wrong.onmicrosoft.com. I thought just changing the dropdown menu to mydomain.com instead of mydomain.local would fix it, but a forced Azure Active Directory Sync sync reported the change was successfully synced, but didn’t actually change the value.
I’m going to guess this is by design, as you don’t usually want logins changing. There is an easy way to change the via PowerShell instead.