Migrate registry-key-based Office 365 Silent Activation to new configuration



  • This topic is intended for orgs that implemented the Early Access version of this feature prior to the 2019.09.0 release. If this applies to your org, you must complete this migration procedure.

  • If you are implementing this feature for the first time after the 2019.09.0 release, please follow the instructions in Office 365 Silent Activation: New Implementations.

This procedure describes how to migrate your registry-key-based Office 365 Silent Activation configuration to the new Kerberos-based configuration. The new configuration uses Kerberos authentication which eliminates the need of registry keys.

Start this procedure

This procedure includes the following main steps:

A. Create and test a new Kerberos subdomain

B. Create and confirm a new DNS record for your org

C. Test the new setup

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.

A. Create and test a new Kerberos subdomain

1. Add a new kerberos subdomain SPN



Use the same service account that you are using currently. Changing the service account can cause Silent Activation authentication requests to fail.

  1. In your AD environment, open a command prompt as an administrator.
  2. Run the following command to add a new Kerberos subdomain SPN:

    setspn -S HTTP/<yourorg>.kerberos.<oktaorgtype>.com <serviceAccountName>




    Your SPN.


    Your Okta org type. For example: oktapreview, okta-emea, or okta-gov.


    Your service account name. This is the name you used when configuring the Early Access version of Agentless Desktop SSO.


    setspn -S HTTP/qa-synth.kerberos.oktapreview.com spndefault



    This command does not create a new AD user account. Instead, it adds a new SPN to the existing AD user account. This command is applicable to all orgs, including those that are using a custom URL.

  3. If you have multiple AD forests, repeat Step 2 for each forest.

    SPNs are unique across a forest so you only need to do this once in each forest.

2. Verify the new kerberos subdomain SPN

  1. In Windows Powershell, enter the following command to confirm that the new DNS and SPN entries are updated:

    klist get HTTP/<yourorg>.kerberos.<oktaorgtype>.com


    klist get HTTP/atko.kerberos.oktapreview.com

  2. Confirm that you get the message about successful ticket retrieval.


3. Add the new kerberos subdomain to intranet zone

Add https://<yourorg>.kerberos.<oktaorgtype>.com to the intranet site list in your internet settings for all the devices that should use Silent Activation.

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.


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

  4. Click Close and OK on the other configuration options.

B. Create and confirm a new DNS record for your org

Prerequisite: Domain administrator privileges to set the SPN.

1. Create a new DNS record for your org

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. If the service account username is in the old format (for example: HTTP/<yourorg>.<oktaorgtype>.com), change it to the sAMAccountname or the username part of the UPN of the service account for which you set up the SPN in Part A.

    Important Note

    Service account username is case sensitive.

  5. Select Validate service account credential on save.
  6. Click Save.

This triggers the creation of a new DNS record for your org. Creating a new DNS record can take a few minutes, or in some cases, a few hours.

2. Confirm the creation of the new DNS record

Use the following dig (Mac) or nslookup (Windows) commands to confirm that the new Kerberos URL is reachable.



If you do not see a success message, run the command again after a few minutes. In some cases, record creation can take several hours. Refer to the respective command reference documentation for more information on the output messages.

For Mac

$ dig <yourorg>.kerberos.<oktaorgtype>.com



For Windows

$ nslookup <yourorg>.kerberos.<oktaorgtype>.com


C. Test the new setup


  • Test user account that has assigned Office 365 app instance and works with old Silent Activation configuration.
  • Following credentials for the test user account:
    • Domain: <yourorg>.kerberos.<oktaorgtype>.com
    • External ID: External ID of the org in which the test user is. You can find this in the script you used for the org's WS-Fed set up.
    • Username: Username part of the test user's UPN.
    • Password: Password for the test user's account.
  • Admin permissions on Windows.


  1. On Windows, as an admin run the following PowerShell command:


  2. Write down the output policy. We will use this in the last step.

  3. Change the execution policy to Unrestricted using the following command:

    Set-ExecutionPolicy Unrestricted

  4. Test a user account:

    1. Copy the following script into a text file and save the file as Test_windowsTransport.ps1.

    2. Run the following command in PowerShell:

      .\Test_windowsTransport.ps1 -domain <yourorg>.kerberos.<oktaorgtype>.com -externalId <orgexternalid> -username <testusername> -password <-testpassword>

    3. Confirm that you get the following successful SAML message:

      Valid SAML ticket received.

      This confirms that Silent Activation is successful for the test user.

  5. Change the execution policy back to the initial one from step 2 using the following command:

    Set-ExecutionPolicy <initialPolicy>

See also

Office 365 Silent Activation: New Implementations

Advanced integration topics for Office 365

Typical workflow for deploying Microsoft Office 365 in Okta