Office 365 Silent Activation Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka00z0000019tcusae&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2foffice-365-silent-activation-1127780439
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Average Rating:
Office 365 Silent Activation
Published: Apr 23, 2018   -   Updated: May 15, 2018

okta-doc-source

Office 365 Silent Activation

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, no further activation steps are required.

For more information on how to setup a shared workstation for Microsoft Office 365, refer to Overview of shared computer activation for Office 365 ProPlus on the Microsoft site.

This is an Early Access feature. To enable it, please contact Okta Support.

Prerequisites

  • Permissions in Active Directory (AD) to configure a service principal name (SPN). For details on AD permissions, refer to Delegating Authority to Modify SPNs on the Microsoft site.
  • To establish the SPN, the Okta IWA app must be installed and configured. For detailed instructions, see IWA Web App for Desktop SSO.
  • Verify that the SPN for the service account has been configured correctly in both Active Directory and on the Delegated Authentication page (Security > DelegatedAuthentication > Active Directory) in Okta.
  • 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 site.
  • You must have an active Active Directory agent in Okta for the domain tied to your user directory.
  • All verified Office 365 domains requiring silent activation must be configured for WS-Fed sign on in Okta. SWA sign on is not supported.
  • Verify that all Office 365 end users have valid licenses, such as Office 365 ProPlus.
  • All end users must be assigned to the Office 365 instance associated with their specific domain. If more than one verified Office 365 domain exists, and another requires silent activation, you must create a separate app instance in Okta, and configure WS-Fed for that particular domain.

Restrictions

Note the following configurations and restrictions that might prohibit enablement of silent activation for Office 365.

  • At this time, only single-domain and single-forest deployments are supported.
  • A Client Access Policy in Office 365 that denies web browser traffic disallows enablement.
  • App Sign On policy and Okta Sign On policy that require MFA are not supported.
  • SWA sign on is not supported.

Supported Configurations

  • Windows 7 and Windows 10
  • Office 2016

Setup Instructions

Okta uses Kerberos authentication to enable Office 365 silent activation. Setup for this exchange requires the creation of a new service account, and a unique service principal name (SPN) for the account.

Create a service account and configure an SPN

  1. Access Active Directory Users and Computers in your Windows environment.
  2. Create a new account with the following properties.

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.

Properties

User logon name: HTTP/yourorg.oktapreview.com

User logon name (pre-Windows 2000): Your Username (can be any username)

O365_SilentAWin1

  1. Create a password and set the Password never expires checkbox, as shown below.

O365_SilentAWin2

  1. Use the following syntax to configure an SPN for the service account.

Setspn -S HTTP/yourorg.oktapreview.com username

Setspn -S HOST/yourorg.oktapreview.com username

Where HTTP/yourorg.oktapreview.com and HOST/yourorg.oktaprevew.com are the user login name specified above, and username is the pre-Windows 2000 username specified above.

Example

Setspn -S HTTP/atkodemo.oktapreview.com OktaCloudDsso

Setspn -S HOST/atkodemo.oktapreview.com OktaCloudDsso

O365_SilentA3

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

Setspn -l username

C:\Windows\system32>setspn -L OktaCloudDsso

Registered ServicePrincipalNames for CN=OktaCloudDsso,CN=Managed

Service Accounts,DC=atkodemo,DC=com:

HOST/atkodemo.oktapreview.com

HTTP/atkodemo.oktapreview.com

O365_SilentA4

Enable Silent Activation

The next step is to enable On-Prem 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 On-Prem SSO section.
  5. Under AD Instances, edit the AD instance on which you configured the SPN.
  6. Configure On-Prem SSO for this domain with the following username format:

Desktop SSO: Enabled

Service principal name(spn): HTTP/yourorg.oktapreview.com

Service account password: Your AD password.

O365_SilentA5

  1. Click the Save button.

Now you can test your Office 365 silent activation on an Active Directory joined machine (VDI or shared workstation).

Validate O365 Silent Activation

Complete the following steps on a machine that has the Office 2016 client installed.

Enable Browser Settings

For correct browser configurations, see the section titled Configure Desktop SSO with IWA under Install and configure the Okta IWA Web App for Desktop SSO.

Run the O365 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:

O365_SilentA9

  1. Access the Okta System Log page to check for authentication via Kerberos endpoint.
  2. From the Administrative Dashboard, hover over the Reports drop-down menu.
  3. Scroll down and choose System Log.
  4. 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.

O365_SilentA8

Post a Comment