Office 365 Silent Activation: New Implementations



The steps in this topic apply to orgs that implemented this feature for the first time after September 1, 2019 (after the 2019.09.0 release). If you have implemented the Early Access version of this feature before the 2019.09.0 release, refer to the instructions in Office 365 Silent Activation: Old Implementations.

Okta Silent Activation for Microsoft Office 365 provides a seamless experience for accessing Office 365 on laptops, desktops, shared workstations, or VDI environments. Using Okta as an identity provider, once your end users have sign in to a domain-joined Windows machine, they're automatically signed into Office 365.

Before you begin

Supported apps and configurations

  • All versions of Windows that are currently supported by Microsoft
  • Office 2016 and later
  • Supported apps: Word, Excel, Outlook, OneNote, Skype for Business, PowerPoint, Access, and Publisher
  • RC4_HMAC_MD5 encryption isn't supported with AD single sign-on and Office 365 Silent Activation. When using ADSSO or Office 365 Silent Activation, Okta recommends using AES 128-bit (AES-128) or AES 256-bit (AES-256) encryption.

Start this procedure

This procedure includes the following steps:

  1. Create a service account and an SPN

  2. Configure your browsers on Windows

  3. Enable Kerberos authentication

  4. Enable Silent Activation

  5. Test Office 365 Silent Activation

Important Note


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

Create a service account and an SPN


When creating a service account:

  • For the Okta tenant Kerberos service, use a domain user account instead of a domain admin account.
  • To further lockdown the account, turn on the logon to restriction with a fictitious host name and mark the account as Account is sensitive and can't be delegated.

  1. Sign in to a server from which you can access Active Directory Users and Computers.
  2. Right-click the folder where you want to create the service account and select NewUser.

  3. Create the account with the following values:



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

    The service account username must be 16 characters at minimum, including the domain name. Also, admin permissions aren't required for the service account, but specific permissions are needed to set the SPN. See Delegating Authority to Modify SPNs.

  4. Click Next.
  5. Create a password that is a minimum of 14 characters, and then check the Password never expires box.

  6. Click Next.
  7. Run the following command to configure an SPN for the service account:

    setspn -S HTTP/<yourorg>.kerberos.<oktaorgtype>.com <username>
    Placeholder Value
    your org Your Okta org name
    oktaorgtype Your Okta org type. For example, okta, oktapreview, okta-emea, or okta-gov.
    username Username that you created in the previous steps.

    Example: setspn -S HTTP/ OktaSilentActivation

  8. Verify that the SPN is correct by running the following command:

  9. setspn -l <username>

Configure your browsers on Windows

  1. Enable Integrated Windows Authentication on the browser.

    1. In Internet Explorer, go to SettingsInternet OptionsAdvanced.
    2. On the Advanced tab, scroll down to the Security settings, and then select Enable Integrated Windows Authentication.
    3. Click OK.

      Important Note


      Make sure that Internet Explorer can save session cookies (Internet OptionsPrivacySettingsAdvanced). If it can't, neither SSO or standard sign-in can work.

  2. Configure the Local Intranet Zone to trust Okta.

    1. In Internet Explorer, go SettingsInternet OptionsSecurity.
    2. On the Security tab, click Local IntranetSitesAdvanced.
    3. Add the URL for your Okta org as configured in the earlier steps.



    4. Click Close and OK on the other configuration options.
  3. Create a Global Policy Object (GPO) to roll this out to all client machines that use Silent Activation.

Enable Kerberos authentication

  1. In the Admin Console, go to SecurityDelegated Authentication.

  2. On the Delegated Authentication page, click the Active Directory tab.
  3. Scroll down to the Agentless Desktop SSO and Silent Activation section and click Edit.
  4. Under Active Directory Instances, find the instance for which you configured the service account.
  5. Configure this instance with the following username format:

    Field Value
    Desktop SSO Enabled
    Service Account Username


    This is the Active Directory sign-on name that you created in step 1, 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. This field is case-sensitive. When the UPN prefix differs from sAMAccountName, the service account username needs to be the same as the UPN and include the domain suffix. For example,

    Service Account Password Your Active Directory password
  6. Click Save.

Kerberos authentication is now enabled for the Office 365 app instance.

Enable Silent Activation

  1. In the Okta Admin Console, go to Applicationsyour Office 365 app instanceSign on tabEdit.
  2. In the Silent Activation section, select the checkbox to enable silent activation for the app instance.
  3. Save the settings.

Silent Activation is now enabled for the Office 365 app instance.

Test Office 365 Silent Activation

  1. Run the Office 365 Client.

    1. On a machine that has an Office 2016 client installed, open an Office 2016 client application such as Microsoft Word.
    2. Confirm that you're signed in and the client is automatically activated.

      You should see a message like the one below:

  2. Confirm the authentication through the Kerberos endpoint in Okta.

    1. In the Admin Console, go to ReportsSystem Log.

    2. On the System Log page, find the sign-in event.
    3. Expand the event to go to EventSystemLegacyEventType.

      The entry should indicate that the user was authenticated through the Kerberos endpoint.

Silent Activation is now enabled for Office 365.