I had to configure this in a PoC for a customer and I know this is not a standard configuration but yes really useful for testing in your lab or use if your customer don’t have Microsoft Active Directory Federation Services (ADFS) in place.
You have already seen this blog post, which cover this configuration step. So why am I doing this? I came across with some diferences which drove me towards this post creation. I wish this can help you on this use case as I did in a PoC with a customer.
1 – Requirements
Before starting configuring this use case, make sure you’re environment meets the following requirements:
- You have an Office 365 environment (if you don’t have it, check my previous blog about it);
- Your domain properly configured into Office 365 environment (check my other previous blog about it);
- Your environment is not configured with Microsoft ADFS (or we will be competing agains it);
- VMware Workspace ONE Access environment;
- User attributes mapped for Office 365 integration (userPrincipalName and ObjectGUID);
- This will be covered on step 3;
- Windows 10 machine with PowerShell installed;
2 – PowerShell Configuring
If this is your first time managing Office 365 along with PowerShell, you’ll figure out a lot of configurations are done using this method. To make it easier for you, I posted the command I used in my GitHub repository to help you on this task. Feel free to use it along with the examples I leave it there (and yes, those variables exemples are from nonexistent environment, so you’ll not access mine =0) ).
Start with module installation required for this configuration:
# Install AzureAD Module Install-Module -Name AzureAD # Install MSOnline Module Install-Module MSOnline
The following screen will appear to request your permission to install it.
After installing the modules, we will connect to the Microsoft Online services using this PowerShell:
# Connect to the MSOnline Services Connect-MsolService
You’ll be prompt to access using your Microsoft account (probably your onmicrosoft.com).
After you’re authenticated, we need to create a Service Principal user to being responsible to provisioning all users into Microsoft admin center side:
# Create a Service Principal user into Microsoft 365 admin center $sp = New-MsolServicePrincipal -DisplayName 365Service -Type Password -Value Password
Now it’s time to assign a Service Principal role for this user:
# Assign a role to the user Add-MsolRoleMember -RoleMemberType ServicePrincipal -RoleName 'User Account Administrator' -RoleMemberObjectId $sp.ObjectId
We will need user’s ServicePrincipalNames information to be used into Workspace ONE Access configuration. Save it, ok?
# Copying Service Principal Names to be used into Workspace One Access $sp.ServicePrincipalNames
Check the domain you have configured into your Office 365:
# Check the domains you have configured under Microsoft 365 admin center Get-MsolDomain
Your domain (in my case valcesia.com), cannot be configured if it’s default. You’ll need to change it to your onmicrosoft domain. So use this command:
# Define onmicrosoft.com domain as Default Set-MsolDomain -Name 365Domain -IsDefault
Now it’s time to set authentication type for Microsoft Online Services along with your Workspace One Access environment:
# Set Authentication type for MSOnline Services along with your VMware Workspace One Access environment Set-MsolDomainAuthentication ` -DomainName $Domain ` -Authentication $Authn ` -IssuerUri $AccessUri ` -FederationBrandName $FedName ` -PassiveLogOnUri $PassiveLogOnUri ` -ActiveLogOnUri $ActiveLogOnUri ` -LogOffUri $LogOffUri
Furthermore, you’ll need to set federation settings with your domain configured on Microsoft 365 admin center:
# Set federation settings with your domain configured on Microsoft 365 admin center Set-MsolDomainFederationSettings -DomainName $Domain
Last but not least, check whether domain is federated or not:
# Check whether domain is federated or not Get-MsolDomainFederationSettings -DomainName $Domain
3 – Workspace One Access Configuration
Remember the attributes that I specified into Step 1? This is the place you’ll need them.
Checking User Attributes
Check if your environment if properly configured accessing your Workspace One Access environment, clicking into Identity & Access Management tab and clicking in Setup.
Under User Attributes, check if userPrincipalName and objectGUID are properly configured. You’ll need to add them in case you don’t have them.
At this point, if you don’t have the users configured and synced into Workspace One Access, you’ll need to follow this blog post to make it right.
If you have it configured properly, you’ll need to sync users again to make the changes you did into attributes side to be available into corresponding mapped users.
Configuring Office 365 with Provisioning
From Workspace One Access side, it’s time to configure Office 365 with provisioning options. Click on Catalog tab and click into Web Apps.
Click in NEW.
You can configure it manually or browse it from catalog. I’ll use the catalog on which is a better way to avoid any problems during your configuration.
Search for Office365. I’ll use Office 365 with Provisioning to allow user provisioning to the Admin Center side. Select this option.
SaaS application definitions will appear, click on next to configure it.
On configuration step, make sure the configuration is like this:
- Authentication Type: WSFed 1.2
- Single Sign-One URL: https://login.microsoftonline.com/login.srf
- Username Format: Unspecified
Scrolling down configuration page, you’ll need to configure Application Parameters like my example:
- tenant: your domain [valcesia.com in my example]
- issuer: your Workspace One Access URL wthout .com [tvalcesia.vmwareidentity in my example]
Important: There are more options to be configured into Advanced Properties. I will go back to this configuration later.
On Access Policies step, I’m using the default access policy so no additional configuration will be needed at this point. If you have a different access policy, just configure it properly according your use case.
On Summary, you can see the configuration you’ve done so. Go ahead and click on Save.
The Assign page will be shown to select users or grupos to give Office 365 with Provisioning access.
I’ll put my service user account for testing purpose.
Note: You might be asking: Why do I need to go back and edit Office 365 with Provisioning if i could configure it all before? Well, you need to make sure all configuration as properly done before start creating users into Microsoft Admin Center, that’s why I think better going this way.
Go back into Catalog, select Office 365 with Provisioning and click on Edit.
On Configuration step, open Advanced Properties and select Show Provisioning Options.
You can see new options will appear into left menu (Provisioning, User Provisioning and Group Provisioning). Go ahead and click on Next.
You don’t need to change nothing into Access Policies at this time, click on Next.
On Provisioning step, you’ll need to configure it with your environment details:
- Office 365 Domain: valcesia.com (your domain configured into Office 365);
- Client ID: Copy the Client ID from PowerShell command when we created a Service Principal account;
- Client Secret: Service Principal password created using PowerShell;
Before moving forward, you have a Test Connection button, hit it to check if you have the correct information to publish users. My suggestion is to keep Enable Provisioning Disabled so far.
If all information are properly configured, you can see Connection to the Office 365 is successful message at the top page. Go ahead and click on next.
On User Provisioning Step, we need to configure the values to be used during provisioning state.
Into Display Name attribute, let’s use $(user.userName) value.
Into User Principal Name attribute, let’s use $(user.userPrincipalName) value.
Into Guid attribute, let’s use $(user.objectGUID) value.
Into Mail Nickname attribute, let’s use $(user.userName) value.
The configuration will be like the screenshot below. Hit next.
I’ll not configure any Group Provisioning at this moment, but you can select a group to make it easier for you to administer this environment. Hit Next.
On Summary page, review your configuration.
BEFORE saving it, Go back to Provisioning menu and Enable Provisioning.
The application is ready from Workspace One Access side.
From Microsoft Admin Center side, you will see the user provisioned and only the license that’s it not automatically configured (I did this with intention).
Now it’s time to sync new users from Workspace One Access side. If you need to understand how to sync users into Workspace One Access side, you can use my previous post to make it.
On Review page, just check the amount of users / groups which will be added / removed and click on Sync Directory.
You can see the user’s provisioning status by selecting Catalog tab, select Office 365 with Provisioning and click on Assign.
Check some provisioning status errors showing below. You can see if something went wrong during provisioning or retry the configuration.
If everything looks great, you can see users with Provisioned status. At this point, you’ll see the users provisioned into Office 365 Admin Center portal.
Note: This occurs with me: Some users were in an Error: not provisioned status. In my case, some users (with the same username) have already been created into Admin Center using Azure AD Connect. That’s why I mentioned into requirements section this configuration is not recommended when you have another method to provision users rather than Workspace One Access.
4 – Apply Office 365 License
You can configure it automatically from Workspace One Access side, but I think better you keep control of users (and also I would like to show you how to do it from Admin Center side).
Open your Microsoft Admin Center portal.
Check your Active users to see if you have unlicensed ones. In my case I have Sue Storm without Office 365 licenses.
Select your username and click on Manage product licenses.
The user’s information will appear and you can select location and Licenses for this user.
After you applied license properly, you can see the Microsoft 365 E5 Developer (in my case) will appear into user information.
Now it’s time to test this solution.
5- Test Time – IDP Initiated – Identity Provider
Now it’s time to check if everything is working. So I’ll start my testing using IdP initiated, which means, I’m testing it login first into Workspace One Access side.
Access your environment and type your username and password.
You can see Office 365 Provisioning into your Bookmarks / Catalog page.
Click on Office 365 to access it.
In my case it’s showing this message because I’m using a developer account but from your side, you’ll not see it (I think).
As you can see, I can access using Sue Storm account. So IdP Initiated is working!
6 – Test Time – SP Initiated (Service Provider)
Now it’s time to test the other way around: Service Provider.
Open Microsoft login page – https://login.microsoft.com/
Type your e-mail address.
You will be redirected into Workspace One Access portal to validate your username and password. Select your domain.
Type your username and password.
Once it’s validated and everything worked like a charm, you will be redirected back to the Microsoft Office 365 page but not authenticated and authorized.
All configuration looks good and not it’s time to start using it!
Enjoy the ride!