Office 365 Silent Activation: Old 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.

Prerequisites

• 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 for directory synchronization to Microsoft 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.

Limitations

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.

Supported configurations

• All versions of Windows currently supported by Microsoft
• Office 2016 and later

Setup instructions

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

1. Sign in to a server from which you can access Active Directory Users and Computers.

2. Create a new account with the following properties:

   Property	Value
   User logon name	<username>
   User logon name (pre-Windows 2000)	<username> (can be any username)

   

   Note

   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.

3. Create a password and check the Password never expires box, as shown below:

   

4. 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>

Where HTTP/yourorg.kerberos.oktapreview.com is the SPN and <username> is the value specified in Step 2 of this section.

Example:



5. Verify that the SPN is correct by entering the following text:

Setspn -l <username>

STEP 2: Deploy registry keys

1. Deploy registry key to client machines. See Active Directory Desktop Single Sign-on.
2. 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:

1. Enabling IWA on the browsers

2. Adding Okta as a trusted site to the Local Intranet Zone in Internet Explorer (IE)

3. Creating a GPO to apply these settings across all your client machines

To configure your browsers:

1. Enable IWA on the browsers

   1. In Internet Explorer, select ToolsInternet Options.

   2. Click the Advanced tab, scroll down to the Security settings, and select Enable Integrated Windows Authentication.

   3. Click OK.

      

      Note

      Make sure that Internet Explorer can save session cookies (Internet OptionsPrivacy tab). If it cannot, neither SSO nor standard sign in can work.

2. Configure the Local Intranet Zone to trust Okta:

   1. In Internet Explorer, open OptionsSecurity.

   2. Click Local IntranetSitesAdvanced and add the URL for your Okta org as configured in the earlier steps.

      For example: https://<myorg>.kerberos.okta.com.

   3. Click Close and OK on the other configuration options.
3. 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.

1. From the Administrative Dashboard, hover over the Security drop-down menu.
2. Scroll down and choose Delegated Authentication.
3. On the Delegated Authentication page, click the Active Directory tab.
4. Scroll down to find the Agentless Desktop SSO section.

5. Click the Edit button at the top right corner of the Agentless Desktop SSO section.

6. Under AD Instances, find the instance for which you configured the Service Account Username.

7. Configure this instance with the following username format:

   Field	Value
   Desktop SSO	Enabled
   Service Account Username	<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

8. 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:

1. Run the Office 365 Client:
1. Open an Office 2016 client application such as Microsoft Word.

2. Validate that you are signed in and that the client is automatically activated.

   You should see a message like the one below:

   

2. Access the Okta System Log page to check for authentication via Kerberos endpoint.
3. From the Administrative Dashboard, hover over the Reports drop-down menu.

4. Scroll down and choose System Log.

   From the System Log page, find the event and use the arrow to drill down to EventSystemLegacyEventType.

   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.

Related Topics

• Get started with Office 365 sign on policies

• App sign-on policies