Azure AD

Zero-click Single Sign-On Without ADFS

Login prompts to websites are a pain. Enterprise employees these days expect to have a single sign-on experience (meaning the same username/password everywhere) and a minimal amount of logging in to systems each day.

It’s a very different from years ago where every system had it’s own unique login, and users got into the habit of synchronizing password changes when the regular password expiries hit (and I’m sure some companies still run this way), but it’s a problem IT as a whole has worked on for many years.

Microsoft has had a big focus in identity management for many years, with products such as FIM/MIM and ADFS along with the old faithful Active Directory, controlling and giving framework for authentication. The on-premises approach didn’t work for cloud based technologies though. Going to a site such as will show an area to sign in:


Going back to the requirements of getting logged out of sites, or needing to log into each different Microsoft service is a pain and time sink for users. The original answer to this problem was ADFS. This works well, but requires the ADFS infrastructure to be set up, and needs to be highly available. If ADFS goes down, your users can no longer authenticate to Azure AD, which is what powers the identity management and authentication orchestration for Microsoft enterprise users (this includes Office 365).

More recently, another native solution was released – Pass Through Authentication for Azure AD Connect (Azure AD Connect being the service that syncs your on premises AD to Azure AD). This removes the requirement for entering a password to these Microsoft services which is great for users, but still requires the entry of the username (which in Azure AD, is the User Principal Name, and looks the same as an email address to confuse things more for users). It’s a good start, but still not the seamless authentication many users expect.

There is another way of providing zero-touch logins to Microsoft services without ADFS, which is Azure AD Domain Join. Windows 10 is a requirement here, but beyond that, the setup is quite easy if you’re already configured for Azure AD. Maurice Daly has written a great guide on this, which outlines all the requirements and steps to follow to be up and running. (Thanks Maurice for your help on this!)

Gotcha for myself: I found that I had an old version of the Microsoft Azure Active Directory Module for Windows PowerShell which didn’t have the get-msoldevice cmdlet at all, and had to download an updated version. I also updated the AzureRM module for good measure since it was also out of date, but shouldn’t have been a requirement.

This is a rather complex topic, so I’ve tried to give a fly-over view of the native options available. There’s also Smart Links which can speed up and improve the user experience.

If you’re on Azure AD and Windows 10, give Azure AD Domain Join a try. It may save you the hassle of building and maintaining an ADFS server, and give your users a better experience overall.

Azure Active Directory – Assigning Groups to Applications in PowerShell

Azure Active Directory Applications have been around for a while, but it’s I’ve found it hard to find good information on them beyond the biggest benefit of Marketplace Apps.

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.

Two different modules are required – Azure Active Directory V2 PowerShell module and Azure Resource Manager.

What we can do with these two modules is first create the application with the New-AzureRMADApplication command:

New-AzureRmADApplication -DisplayName "SharePoint Online Site A" -HomePage "" -IdentifierUris ""

Easy, now you have an application that will point to the URL entered in Azure Active Directory. Assigning a group to it is a bit trickier…

First, a few values need to be obtained:

$app = Get-AzureRmADApplication | where displayname -eq "SharePoint Online Site A"
$appid = $app.ApplicationId
$fullgroup = get-msolgroup -all | where displayname -eq "SharePoint Online Site A"

This is getting the two objects as variables – the Application itself, and the group that you want to add onto it.

Then a new Service Principal needs to be created based on the Application, as this is required when adding the group onto the application:

New-AzureADServicePrincipal -AppId $appid

Another variable is needed, which is the new Service Principal we just created:

$servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"

Finally, we can assign the group to the application:

New-AzureADGroupAppRoleAssignment -objectid $fullgroup.objectid -principalid $fullgroup.objectid -resourceid $serviceprincipal.objectid -id ([Guid]::Empty)

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.

Remove Microsoft Account or Work Account

If you’re using Office 365 and/or Azure, you may have run into this scenario. If you want detailed information about Microsoft Accounts vs Work or school accounts, read this comprehensive article.

For people who set up a Microsoft Account on a work email address, and then configured it for Office 365/Azure, you’d be used to seeing this screen every time you log in:

