Office 365 Silent Activation: Old Implementations
The steps in this topic apply to orgs that implemented the Early Access version of this feature prior to the 2019.09.0 release. If you are implementing this feature for the first time after September 1, 2019 (after 2019.09.0), refer to the instructions in Office 365 Silent Activation: New Implementations.
Okta Office 365 Silent Activation allows for a seamless experience for accessing Microsoft Office. Using Okta as an identity provider, this option enables silent activation for shared workstation or VDI environments. Once your end users have logged into a domain-joined Windows machine, they will be automatically signed into Office 365 applications.
For more information on how to setup a shared workstation for Microsoft Office 365, refer to Overview of shared computer activation for Microsoft 365 Apps on the Microsoft website.
- You have an Active Directory domain (or multiple domains) integrated with your Okta org. For more information on integrating AD domains in Okta, see Active Directory integration.
You have permissions in Active Directory to configure a Service Principle Name (SPN). For more information on permissions, see Delegating Authority to Modify SPNs.
- You will need to create a service account, as described below. For this service account:
- A domain user account is recommended, for the Okta tenant Kerberos service, instead of a domain admin account as a security best practice.
- To further lock down the account, the logon to restriction can be turned on with a fictitious host name, and the account can be marked as Account is sensitive and cannot be delegated. This is also for security reasons.
- The user's Active Directory UPN must match the Office 365 UPN. The Office 365 application username can be configured to map any AD attribute. For more details, refer to Prepare to provision users through directory synchronization to Office 365 on the Microsoft website.
- Verify that all Office 365 end users have valid licenses.
- All end users must be assigned to the Office 365 instance associated with their specific domain.
- Users must be able to reach domain controllers.
The following configurations and restrictions prohibit enablement of Silent Activation for Office 365:
- If a Client Access Policy in Office 365 is set to deny web browsers, it will also block the Silent Activation.
- If your app or Okta sign-on policy requires MFA for web browsers, there will be no MFA when logging in through Silent Activation.
- SWA sign-on is not supported.
- All versions of Windows currently supported by Microsoft
- Office 2016 and later
Okta uses Kerberos authentication to enable Silent Activation for Office 365. Setup for this exchange requires the creation of a new service account, and a unique service principal name (SPN) for the account.
STEP 1: Create a service account and configure an SPN
- Sign in to a server from which you can access Active Directory Users and Computers.
Create a new account with the following properties:
User logon name <username> User logon name (pre-Windows 2000) <username> (can be any username)
Admin permissions are not required for the service account, but specific permissions are needed to set the SPN, as documented in Delegating Authority to Modify SPNs on the Microsoft site.
Create a password and check the Password never expires box, as shown below:
Open a Command Prompt and use the following syntax to configure an SPN for the service account:Setspn -S HTTP/yourorg.kerberos.oktapreview.com <username>
Verify that the SPN is correct by entering the following text:Setspn -l <username>
HTTP/yourorg.kerberos.oktapreview.com is the SPN and
<username> is the value specified in Step 2 of this section.
STEP 2: Deploy registry keys
- Deploy registry key to client machines. See Active Directory Desktop Single Sign-on.
- Use the following content to create a REG file on the client machine, when deploying registry keys on a single machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149] "winword.exe"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149] "powerpnt.exe"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149] "outlook.exe"=dword:00000001
STEP 3: Configure your browsers on Windows
There are three main steps involved in configuring your browsers on Windows:
Enabling IWA on the browsers
Adding Okta as a trusted site to the Local Intranet Zone in Internet Explorer (IE)
Creating a GPO to apply these settings across all your client machines
To configure your browsers:
Enable IWA on the browsers
In Internet Explorer, select Tools > Internet Options.
- Click the Advanced tab, scroll down to the Security settings, and select Enable Integrated Windows Authentication.
Make sure that Internet Explorer can save session cookies (Internet Options > Privacy tab). If it cannot, neither SSO nor standard sign in can work.
Configure the Local Intranet Zone to trust Okta:
- In Internet Explorer, open Options > Security.
Click Local Intranet > Sites > Advanced and add the URL for your Okta org as configured in the earlier steps.
- Click Close and OK on the other configuration options.
- Create a GPO to roll this out to all client machines that will use Silent Activation.
STEP 4: Enable Silent Activation
The next step is to enable Agentless Desktop SSO within Okta.
- From the Administrative Dashboard, hover over the Security drop-down menu.
- Scroll down and choose Delegated Authentication.
- On the Delegated Authentication page, click the Active Directory tab.
- Scroll down to find the Agentless Desktop SSO section.
Click the Edit button at the top right corner of the Agentless Desktop SSO section.
- Under AD Instances, find the instance for which you configured the Service Account Username.
Configure this instance with the following username format:
Desktop SSO Enabled Service Account Username
Note:This is the Active Directory sign-on name that you created in STEP 1: Create a service account and configure an SPN , without any domain suffix or Netbios name prefix. It can be the sAMAccountName or the username part of the UPN. These two may be the same string unless the Org admin chose to use different values.
Service account password Your AD password
Click the Save button.
Now you can test your Office 365 Silent Activation on an Active Directory joined machine (VDI or shared workstation).
STEP 5: Validate Office 365 Silent Activation
Complete the following steps on a machine that has the Office 2016 client installed:
- Run the Office 365 Client:
- Open an Office 2016 client application such as Microsoft Word.
Validate that you are signed in and that the client is automatically activated.
You should see a message like the one below:
- Access the Okta System Log page to check for authentication via Kerberos endpoint.
- From the Administrative Dashboard, hover over the Reports drop-down menu.
Scroll down and choose System Log.
From the System Log page, find the event and use the arrow to drill down to Event > System > LegacyEventType.
The entry should indicate that the user was authenticated through the Kerberos endpoint.
Once you have finished validating Silent Activation you have successfully complete the setup.