Hi folks! Pure Awesomeness back again! Yes, I know it’s been a stupid amount of time since my last blog post but I’m back…back again to pump as much knowledge and wisdom into your cerebrums as one individual with the title of Pure Awesomeness can!
So, sit back, relax and begin digesting the content in this blog to know about Identity and Authentication in Office 365! Wait…What? You’re the Exchange guy, right? What is this foreign topic you speak of? Well my humble apprentice, Pure Awesomeness has decided to venture out into the big bad world of Identity and Authentication and take a slight detour from the ever-changing world of Exchange. I mean, let’s face it…without identity and authentication…you’d have no email!
Ready for this? Buckle up and enjoy!
So, you’ve decided to move your on-premises workloads to Office 365. First of all, awesome decision! Secondly, have you decided on your identity and authentication model? YES/NO – Please select one.
If you selected YES, proceed to GO, collect $200 and enjoy the benefits of your new identity and authentication model! *Queue the Carlton dance*
If you selected NO, read on and prepare to be amazed at all the authentication models available to you at your fingertips…but first!…yes there’s always a first…and yes you knew this was coming…subscribe to Insentragram!
Identity…what is it? Well, quite simply, it’s who we are and how we are viewed by the world. It’s the same concept when you combine identity with Office 365. Identities in this ever-expanding and changing world tells Office 365 who we are and how we are viewed across this giant platform allows us to gain access to the resources we need to get the job done, whether it be sending that all-important email through Exchange Online or sharing the latest cat meme across a Yammer network or Teams Channel. Yep, identity spans across these workloads as well.
But Pure Awesomeness, we want to know more about Yammer and Teams as well! I can help you with one for now. Check out this blog by my sidekick Hugh Roberts (we came on board the Insentra train on the same day and almost 3.5 years later, I can call him my sidekick…because I’m just purely awesome).
Information about Teams will come in my next blog…no it won’t…yes, it will…maybe…unless my sidekick beats me to it 😛
Anyways, moving on to the topic of the hour…identity.
By now you’re probably wondering how I’m supposed to dedicate an entire blog to identity. Well, identity is just one portion of the ever-growing world of Office 365. Combine it with authentication/sign-in and you have an awesome blog written by a purely awesome individual…me!
Ok, here we go…
With Office 365, you have a few identity/sign-in models available and I’ll expand on these models as you read on.
Cloud Only Identities
In a nutshell, identities exist only in the cloud and all edits to these identities are done from the cloud. Meaning, you get married and change your surname…it gets updated in the cloud. You want a new alias email address added called dothebartman@domain.com.au… It gets added in the cloud. Pretty simple right?
Synchronised Identities
Here’s where things get interesting…in a good way…I promise. So, synchronised identities means that all your identities are synchronising in a synchronous approach to the identity platform where synchro…scratch that…basically, your on-premises Active Directory domain becomes the source of authority and all required accounts synchronise to Office 365 using a toolset called Azure Active Directory Connect (AADC). Everything you were able to do with your account in a cloud only identity model, now can only happen from on-premises, hence the term “source of authority”.
But did you know that AADC has various options available when configuring user sign-in methods? No? Sweet! That’s what this blog is for. See the work of art screenshot below outlining the options available:
Don’t worry, I’ll explain each below but before I do, just know that this is how Microsoft lists the above options, from simple to set up, all the way through to complex:
- Password hash (or password synchronisation)
- Seamless SSO (single sign-on)
- Pass-through authentication (PTA)
- ADFS
Password Synchronisation
Before you panic…this is a secure way to sync your password to the cloud. AADC extracts the password hash and syncs to Azure Active Directory. There is absolutely no way to reveal or convert the password to plain text and all it takes to implement this is a single check box. See, simple!
But there is one catch to this model – if your on-premises account expired, users can still log into Office 365 using the password hash as Azure AD has no concept of account expiration. Look at the brighter side of this statement…if your on-premises environment gets “taken out”, whether it be cyber attack or a nuclear meltdown because Homer wasn’t doing his job, password hash (or synchronisation) provides a form of DR.
Oh and before I forget…if you change your password on-premises, the change is synchronised to Office 365 in about 2 minutes!
Seamless SSO
Works with Password Synchronisation and as the name suggests, provides a single sign-on model without the need for additional infrastructure. Pretty cool right? The catch is that it only provides SSO capabilities to Office 365 for users inside the corporate network. Where your traditional federation model using ADFS or a 3rd party platform would provide SSO for users outside of the network, Seamless SSO through AADC only applies to internal users. It’s supported with password synchronisation or PTA and is as simple as checking the “Enable Single Sign-On” box in the AADC configuration. You’ll also need to do the following through GPO:
- Add https://autologon.microsoftazuread-sso.com to the Intranet Zone
- Enable “Allow updates to status bar via script”
Next up, we have…
Pass-Through Authentication (PTA)
Want to enforce your on-premises Active Directory security and password policies? This is the sign-in model for you! Basically, allows the user to sign into both Office 365 and on-premises resources using the same password, where the password is validated against the on-premises directory. Nothing is stored in the cloud!
To enable PTA, a lightweight agent is deployed across the on-premises infrastructure and the beauty with this agent is that it’s self-managed, meaning you, as the administrator, don’t need to continually deploy the latest updates to the agent. It does it itself! There are, however, a few things to take note of when deploying PTA:
- If you already use password synchronisation, don’t deploy PTA
- PTA takes precedence over password synchronisation
- Turning off PTA requires that the AAD Connect server has internet connectivity – you can use PowerShell to switch the tenant to use password synchronisation if the on-premises environment goes down
- PTA agent connectivity issues will prevent users from authenticating
- There is no logic in the PTA agents to load balance traffic
Deploy more than one PTA agent – by default, the first PTA agent deploys on the AAD Connect server
ADFS
In a nutshell, provides users (both internal and external to the network) with single sign-on capabilities, but requires additional hardware and infrastructure on-premises, depending on how in-depth you want to go with redundancy and high availability. I won’t go into too much detail with ADFS but just know that Microsoft has listed this option as the most complex to set up because of the additional configuration and infrastructure required.
The decision to use ADFS is obviously going to come down to business requirements, however, explore other options, such as password synchronisation or PTA.
There you have it, folks…a bit of a lengthy blog post this time around and focusing on a completely different topic, but nonetheless, still an important topic to discuss and include in your overall transition to Office 365.
Until next time, Pure Awesomeness signing off!
“You miss 100 percent of the shots you don’t take.” – Wayne Gretzky
