Post-Rename Checklist for an Okta Subdomain

Rebranding, mergers, or other initiatives require an Okta subdomain rename, such as changing <subdomain1>.okta.com to <subdomain2>.okta.com. Contact Okta Support to initiate the rename process and complete a post-rename checklist to ensure proper functionality. Proper planning minimizes service disruptions when updating agents, applications, and integrations.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Subdomain
• Administration

How is an Okta subdomain renamed?

Contact Okta Support to change the Okta subdomain. Okta Support checks the new subdomain's availability and coordinates the timing of the rename operation.

Complete the post-rename checklist.

Ensure proper functionality and minimize service disruptions by completing the post-rename checklist for agents, applications, and integrations.

• Active Directory (AD) Agents: Uninstall and reinstall each AD agent for each domain using the new Okta subdomain. Refer to the Installing and Configuring the Active Directory Agent guide for detailed instructions.
• Lightweight Directory Access Protocol (LDAP) Agents: Uninstall and reinstall each LDAP agent using the new Okta subdomain. Refer to Install the Okta LDAP Agent for detailed instructions.
• Classic Desktop Single Sign-On (SSO): Uninstall and reinstall each Integrated Windows Authentication (IWA) server using the new Okta subdomain. Refer to the Configuring Desktop SSO guide for detailed instructions.
• Agentless Desktop SSO: Recreate the Service Principal Name (SPN) Record with the new custom domain. Follow the instructions in Create a service account and configure a Service Principal Name to configure a new SPN Record. Update browser settings to trust the new SPN Uniform Resource Identifier (URI) by reviewing Configure browsers for Windows agentless Desktop Single Sign-on and Configure browsers for Mac agentless Desktop Single Sign-on.
• Remote Authentication Dial-In User Service (RADIUS) Agent: Uninstall and reinstall each Okta RADIUS agent using the new Okta subdomain. Refer to the Install and configure the RADIUS Agent guide for detailed instructions.
• RSA SecurID Agent: Uninstall and reinstall each RSA SecurID agent using the new Okta subdomain. Refer to the Install and configure the RADIUS Agent guide for detailed instructions.
• API: Update any custom code to ensure the API endpoints reference the new Okta subdomain. API tokens for Representational State Transfer (REST) API calls do not require regeneration.
• SSO Applications: Review the Security Assertion Markup Language (SAML) or Web Services Federation (WS-Fed) Sign-On setup instructions for each application. Update each SAML or WS-Fed Service Provider integration with the corrected Okta subdomain to avoid SSO login disruptions.
• OpenID Connect (OIDC) Applications: Update the issuer for each OIDC application on the Client side and on any resource servers used for token validation. Check the Issuer on both the Okta Application and Authorization Server settings to ensure they are set to either the new domain or "Dynamic" for any application using the new domain.
• Okta Verify: Reset all Okta Verify with Push Authentication enrollments. Refer to "Using Okta Verify" for instructions on resetting multifactor authentication (MFA) for end users.
• Custom Domain: Update the Canonical Name (CNAME) value of the Domain Name System (DNS) records to match the new default subdomain.
• Identity Provider: Update the Identity Provider information with the new domain name.

How is the brand name updated after a subdomain rename?

Changes to subdomain names do not automatically reflect in the default Okta subdomain brand name. Update the brand name manually by navigating to the Customizations menu in the Okta Admin Console and editing the brand settings.

1. Log in to the Okta Admin Console.
2. Navigate to Customizations > Brands.
3. Select the brand to modify.
4. Edit the Brand Name field on the settings page.
5. Save the changes.

NOTE: When using Okta Workflows, the tenant name displayed in the top-right corner of the Workflows console does not update after a subdomain change. This display remains set to the original domain name from the time of initial activation. This behavior does not affect the functionality or execution of workflows, and there is no method to modify this specific user interface (UI) display.