In all projects in which I am consulting with my customers, most of the questions are about the functionality of ADFS and the cloud identity. In one of my Articles I have described, how we have to configure ADFS for Office 365. In this article I have also shown the picture below, how the sign-on progress is working.
As you can see on the picture, it was made as a high level Topic. However, in this article I want to go a bit deeper into the matter of ADFS and cloud identity. This with a goal to have something for my next meeting about planning and explaining the functionality of ADFS. If you are reading, this article and it can help you too. Feel free to use it. 🙂
To start the explanation I have made a new picture for us with which we will help to understand this topic better. Everything starts with the fact, that we have two sites which are federated with each other. The first site is the on-premises one and the other the Office 365 one. In the picture below, we can see these two sites and nine orange spots. To get to our goal in this article, we will follow this orange spots:
1
If we federate to another site, in our case to Office 365, we need a tool for synchronizing our data to the other Active Directory. By using a directory sync Tool (in the most cases I work with Azure AD connect). Here we have many ways how we can configure which data we want to sync. Aside of the AD User object we can decide if we want to sync Exchange hybrid write back, Password write back, etc. For more information about the Microsoft solution (Azure AD Connect) you can follow the official Microsoft article HERE.
Configuring the client can be made by GUI or by PowerShell. Aaron Guilmette has written a fantastic PowerShell script, how this can also be done by using PowerShell. If you are interested in it, you can download it from the Technet Gallery using the link HERE.
2
In a company today, we find mostly one of the following two scenarios:
- Our Client computer are domain joined
- We have a BYOD (Bring your own device) policy.
In any case, we are working with User accounts from a specific Domain forest located in an Active Directory. By using this construction, the System admins are able to manage our permissions, SSO, and other tasks. In our case, we are going to talk about that on third and fourth point by simulating the user case progress.
3
So, let us change now the point of view, we have an employee called Desmond Miles. Desmond works for the company Contoso Ltd. and he has an AD account with the UPN [email protected]. In our example, Contoso Ltd. has an IT environment with Exchange online only. Therefore, that means, there is no Exchange installed on the on-premises site. Desmond want’s to connect to his Outlook Web App by using the Office 365 Portal.
4
If Desmond is using a Domain Joined company device, logged in with his Contoso UPN, Desmond will be redirected to ADFS and if he is inside the corporate Network, he can use Integrated Auth to automatically sign into ADFS and therefore gets straight away to his cloud services after authentication. If Desmond is using another device (eg. BYOD) or he is not working from on side, he will be shown the ADFS logon screen logon screen. By entering his UPN and pushing the TAB Key, the Office 365 Portal will check if there is a federation between Office 365 and Contoso.com. If yes, Desmond will be redirected to the companies ADFS where he needs to authenticate himself as Desmond Miles by entering his company credentials.
5
Our ADFS and AD server are now checking the entered credentials if the user really exists, if the password is correct and which permissions are assigned to the user. If the requested authentication will be approved, the ADFS server can Issue the requested client token for the Office 365 Portal.
6
Desmond doesn’t see all these steps, he simply noticed that he had to enter his credentials and after that we will be redirected to the Office 365 services. In reality, or from a technical view, our user has now an issued SAML Token form the on-premises environment. As a next step the user requests the access with his token.
7
Before the access can be granted, the Azure Active Directory makes a check if there is a synchronized cloud identity matching to the Token (e.g UPN) to logon. Here we talk about the sync progress from step 1.
8
If all tests are successful, Desmond will be signed in to his Office 365 Portal. Depending on his permissions and license plan, this could look like this:
Summary
I hope, this article helps to understand how the logon progress by using ADFS works. I also hope I was able to explain, why we need to sync information to the Azure Active Directory for having a cloud identity.
This was just one example how it can work by using our company credentials. However, a cloud identity is much more than I have written in this article, there are many other examples, how they can be used. The most of us are having at least one cloud identity, that can be a Windows Live account, Google account, Facebook account or many other too. If you are interested in it, I can write a following up article about cloud identities. In any case I can HIGHLY recommend you, to keep your online identities safe!
I have written in the past an article about keeping your emails safe, there you also can read about MFA and 2FA, also about password security etc. By further questions about this article, you have multiple options to contact me, send me a mail HERE, leave a comment, or chat with the community threw the Telegram Chanel you can find here.