What causes the redirect in the first place is that Okta detects that a user is seen to be on an internal registered IP address (i.e. to determine if the users on the internal network or not). Once that’s been detected (and you can register up multiple IP addresses and or ranges of addresses), the next thing is to direct the user to the right IIS web server where the Integrated Windows Authentication (IWA) module is running. We do this by a “Global Redirect”. This is detailed in the notes that I’ve copied and pasted from our internal support site:
The information here describes the Global Redirect URL option (see screenshot below) for Desktop SSO. This feature allows untrusted domains to use Desktop SSO.
When “Use global redirect URL” is selected, Okta gives customers the flexibility to resolve and loadbalance Okta IWA servers. This flexibility allows untrusted domains to use Desktop SSO. In the screenshot above, I’ve configured a global redirect URL of http://oktadesktopsso.company.com, which is a nonexistent target. The customer shall create a CNAME DNS entry for this URL at each domain where there are IWA servers. Ideally, each domain will have multiple IWA servers installed, and the CNAME entry will point to a loadbalancer URL that fronts the IWA servers. As an example, consider the following scenario. Let’s say there are two untrusted domains: abc.com and xyz.com. Domain abc.com has agent1, agent2, and agent3. Domain xyz.com has agent4 and agent5. All agents and gateway IPs from abc.com and xyz.com are registered with Okta. When a user from abc.com hits Okta, Okta will redirect the user to http://oktadesktopsso.company.com. The DNS server/load balancer at abc.com will redirect to either agent1, agent2, or agent3. When a user from xyz.com hits Okta, Okta will redirect the user to http://oktadesktopsso.company.com. The DNS server/load balancer at xyz.com will redirect to either agent4 or agent5.
1) by mistake, "Mode" would need to be 'on' to test, otherwise manual AD authentication would occur. 2) No you won't acheive the same behaviour, because with "Manual failover" or "Automatic failover" Okta wil not invoke/ redirect the user to the 'Global redirect' URL. This step is important, because then you 'Global C-names' in your Corporate/internal network facing can redirect the users request to WHICHEVER Desktop SSO Agent is LOCAL to that employee ....
say Australian 'Desktop SSO' plugin
for Australian employee
sitting behind Australian AD domain/ DC/ domain credential's
...rather than being authenticated against the UK domain controller.
tHis 'Global Redirect' feature need's to be used in conjunction with global A-name or CName changes that your network/ DNS admin makes to support the underlying resolution of requests by your employee's to access the 'desktopsso.companycom' URL. in other words DNS is responsible for redirecting the request in the employee's browser to the correct (local or regional) [remember Australia] Okta Desktop SSO plugin (sitting on IIS & usually your AD Agent.)
I have a scenario in which my current two Okta IWA agents app configured on "Automatic failover" need to be migrated to AWS's EC2 instances with "Global Redirect URL" configuration along with the load balancer. Can you please help me the necessary steps that I should take for this migration, considering in mind that there should be no downtime for the users?
Note:- Active directory on AWS, will be just extended active directory from the current On-premise active directory