In my last post I provided details on how to connect Okta and AWS for federated account access. The goal of the federated access was to remove dependency on AWS’ IAM roles and provision role-based access via SAML. The goal of this post is mostly the same – provide federated access to Azure allowing for all Identity and Access Management to be managed via Okta.

Below is a list of high-level tasks needed to perform this request followed by the detailed step by step process.

• [In Azure] Ensure you have assigned a backup Global Administrator
• [In Azure] Ensure you have mapped a Custom Domain Name
• [In Okta] Add the Microsoft Office 365 Application
• [In Okta] Create and Assign Role Groups
• Testing

[In Azure] Ensure you have assigned a backup Global Administrator

Note: This scenario is unique in that I have freshly created this Azure account for the express purpose of documenting this setup. It is possible that you may have completed these steps prior to now. You may safely skip to the section [In Okta] Add the Microsoft Office 365 Application if these first two steps have been completed.

First, let’s log into our Azure account at https://portal.azure.com entering account information for a Global Administrator account. If you have not already started using a Custom Domain Name, this username will be something akin to the email used to sign up for Azure resources or an Azure trial. This should be <username>@<domain-name>.onmicrosoft.com.

Once logged in, navigate to the Portal Menu (hamburger meu in the top-left) > Azure Active Directory.

On the New User wizard, ensure that Create User is selected. This will create a new user in your Default Directory. Enter a username, name, select “Let me create the password” and enter a password. Under Groups and Roles, click on User and a pop-out window will enter from the right-hand side. Ccroll down to select Global Administrator, ensure that you click Select at the bottom of the pop-out, and then click Create to create the user.

This should be the second Global Administrator in the account, the first of which is the user who created the Azure account. Be sure to edit both Global Administrator user accounts to add an alternate email address should you need to recover a password in the future.

[In Azure] Ensure you have mapped a Custom Domain Name

Note: Okta Federation should not be done with the Default Directory (e.g. domain.onmicrosoft.com). In this scenario, we’ll be using a custom domain name. If you do not have a custom domain, you should create another directory in Azure Active Directory and federate the second directory with Okta – the goal being that no one except the account creator and secondary Global Admin have access to the original domain name for security and emergency, break-glass moments.

With our second Global Administrator user created, navigate to Portal Services > Azure Active Directory > Custom Domain Names. If you have added a Custom Domain, it will show here. If not, select the +Add Custom Domain. This will pop-out another menu from the right-hand side of the screen. Enter the domain name (e.g. mueller-tech.com) and select Add at the bottom of the pop-out.

This will bring you to a screen with details to verify domain ownership. In a new tab, locate your domain’s DNS servers and follow the instructions on screen. Essentially, you’ll be creating a DNS TXT record with a reference point that Microsoft will search for when we select the Verify button.

After adding the DNS record, wait approx. five minutes and head back to the Azure tab to select Verify. Should verification fail, wait another few minutes and try again. On successful verification, you’ll be brought back to the Custom Domain’s details screen. On this screen, it may show that the custom domain is still unverified. To double-check, navigate back to Portal Settings > Azure Active Directory > Custom Domain Names and the Verified checkmark should display.

[In Okta] Add the Microsoft Office 365 Application

Now that we have verified that we have both a secondary Global Administrator in our Default Directory and that we have a Custom Domain Name added, let’s create the Federation between Okta and Azure. Important note: We’re looking for account Federation. If you search Okta’s Application Catalog, you can find an app named Azure Portal Login. This is not the integration that we’re looking for – the Azure Portal Login is a Secure Web Access application that can be assigned to users – effectively a glorified bookmark.

In Okta Administrator, navigate to Applications > Applications and select Browse App Catalog. Search for Microsoft Office 365 and select Add.

You might be thinking something along the lines of: “Office 365 is certainly not the Azure Portal. I may not even be licensed for Office 365. What are we doing here?” Answer: While we’re not looking to actually utilize any of the Office Suite, we are looking to interface with Azure Active Directory which is exactly what this app does!

In the General Settings tab of the Office 365 app, update the Application Label to be more descriptive if you choose. We’ll be hiding it from users as it’s not an intuitive one-click login. Next, enter your onmicrosoft.com tenant name (e.g. the Microsoft-assigned domain name). Deselect all other apps except the Office Portal – Okta requires at least one for the integration to function. At the very bottom of the screen, select the checkbox for “Do not display this app to users” and then click Next.

