This Series is authored by Ruchir Parikh.

Welcome back to our “Demystifying Upgrading to OIE Series”!. 

This episode is the Appendixes to Episode #2a.

Appendix 1: What configurations need to be copied from Okta Production to Preview 

The following are the key configurations you need to make sure are in your Okta Classic Preview org in order to maximize the value of first upgrading and testing in Preview before performing your Production upgrade. Please note that the following information assumes the Okta Preview tenant is on Okta Classic. If you have already upgraded your preview environment to OIE, contact your Okta Account team, and a new Classic tenant can be provided for testing (an additional cost might be applicable based on licensing). 

1. Customers should copy their configured Policies from Okta Production into Preview.

• Okta Admin → Security → Authentication
  • Password Policies
  • Sign-On Policies
• Okta Admin → Security → Multifactor
  • Factor Types 
    • Enable the same factors in Okta Preview that are enabled in Production. 
  • Factor Enrollment policies 
• Okta Admin → Application → Applications → Application of Choice → Sign On
  • You can use the Rockstar Browser Plugin in Okta Classic to export per-app policies and see which apps have custom policies. 
• Customers should integrate third-party directories into their Preview environment if they have use cases that are being used currently in Production. 
  • Directory integrations are not affected by the OIE upgrade. 
  • If you have a directory integrated in Okta Production, doing like-for-like testing in Preview can ensure that nothing is missed. 

1. Customers do not need to configure all their SAML/OIDC OIN applications from Okta Production into Preview. 

• The OIE upgrade does not change how SAML and OIDC authentication occur.
• If you have a custom SAML/OIDC application that was developed internally, it is HIGHLY recommended that customers replicate this in Okta Preview and upgrade to OIE with these custom apps to ensure the expected behavior continues post-OIE upgrade. 
• Customers with custom authentication flows can configure their custom per-app sign-on policies using Bookmark apps to mimic the end-user experience post-OIE upgrade.

Appendix 2: Atko HytekSys Tenant Blockers & remediation steps

Below are the blockers we will cover in this blog post, as well as the series and links to documentation on remediating them. Please note that this series will not cover all the blockers a customer may see but will focus on those about which customers have the most questions. Mobile and Desktop Device Trust and Okta Customizations/API changes will be covered in their respective blog posts. 

Blocker #1: IWA Routing Rules

IWA Routing Rules falls in the “Customer Configuration Required” bucket.

Remediation Steps: 

• Remediation can be done while still in Okta Classic. 
• IWA is not and won't be supported in OIE. 
• Customers need to delete their IWA routing rule in their Okta Admin Console. (Settings → Identity Providers → Routing rules → find and delete the IWA routing rule)
• NOTE: 
  • If you have Desktop Device Trust, set up in Okta Classic, do not remove the on-prem IWA Agents, as they are needed after the upgrade for Desktop Device Trust. After moving to the new Desktop Device Trust platform in OIE, it is safe to decommission the on-prem IWA agents.  

How to achieve a similar experience in OIE: 

• Customers who want to keep a similar experience in OIE must configure Agentless Desktop SSO (ADSSO). 
  • There is a slight change in the end-user experience associated with ADSSO. End-users will see different interstitial pages. 
  • ADSSO can be configured while still on Okta Classic
  • ADSSO will become primary, and IWA will be the fallback; end-users will log in via IWA if there are issues.
• Another option is to move to Oka Fastpass after the OIE upgrade.
  • NOTE: This will significantly alter the end-user experience. Please ensure proper communication with the end users so as not to cause confusion. 

Tips and Tricks: 

• The most common issues customers encounter when configuring/moving to  ADSSO:
  • Creating a service account and configuring a Service Principal Name
    • Ensure you follow each step carefully. 
    • Step 9 from the above article is optional.
    • For step 10, copy and paste the command into a text editor and modify the Okta URL and the service account name to match your environment.  
  • Configuring browsers on Windows and Mac for ADSSO
    • The URL from IWA has changed. 
    • Each browser has its own steps on how to configure it.
    • Ensure the URL matches your Okta environment.    

Documentation: 

• OIE Upgrade Blocker - IWA Routing Rules (okta.com)
• Migrate from Integrated Windows Authentication to agentless Desktop Single Sign-on | Okta
• Configure agentless Desktop Single Sign-on | Okta

Blocker #2: Kerberos Alias

Kerberos Alias is in the “Okta Assistance Required” bucket.

Remediation Steps: 

• Customers with this blocker configured ADSSO during its initial launch. ADSSO has been re-designed, and due to the re-design, customers need to have this feature enabled by Okta Support.
  • Customers who have enabled ADSSO in the past for testing but do not actively use it can enable the feature with no additional steps needed. 
  • Customers who do actively use ADSSO, please ensure you do the following two steps: 
    •  Creating a service account and configuring a Service Principal Name
      • Ensure you follow each step carefully. 
      • Step 9 is optional.
      • For step 10, copy and paste the command into a text editor and modify the Okta URL and the service account name to match your environment.  
    • Configuring browsers on Windows and Mac for ADSSO
      • Each browser has its own steps on how to configure it.
      • Ensure the URL matches your Okta environment.   

Documentation: 

• OIE Upgrade Blocker - KERBEROS_ALIAS (okta.com)

Office 365 Pass Claims for MFA

“Office 365 Pass Claims for MFA” is in the “Consent Required” bucket.

Remediation Steps: 

• Remediation for this blocker must happen after your OIE upgrade. 
• After your OIE upgrade, customers must go into their Office 365 per-application policies and ensure the “User must authenticate with” setting is set to either “Any 2 factor types” or “ Password/IDP + Another factor.” 

Tips and Tricks: 

• In OIE, per-application policies can be updated programmatically via Okta’s API if your tenant has multiple Office 365 applications. 
  • https://developer.okta.com/docs/reference/api/policy/#authentication-policy  

Documentation: 

• OIE Upgrade Blocker - OFFICE365_PASS_CLAIM_FOR_MFA (okta.com)

Email Factor Policies Optional

Email Factor Policies Optional is in the “Consent Required” bucket.

Remediation Steps: 

• Under Settings > Features, enable the Feature “Enable optional email enrollment for Okta Identity Engine”.  NOTE:  This feature has zero impact in classic, but once upgraded to OIE this feature will ensure that the behavior of the “optional” setting for Email factor enrollment remains very much the same as you experience today in classic.  
• In the OIE Upgrade Hub, acknowledge the item titled “After the upgrade to Okta Identity Engine, email will not be auto-enrolled as an authenticator unless it is required.”  The “change” in behavior described is only a change to what had previously been the default behavior in OIE only.  In reality, the behavior you have enabled is the same behavior you currently experience in classic, so it is safe to acknowledge this and move forward.

How to achieve a similar experience in OIE: 

• Under Settings > Features, enable the Feature “Enable optional email enrollment for Okta Identity Engine”.

Documentation 

• OIE Upgrade Blocker - Email Optional Enrollment (okta.com)

Contributors:

Brent Arrington 

Dimitri Volkmann