It’s necessary, but annoying when you’re signing in a lot. I’m not sure how long this has been around, but you can change the email address associated with your Microsoft account, and move it away from your work email address.

And you may notice, there’s that ‘Tired of seeing this?’ message. My brain blocked that out, so you can follow that link too :)

Atwork have a writeup on how to change the email address (the first link gives a 404 message, but you’re still in the right place to make the changes). I tested this on my own account, and within a few minutes I was no longer seeing the choice between Work or Personal when signing into Office 365/Azure services.

Combine that with ADFS or Azure AD Connect Pass-Through Authentication to make your Microsoft sign-ins a quicker process!

Azure AD Connect Pass-Through Authentication Tips

A few days ago, an updated version of Azure AD Connect was released – 1.1.371.0 (download). This included the public preview of Passthrough Authentication and Seamless Single Sign-on which lets an internal domain connected computer authenticate against an internal domain controller and sign into Office 365 resources. This gives a great cheap option to do this rather than requiring ADFS on premise to do this or just entering user credentials to authenticate against Azure AD; but there are caveats I’ll cover below.

Install Gotcha

After you’ve updated the client (regardless of the authentication type chosen), there’s a quick ‘gotcha’: The Azure AD Connect application shows a different message when you launch it:

“Synchronization has been disabled to allow changes to your current configuration. Azure Active Directory will not receive further updates until reconfiguration is complete.”


This is very different from previous versions:

As I was testing passthrough authentication at the time, I misunderstood this message to mean that something was being configured, and I had to wait. What it actually means is that by launching the application, syncs are now paused until you go finish with this program; either by making a configuration change or just exiting.

This also means that if you leave this window open, synchronization will not occur again until it’s closed – even if you have multiple servers set up. If you get an email alert saying synchronisation hasn’t occurred for a while, this is the first thing to is to check that someone didn’t leave the application open.

Azure AD Connect Passthru Auth

