Azure

Azure AD Connect – Password Sync Times

Posted on by Adam Fowler

Azure AD Connect is a Microsoft utility that will sync your Active Directory records to Azure AD/Office 365. An introduction to this is available here.

One of the benefits of Azure AD is being able to use it as your point of authentication for users over the internet, without having to poke holes in your on-premises firewall. I was considering this for a 3rd party solution – but I had a concern.

How Do Passwords Work in Azure?

Azure AD/Office 365 stores passwords for users created ‘On Cloud’ – i.e. the primary record for them exists in Azure AD/Office365. For the ‘On Cloud’ users, password resets are instant, because the same system that hosts the user, manages their password.

Azure AD/Office 365 does not store passwords for your on-premises users. Instead, it uses a password hash. To learn more about this, read Mircosoft’s article on Understanding Office 365 identity and Azure Active Directory. This only functions if you’ve actually enabled password sync, which is a tickbox configurable from the Azure AD Connect side of things.

This means an on-premises user still authenticates against Azure AD/Office 365, but details are synced using Azure AD Connect on a scheduled basis. Someone’s phone number changes? That’ll be pushed to the cloud on the next sync. By default, that sync is every 3 hours. Personally I prefer every hour, but this is going to be dependent on the size of your AD environment if that makes sense.

What about Password changes?

Password hashes are different though. They occur every few minutes – sometimes within seconds. Event logs on the server that hosts Azure AD Connect will show three different events occuring.

The first is the ‘Password Change Request’ Event ID 656. From this you’ll see which user it is, as well as when the password change was actually made according to AD.

Second is the batch count, Event ID 651. This shows that it’s finished collecting details of password changes.

Finally, the Password Change Result record, Event ID 657. This should show the user affected again, and the result of the password change (which is hopefully Success):

adsync1

I was hoping passwords would almost be instant (within a few seconds) and my original testing showed that, but after more testing I found mixed results. More often it would take a minute or two.

Real World Impact

This means that if you have any application that authenticates against Azure AD, there is a chance of up to a roughly 3 minute delay before Azure AD knows of the new password, and won’t create a great experience for end users depending what applications they use, even first party.

Consider if you had Sharepoint Online for something staff accessed, and someone logs onto their domain connected PC. Their password has expired, so they change it and continue logging in. First thing they do is try and get to the SharePoint Online website, and get prompted for credentials. They try their new password, and it doesn’t work! So they try their old password… but in between these two attempts, their password in Azure AD has now updated. The old password doesn’t work either! From an end user perspective, that’s incredibly confusing.

Solution

The real solution to all of the above is to not use Azure AD Connect, and instead use ADFS. Instead of syncing passwords, password requests come from Azure AD back to your on-premises ADFS environment to authenticate a user. This will be immediately aware of a password change, and authenticate the user with the right credentials. You get the added benefit of pass-through authentication to Azure/Office 365 resources, which means users don’t need to keep authenticating to online resources (such as my SharePoint Online example above).

Any questions/comments/disputes on the above? Comment below!

Thanks to @Froosh for confirming my tests on this.

Adding Multiple Cloud Users to an Azure/Office 365 Security Group

Posted on by Adam Fowler

This one had me stumped for a while – how do you get a bunch of users in Office 365/Azure and then add them to a security group? This was met with the relevant tweets of frustration, such as:

After mucking around for a while, and getting Microsoft MVP David O’Brien to listen to my woes, I ended up working out a solution.

Part of my confusion was around this TechNet article for the command Add-MsolGroupMember which at the time of writing, I’m convinced is wrong. The example they give is to get a user and a group, then add the user to the group…. except, they’re used the get-msolgroup command to do so.

When I tried to switch this over to a user lookup with multiple user results, I received this error:

Add-MsolGroupMember : Cannot convert ‘System.Object[]’ to the type ‘System.Guid’ required by parameter
‘GroupObjectId’. Specified method is not supported.

Long story short, most Office 365 user/group commands I’ve come across don’t support multiple inputs, so you can’t feed a list of results through – it’s one at a time. Also, groups and users only seem to support using the Object ID of each object, so you can’t easily use names, email addresses etc. This means you’ll need to run commands to get those Object IDs based on the information you know.

To get around this, you’ll need to use the ‘foreach’ command – then it’ll go through each of your results one by one. I’ll go through this step by step:

1. Get your group:

$group = get-msolgroup | where {$_.Displayname -eq “All Office365 Users”}

Pretty self explanatory, we’re making the variable $group equal the object of the group name specified.

To check what users came back, you can just type $group

2. Get your users:

$users = get-msoluser | select userprincipalname,objectid | where {$_.userprincipalname -like “*domain.com*”}

Similar to the above, we’re making the variable $users all the users we want to add to the group, based on the User Principal Name containing “domain.com”. We’re also making sure we grab the object id of each of those users.

3. Adding the users to the group

$users | foreach {add-msolgroupmember -groupobjectid $group.objectid -groupmembertype “user” -GroupMemberObjectId $_.objectid}

This is showing the users we set earlier, then for each record, running the command ‘add-msolgroupmember’ based on the group we discovered in step 1, and the users from step2. Notice we call the Object ID for each of these objects, as the commands only support it as an identifier.

4. Check what users are in the group

get-msolgroupmember -groupobjectid $group.objectid

This will show you all the members of the group you’ve been working on.

With the above, you can use pretty much any search criteria for step 2, and add those users to your group.

Note that all the above is only for ‘In Cloud’ users, if they were on premesis and being synced to Azure AD/Office365, you’d run different commands against your on premise Active Directory environment.

Connect to all Office 365 services via PowerShell

Posted on by Adam Fowler

I found this great TechNet article and wanted to share:

Connect to all Office 365 services in a single Windows PowerShell window

It’s a greatly described article about how to connect to each Office 365 service – MSOL itself, Exchange Online, Skype For Business, SharePoint Online and the Compliance Center.

If you go through the article, you can set up a script to prompt you once for Office 365 administrator credentials, and connect to each service for a one stop shop on managing your Office 365 environment from PowerShell.

One catch (which is mentioned in the article) is that you’ll need to run PowerShell in Administrator mode, or you won’t be able to import modules. You’ll see an error like:

The specified module 'Microsoft.Online.SharePoint.Online.PowerShell' was not loaded because no valid module file was found in any directory.

If you aren’t sure if you’re in Administrator or User mode, the default path prompted in the PowerShell window will be “PS C:\users\username>” for User mode, and “PS C:\Windows\system32>” for Administrator mode (along with the word “Administrator” in the PowerShell window title.

I’m only new to Office 365, but I’ve found the GUI via the web for user management rather basic – I can’t do simple tasks such as search for users on a specific domain, then add them to a group. PowerShell is absolutely necessary if you want to manage Office 365.

Azure Live for Australia

Posted on by Adam Fowler

Today I logged onto Azure with my MSDN account, and considered setting up a Terraria server. That’s just the sort of fun I have on a Sunday afternoon.

To my surprise, I noticed that there were two new regions available on the virtual machine I was about to create: Australia East and Australia Southeast. If my primary school geography had taught me correctly, that would be Sydney for East, and Melbourne for Southeast.

I of course immediately tweeted about it to share the good news.

Creating a few VMs seemed to be a very quick process, particularly compared to creating VMs in other regions. I’m going to guess that this is because there aren’t too many people creating VMs right now, but come tomorrow it may have a bit of load – especially due to TechEd Australia starting in Sydney where I’m sure they’ll share the news.

Speed wise, it also seems much more responsive to RDP to – makes a lot of sense when the data doesn’t have to travel overseas and back – so I thought I’d ping one of the new VMs to see what sort of roundtrip difference there was.

It was at this stage I found out that you can’t ping an Azure VM from the public internet, which makes sense due to load balancers and other infrastructure smarts getting in the way. I could have set up a VPN, but this solution was much easier; using psping from Sysinternals. This works by using TCP and letting you specify which port. By default, Windows VMs are created with two ports forwarded: 3389 for RDP, and 5986 for PowerShell. I first tried this with port 3389 but didn’t get a response, but 5986 worked:

azureping1Adelaide to Sydney ping

Sub 40ms from my home Telstra Cable internet connection in Adelaide to Australia East (Sydney). Is it any better if my VM is hosted in Melbourne?

azureping3Adelaide to Melbourne ping

That… seems about the same. I would have expected Melbourne to have less latency, but it’s still quite decent.

For comparison, how does the region East US look in Azure?

azureping2Adelaide to East US ping

Huge difference. Above what I’d want clients to be connecting to a server at, as many applications can get a bit funny above 150ms or so. Still usable in many scenarios of course!

Azure going live in Australia will be the green light that many Microsoft based businesses have been waiting for to give the cloud a real chance, and I’m sure there will be interesting times ahead for those who start playing with Azure.

Quick Update:

David O’Brien was unable to see the Australian datacentre options, and came up with this explanation:

“only available for australian subscriptions. Every other region is available for everybody, not Australia.”  https://twitter.com/david_obrien/status/526339016245800961

So, if you can’t see the Australian options either you might have the same problem. Hopefully it will be available to all regions soon?