Azure Active Directory has the ability to create Security Groups with Dynamic membership. This is great if you can apply logic to a group, as members will fall in and out of scope without any work required.
Microsoft have a great writeup on how it all works and how to create rules, however I’ve run into a scenario not covered in the documentation.
Wanting to have all users to have the country ‘Australia’ in Active Directory, I thought it would be a simple PowerShell command. Get all the users you want and set a field to ‘Australia’. However, it’s more complicated than that.
As you can see from the above, the Country/region field is a dropdown, where you can select the country. If you look in PowerShell using ‘get-aduser username -properties *’, there’s 4 fields that get populated with this setting:
c : AU
co : Australia
Country : AU
Trying to just change one of these fields will result in an error such as:
Set-ADUser : A positional parameter cannot be found that accepts argument ‘Au’. Set-ADUser : A positional parameter cannot be found that accepts argument ‘Australia’. Set-ADUser : A value for the attribute was not in the acceptable range of values
The answer is that all fields need to be set at the same time. The C and Country fields are based on ISO 3166 codes, with Australia being AU and 36.
I’ve written before on how to update Active Directory from a CSV. This time, I’ve got a CSV list of users that I want to check are valid users against my Active Directory (AD) environment.
There’s a huge amount of ways this can be done, and this is just one of them. If you have others, or ways to improve this I’m always keen to hear!
This script assumes you have a CSV file with the header (first line) with the word ‘users’. Here’s an example CSV file: myusers.csv
Below is the PowerShell script I wrote. I’ve also written about ‘If’ and ‘Else’ before, so read that if you want some clarification. The user list I have is based on User Principal Name (UPN) rather than just username, so I’m searching AD to see if there’s a match or not.
What I’m doing here is setting each line of the CSV as the $UPN variable to search for. Then using the ‘Try‘ function, I’m catching if there is no result/match (null). If there’s a match, it won’t equal null, so display nothing. Else, show the UPN via the $UPN variable and follow that with ‘Doesn’t Exit’.
This way, I will only get results back from each AD search where the UPN in the CSV doesn’t match a user’s UPN in my AD environment – and I get to see what those results are.
This script method can be applied in many different ways of course, but it was the first time I’d used the Try function, and it worked really well.
The ability to allocate Office 365 licenses via groups is now available for everyone to use. This has been a long-awaited feature, up until now licenses have either been applied manually via the portal, or via scripts/3rd party software with logic applied for automation.
Now, you can automatically apply and manage license allocation using whatever logic you like. You can create on-premise AD groups, apply a license set to the groups, and members will be allocated the relevant licensing. If that doesn’t work for you, there’s also cloud based Dynamic Groups which let you use whatever logic you can come up with to add members to the group. You could do it on something like a department name, or use an extension attribute and populate that based on what license you want to allocate.
This removes licenses from all your users, to be more specific add extra criteria to the first ‘Get-MsolUser’ command. Also note you need to swap ‘litwareinc’ with your tenant ID, and ENTERPRISEPACK with whichever license you’re removing. I’d recommend testing on one account first!
To see what your tenant’s license options are just use:
And you’ll see a list of the license options along with existing allocations.
Along with my Azure AD B2B journey (still in preview at time of writing), the option of pushing out something like a SharePoint Online site as an app is one of the jigsaw pieces required to make the whole B2B process work – as a version of the apps page is displayed as the default link to anyone who accepts an Azure AD B2B invite and logs in for the first time.
MyApps – an externally invited user will only see the apps they have access to (by default, none)
I’m trying to gloss over details here, as there’s a lot of steps with different parts of the Microsoft world to get a process automated end to end for inviting external users to a SharePoint Online site – but the last step of assigning a user or group to an application has no documentation I could find, that showed how to achieve this via PowerShell.
All I want to do here, is create an Application in Azure AD, then assign a group to it. Members of the group will then see the application on MyApps.
You can check that this has applied by the Azure Active Directory portal too, by going to your Active Directory section, choosing ‘Applications’ and finding your app, then go into ‘users and groups’ and find the group. You should see a ‘yes’ in the assigned field.
If there’s any interest in documenting the entire SharePoint Online and Azure AD B2B invite process and script, let me know. It’s a great way of sharing data with clients via a portal.
Update 15th June 2017
Microsoft made a change with the IdentifierURI field, which is also called AppID if you view it in the Azure portal. Previously, it could be any unique URL, it just has to be unique amongst your apps (as to why it has to be a URL at all, I couldn’t get an answer on). Now, it can be anything as long as it’s not sharepoint.com or dynamics.com as they’ve reserved those for other reasons. My example above, and what I’d been using in production was variants of sharepoint.com – as the unique URI might as well be the actual URL of the site. If you use a URL that’s not allowed anymore, you’ll get the error:
New-AzureRMADApplication : Operation returned an invalid status code ‘BadRequest’