Office 365 Silent Activation: Old Implementations
This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, contact Okta Support.
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 usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. have logged into a domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https).-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 Office 365 ProPlus on the Microsoft website.
- You have an Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. domain (or multiple domains) integrated with your Okta orgThe Okta container that represents a real-world organization.. 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 KerberosKerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. service, instead of a domain adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. 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 ClientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. Access Policy in Office 365 is set to deny web browsers, it will also block the Silent Activation.
- If your appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. or Okta sign-on policy requires MFA for web browsers, there will be no MFA when logging in through Silent Activation.
- SWAAn acronym for Secure Web Authentication. SWA is a SSO system developed by Okta to provide single sign-on for apps that don't support proprietary federated sign-on methods or SAML. Users can enter their credentials for these apps on their homepage. These credentials are stored such that users can access their apps without entering their credentials each time. When users first sign-in to a SWA app from their homepage, they see a pop-up message asking if they were able to sign-in successfully. 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:
Verify that the SPN is correct by entering the following text:
Setspn -S HTTP/yourorg.kerberos.oktapreview.com <username>
HTTP/yourorg.kerberos.oktapreview.com is the SPN and
<username> is the value specified in Step 2 of this section.
Setspn -l <username>
STEP 2: Deploy registry keys
- Deploy registry key to client machines as instructed in the STEP 4 of Configure Agentless Desktop SSO with Registry Keys (deprecated).
- 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 AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect..
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 on 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.