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, please contact Okta Support.
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 usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. 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, 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.
- 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 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. 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 > Delegated Authentication > 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 agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. 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. 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.
- Verify that all Office 365 end usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. 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.
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 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 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.
- Windows 7 and Windows 10
- Office 2016
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.
- Access Active Directory Users and Computers in your Windows environment.
- Create a new account with the following properties.
- User logon name: HTTP/yourorg.oktapreview.com
- User logon name (pre-Windows 2000): Your Username (can be any username)
- Create a password and set the Password never expires checkbox, as shown below.
- 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.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.
Setspn -S HTTP/atkodemo.oktapreview.com OktaCloudDsso
Setspn -S HOST/atkodemo.oktapreview.com OktaCloudDsso
Setspn -l username
C:\Windows\system32>setspn -L OktaCloudDsso
Registered ServicePrincipalNames for CN=OktaCloudDsso,CN=Managed
Deploy registry key to client machines as instructed in Deploy registry keys.
The next step is to enable On-Prem Desktop SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. 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 On-Prem SSO section.
- Under AD Instances, edit the AD instance on which you configured the SPN.
- 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.
- Click the Save button. Now you can test your Office 365 silent activation on an Active Directory joined machine (VDI or shared workstation).
- Enable Browser Settings
- 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.
For correct browser configurations, see PROCEDURE to install and configure the Okta IWA Web App for Desktop SSO.