Office 365 Silent Activation: New Implementations

Okta silent activation for Microsoft Office 365 provides a seamless experience for accessing Microsoft Office on shared workstations or VDI environments. Using Okta as an identity provider, once your end users have logged into a domain-joined Windows machine, they are automatically signed into Office 365 applications.

Before you begin

• Active Directory domain(s) integrated with your Okta org. See Active Directory integration.
• Permissions in Active Directory to configure a Service Principle Name (SPN). See Microsoft doc: Delegating Authority to Modify SPNs.
• 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. See Microsoft doc: Prepare to provision users through directory synchronization to Office 365.
• All Office 365 end users must 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.

Supported apps and configurations

• All versions of Windows 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 is not 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 main steps:

A. Create a service account and an SPN

B. Configure your browsers on Windows

C. Enable Kerberos authentication

D. Enable Silent Activation

E. Test Office 365 Silent Activation

A. Create a service account and an SPN

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 new service account and select New > User.

3. Create the new account with the following values:

   Field	Value
   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, . Additionally, admin permissions are not required for the service account, but specific permissions are needed to set the SPN. See Microsoft doc: Delegating Authority to Modify SPNs.

4. Click Next.

5. Create a password that is a minimum of 14 characters, and 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
   yourorg	Your Okta org name
   oktaorgtype	Your Okta org type. For example, okta, oktapreview, okta-emea, or okta-gov.
   username	Username that you created in previous steps.

   Example: setspn -S HTTP/atkodemo.kerberos.oktapreview.com OktaSilentActivation

   

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

setspn -l <username>

B. Configure your browsers on Windows

1. Enable Integrated Windows Authentication on the browser.

   In Internet Explorer,

   1. Go to Settings > Internet Options > Advanced.
   2. On the Advanced tab, scroll down to the Security settings, and select Enable Integrated Windows Authentication.

   3. Click OK.

      

      Important

      Make sure that Internet Explorer can save session cookies (Internet Options > Privacy > Settings > Advanced). If it can't, neither SSO nor standard sign in can work.

2. Configure the Local Intranet Zone to trust Okta.

   In Internet Explorer:

   1. Go to Settings > Internet Options > Security.
   2. On the Security tab, click Local Intranet > Sites > Advanced.

   3. Add the URL for your Okta org as configured in the earlier steps.

      https://<yourorg>.kerberos.<oktaorgtype>.com

      Example: https://atkodemo.kerberos.oktapreview.com

   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 will use Silent Activation.

C. Enable Kerberos authentication

In the Okta Admin Console:

1. Go to Security > Delegated 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	<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, agentlessDsso@mydomain.com.
   Service Account Password	Your Active Directory password

6. Click Save.

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

D. Enable Silent Activation

In the Okta Admin Console:

1. Go to Applications > your Office 365 app instance > Sign on tab > Edit.
2. In the Silent Activation section, select the check box to enable silent activation for the app instance.
3. Save the settings.

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

E. Test Office 365 Silent Activation

1. Run the Office 365 Client.

   On a machine that has an Office 2016 client installed,

   1. Open an Office 2016 client application such as Microsoft Word.

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

      You should see a message like the one below:

      

2. Confirm the authentication through Kerberos endpoint in Okta.

   In the Okta Admin Console:

   1. Go to Reports > System Log.
   2. On the System Log page, find the sign-in event.

   3. Expand the event to go to Event > System > LegacyEventType.

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

      

You have now successfully set up Silent Activation for Office 365.