On the Sign-On Options screen, select the WS-Federation radio button and leave the WS-Federation Configuration radio set to Automatic. Enter the username and password of the second Global Administrator account that we created earlier. Click on Fetch and Select.

Clicking on Fetch and Select will use your Global Admin credentials to connect to Azure AD and query available domains to Federate. Clicking in the blank box will drop-down a list of available domains – select the custom domain that we added earlier and not the Microsoft-assigned domain.

If you receive an error connecting to Azure AD, make sure that you’re entering the correct username and password. If necessary, review the account created earlier to ensure that you’ve granted the Global Administrator role.

Once you’ve selected the Domain and close the Fetch and Select screen, you’ll find the domain(s) selected now show under Office 365 Domains. At the bottom of the screen, click Done to create the Microsoft Office 365 app.

Clicking Done will bring you straight back to the Application at the General tab. Select the Provisioning tab and then click on Configure API Integration.

Next, check the box next to Enable API Integration. This will then supply a form with the same Admin Username/Password combination from the Sign-On tab. Click the button that says Authenticate with Microsoft Office 365. This should then open a new tab where Azure is requesting you to review the permissions necessary to create the Okta Microsoft Graph Client which is the mechanism used to sync data between Okta and Azure AD.

Review these permissions (or blindly accept them) and click on Accept. Once accepted, the application is provisioned in Azure. It may take a moment, but once completed the new window will close automatically bringing you back to the Okta App provisioning tab. Click on Test API credentials and you should receive a message indicating successful verification. Click Save.

After saving, you now have two more options under Settings on the left-hand side. Select the To App settings (Okta > Office 365) and select Edit on the right-hand side. We want to leave the Profile Sync radio button alone. Scrolling down, click on the Enable checkbox to the right of Create Users, Update User Attributes, Deactivate Users, and Sync Password. Under Sync Password, select the Sync Okta Password radio button and click Save.

Note: The Sync Password option will make it easier should you ever decide to remove this Federation. Rather than needing to update passwords for all users, you can have your users use their Okta password until Azure AD forces a password rotation.

[In Okta] Create and Assign Role Groups

Just like in AWS, we want to create a set of Role Groups for each role that we’ll be assigning. In Okta, navigate to Directory > Groups and click the Add Group button. In the Add Group display, enter a new group name using a syntax that is easy to decipher. The Okta-suggested syntax for the AWS was aws#<Account Alias>#<Role Name>#<Account #>. I suggest something similar for Azure. I’ve used azure#<Custom Domain Name>#<Role Name>#<last section of Tenant ID> to create two groups: azure#Mueller-Tech.Com#GroupAdministrator#e4a004aa000e and azure#Mueller-Tech.Com#UserAdministrator#e4a004aa000e.

Add a user to each group for testing purposes and then navigate to Applications > Applications > Microsoft Office 365. Click on Assign and select Assign to Groups. In the pop-up, click on Assign next to one of the groups you just created. In the next screen of the pop-up, select the Azure AD role to assign to the group and click Save and Go Back. Assign additional groups to match Azure AD roles as necessary. When finished, select Done.

Testing

Now that all of this work is done, let’s verify some things and test. Flip back to Azure and navigate to Portal Services > Azure Active Directory > Users. You should see the users that were added to groups in Okta.

Head back to Azure AD and select Custom Domain Names. Next to the Custom Domain Name, we should now see a checkmark in the Federated column.

Let’s get to testing! In an Incognito/Private window, I’ll navigate to https://portal.azure.com. Here, I’ll enter the test user account that was created earlier and click Next. As this is the first webpage open in the Incognito/Private window, this should redirect me to Okta and prompt me for login.

After entering my credentials and clicking Sign In, I’m redirected to the Azure Portal landing page!

Conclusion

This post wasn’t nearly as long as the previous post, but I hope that you found it valuable for integrating Okta and the Azure Portal. We’re one step closer to providing similar access to Azure Resources (via Azure Role Assignment) similar to how we provided role-based access to AWS accounts. I’ll cover that in the next post.

Thanks for reading!