I’ve been waiting all year for this option, but there is a lot of misinformation around what it actually can do. After having the privilege of speaking to the Senior Program Manager on SSO and Passthru Auth for Azure AD Connect Ross Adams for two hours (thanks Ross for your invaluable time!) I found out about these key points:

  • Passthrough Authentication right now does not give you a pure automatic authentication experience. It avoids the requirement of having to retype your password, you still need to choose your account
  • Azure AD App Proxy is required for Single Sign-on and Passthrough Authentication, but won’t function for actual application proxying when in this mode. You’ll need a different box running App Proxy if you use it this way.
  • Appending your domain onto supported urls with WHR (Custom login page e.g. will reduce the amount of clicks a user needs to get in – generally a single click to pick their account

This doesn’t quite match the experience compared to having ADFS on premise, as I confirmed with friend     Ken Goodwin. This is his explanation of the ADFS experience:

If you just go to to logon, after you type in your email address it’ll redirect you to the adfs server which will automatically log you on (assuming internal). If you pre-specify the domain using, then the logon will be automatic.

This might act differently if you’re able to enable auto-acceleration on your SharePoint sites at least which drops the WHM requirement – as long as you have Azure Active Directory Premium.

Keep in mind, Passthrough Authentication and Single Sign-On are still in public preview so this may change and improve. I’m still having a mixed experience on a few items, so don’t go too crazy with rolling this out to your live setup yet. I expect we’ll see some updates soon, and finish up with a really solid new feature to improve the experience for all.

Update: Another tip – if you disable and re-enable Pass Through Auth then your old Kerberos tickets will be invalid. Wait 10 hours or run the command “Klist purge” on an affected PCs – otherwise you’ll get weird authentication errors when trying to log into a site.

Softerra Adaxes – Several Months In


Softerra Adaxes is an Active Directory management & automation tool which I’ve grown very fond of.

First I reviewed Softerra Adaxes, then I actually bought Softera Adaxes and even did a brief case study for them. I thought it would now be good to share how far we’ve come through using this tool, and what the experience is like for those considering this option of automation. Here’s my thought process and how I personally approached the rollout, along with my experiences along the way:

Initially to me, the idea of having an ‘Outlook rules’ style approach to building a system that automated user management was enough to me. We’d been creating accounts manually for a long time, and the process was documented but took 20 minutes or so to perform. There was also a lot of room for human error, especially when someone was interrupted while creating an account.

There was of course the ‘selfish’ reason of not wanting to do these user management tasks myself, but it’s hard to pass those tasks off with the inherit risks or lack of knowledge of the tools being used to ease the process. This is what had held me off writing my own giant PowerShell script to automate all the steps.

After mucking around with the Adaxes basics, I started to realise that this software solution seemed to actually deliver on what I was personally looking for – something that wasn’t complex, but also let me define whatever criteria, business rules and caveats to the user creation process that I wanted. On top of that, there was inbuilt webpages where I could deliver these options to other staff requiring no software installs, and the ability to show or lock down whatever I chose, to both control and protect the Active Directory environment.

It did take a few weeks to set up properly, but I wouldn’t have really spent more than an actual day’s worth of work in those few weeks doing it. That was just to create a new user in all the various systems I wanted, with our unique user setting requirements. I wouldn’t say the entire system is so simple and easy to navigate that you can get cracking, but it’s also not complex. Once you find the setting or understand how Adaxes achieves a solution, it’s not difficult to set things up.

The inbuilt functionality of website templates – where you can create multiple sites displaying whichever fields you like to whichever users you like – is a good way to deliver the solution to end users. You can have a page for IT and another page for Finance with completely separate functions to best fit each use case.

For me, it was great that I could create websites with zero programming requirements. It’s all driven by a GUI, and somehow it’s still very flexible in what it can do. It might be frustrating to someone who actually writes code, but that’s not who would normally be using this solution. I really feel it’s aimed at someone like me, the IT Pro/Sys Admin who wants to automate and allow others to use the tools, without needing to code or expect others to run PowerShell commands themselves.

adaxes1Basic site with one option – menu and right side options can even be hidden if required.

Once I’d finished the user creation process and published the method of doing so to a website, I had internal staff muck around with it and use it, purely for new user creations. The feedback I received was immediately positive – that 20 minute or so process had been reduced to a few minutes, and even generated out an email saying the account creation was done. This in itself to me was the tick of a successful project, and I knew I could do a lot more around automation and empowering others to do repeatable tasks.

Some of the problems I hit on the user creation automation were:

  • After upgrading from Lync 2010 to Skype for Business 2015, there were intermittent errors popping up for creating a SfB user. This was a known problem to Softerra, and took several months to resolve with a new version of Adaxes. I did have a workaround luckily, so it only took some rule modifying to work around it until a proper solution was found.
  • ‘User unknown’ – I ran into some problems where I’d create the user or enable them for Exchange, but then the next command wouldn’t find the account. Adaxes was faster than what other systems could replicate changes, so some tactful ‘start-sleep’ PowerShell command steps during the workflows to allow replication to occur before the next step triggered. This does mean that the overall process can take a minute or two, and the person who triggered the user creation has to wait for it to finish.
  • Not all functionality was available that I needed in the GUI. For example, creating a Skype for Business user is easy, but you can’t assign a policy. Instead you need to use PowerShell commands to do what you want. That took a bit longer and needed more testing, but wasn’t much of an issue once I found that out.
  • When a new user was created that already existed (e.g. another John Smith – john.smith) I hadn’t considered that scenario. I asked in the Adaxes forums and was told how to run some pre-checks to make sure the username and phone number were unique and bomb out if they weren’t, rather than half creating an account and having to clean it up afterwards.
  • The upgrade process isn’t painful when a new version of Adaxes comes out (which came out while I was doing the user creation and I wanted to try upgrading early on), but there’s a few more steps than next, next finish. An uninstall is required with backing up a few files, then a fresh install and importing what you backed up. I’m hoping that will be streamlined a bit in the future.

After the user creation process was settled, I started to create more automation tasks. Deprovisioning was an obvious one, and was a lot easier than user creation as well as taking a lot less time to set up. This command would clean up all the bits and pieces from an account, including home drives and Exchange settings (along with moving the mailbox to a different database). This was rolled out relatively quickly.

I should also note, the logging is very helpful. If someone triggers a command from the website, they can see if it was successful or not, or where it failed. It made testing easy to do, but I was also able to read through logs via the GUI on the server to find out more about what failed and why.

adaxes2Updating options on one of the web interfaces – no coding required.

I then decided to wait for common scenarios to come up and build them as needed. We often had ‘returning staff’ which if their Active Directory account still existed, I couldn’t use my user creation method when the account already exists. This took a rethink of how I’d designed my rules so far, and decided to re-do a lot of it in a more modular fashion. Because there’s the ability to copy and paste rules, this was a lot easier than I expected. The end result was that I’d have a list of modules to run against a task – e.,g. a new user would call commands such as ‘enable email’ and ‘enable Skype for Business’ which my new ‘returning staff’ would call ‘re-enable email’ but the same ‘enable Skype for Business’ command as a new user. This now meant I could move a mailbox from one database to another and unhide the user from the Global Address Book when they returned, but because all users have their Skype for Business disabled, that step was the same in either scenario.

Another valuable idea I had was to let users control the membership of Active Directory groups that they were the owner of. After some mucking around, I created a website solely for that purpose. The great part about it was that whomever logged onto the site (with passthrough authentication so no extra typing required) could only see groups they were an owner of, based on the Manager field in Active Directory. This gives anyone in the company who is in control of a group, the ability to add or remove members without any IT assistance required. Perfect for application owners who control who can get to their application or not via a security group.

My next task will be the automation of a user name change. With the updated modular design, I can copy out the steps that I need and modify them to my new requirements; of course finding the hour or two to build and test this is the hardest part. (Note: Between the week of writing this and publishing, I’ve now done it.

I’ll give praise to both the Adaxes forums and their helpdesk support via email- almost always, within 24 hours max (and usually 4-5 hours) I’d get a specific and clear answer on how to do something I couldn’t work out personally, and it was from someone who knew the product rather than a basic 1st level helpdesk type response.

I hope this gives a real impression of my experience and opinion of Softera Adaxes at a high level, after using it for an extended time. There’s no real gaps to the product that I’ve found. and you can pick and choose as to how much customisation you want to do through PowerShell scripting. I’m still happy with the product, and it will continue to evolve with us.

Intune – Couldn’t Enroll your Device

We started having issues with new enrolments to Intune. Nothing had changed that we were aware of, but registering a new device brought up the error “Couldn’t enroll your device. You can try again or send the error information to your IT admin in an email.” iOS or Android, didn’t matter:

screenshot_20160922-180510Intune Enrollment Error

After testing multiple accounts and multiple devices, I logged a call with Office 365 support, and eventually we worked out that for my account, I didn’t have a license applied. Intune sits under our Enterprise Mobility Suite package:

licenseIntune License is “Off”?

After checking other users, I found that everyone was in this ‘Off’ state. Weird, because we hadn’t done this, and Intune licensing was being managed by a group via Azure AD as per these instructions. That configuration was still in place too when I checked. I decided to do the logical thing and ‘turn it off and back on again’ – so I disabled the assignment on that page, then re-enabled the same group with the Intune license.

After then going back to the Office 365 User search, I found that all the users had now changed to ‘on’ again. The only recent event in the last few weeks was a renewal of our licenses, so I wonder if something happened in the back end as a part of that?

Anyway, if you see the ‘Couldn’t enroll your device’ message when using the Intune Company Portal app, make sure the user has their Intune license enabled!

Important Azure and Office 365 URLs for Admins

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.

Office 365
Office 365 Admin Portal
Office 365 Admin Portal (old)
Office 365 Portal with specific internal domain (modify to your own domain on the end)
Office 365 Apps

Azure AD and Old Portal
Azure AD and Old Portal to a specific domain (modify to your own domain on the end)
Azure New Portal

Intune Admin Portal

Skype For Business Online
Skype For Business Admin Portal (possibly Australia only?)

Exchange Online
Exchange Admin Center

Power BI
Exchange Online Mailbox
SharePoint Online
Office Online (Word, Excel etc)
Security and Compliance
Office Store


Microsoft have a list of all Office 365 URLs and IPs too, but that’s for you to configure your firewall preemptively rather than an Office 365/Azure Admin.

If you have any adds or changes, please let me know!


Update 7th September 2016

Microsoft have put up a giant list of links to all the Azure bits and pieces, check it out!