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. (DSSO) is the functionality that allows users to be automatically authenticated by Okta, and any apps accessed through Okta, whenever they sign-in to your Windows network. It provides a superior user-experience as users don’t have to sign in multiple times.
Traditionally, enabling Desktop SSO required deploying IWA agents. Agentless desktop SSO eliminates the need to deploy IWA agents across Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. domains to enable DSSO. This enables you to have no maintenance overhead and also removes the burden of worrying about High Availability as Okta handles the Kerberos validation. Diagram
As you configure Desktop SSO (on prem or agentless) in your environment, be aware of how the Desktop SSO flow works when importing users and how Just in Time (JIT) authentication will occur.
- If using on-prem DSSO IWA always sends Okta the Universal Principal Name (UPN). This is the only data Okta uses to look up a user. Okta does not perform authentication for users because Kerberos validation is already done on the IIS side.
If using Agentless Desktop SSO, your web browser sends the Kerberos ticket to Okta, and relies on the AD 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. to look up the UPN. The Kerberos validation is now done in the cloud in Okta.
When a user tries to sign in using Desktop SSO:
- If the user is already imported and active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the profile reloads from AD and the user signs in.
- If the user is imported but not yet active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the profile loads from AD, is activated and the user signs in.
- If the user has not been imported into Okta and JIT is on: Okta can only validate the user by the UPN. So the Okta user name format must be the UPN in order for the user to be successfully imported with JIT turned on. If the user name format is something other than the UPN, for example the email address or SamAccountName, the search will fail to locate the user.
- If the user has not been imported into Okta and JIT is off: User sign in will fail.
- Custom URL —
If you are using the Custom URL feature and integrating with one of the Okta agents, take note of the following:
- Agents – Need to be installed against the actual 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). (example.okta.com), not the custom domain (example.customname.com). This applies to all agents.
- If using IWA SSO – You should modify the web.config file to include the custom url. The configuration will continue to work without these modifications, but it could cause confusion for your end user if their sign-in attempt fails and they end up on a different domain.
- If you are using Agentless DSSO – Because you can only specify one SPN when setting up Agentless DSSO, you should ensure that all your sign-in flows and browser bookmarks use the URL you want ADSSO to use.
- Using AES128 or AES256 encryption — If you want to use AES128/256 with Agentless Desktop SSO or MS 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. silent activation, you must enable AES for both the AD domain as well as the service account for Okta DSSO. If it isn't enabled for the AD domain you will see a Kerberos error KDC_ERR_ETYPE_NOTSUPP in the Kerberos events.
For details on how to enable each of these, refer to Windows Configurations for Kerberos Supported Encryption Type.
You have an Active Directory domain (or multiple domains) integrated with your Okta orgThe Okta container that represents a real-world organization..
You have permissions in Active Directory to configure a Service Principal Name (SPN). For more info on permissions, see Delegating Authority to Modify SPNs at the following URL: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731241(v=ws.11).
- You will need to create a service account, as described below. For this service account:
- A domain user account is recommended, for the Okta tenant Kerberos service, instead of a domain adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. account as a security best practice.
- To further lock down the account, the logon to restriction can be turned on with a fictitious host name, and the account can be marked as Account is sensitive and cannot be delegated. This is also for security reasons.
- Agentless DSSO will not work if a single user has memberships to more than 600 security groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. — If an end user tries to go through the Agentless DSSO flow and has more than 600 security groups, they will see a 400 response and be redirected to the regular sign in page.
- The following browsers are not supported:
- Firefox on Windows
- Chrome on macOS.
- MS Edge
- If you are using Windows functional level 2008 or below, be aware that it uses a less secure encryption RS4. We recommend that you upgrade to at least Windows functional level 2008 or above to use the most secure encryption algorithm.
Setting up Agentless Desktop SSO involves the following steps:
- Create a service account and configure an SPN
- Configure Browsers on Windows or Mac
- STEP 4: Deploy registry keys to client machines
- STEP 5: Enable Agentless Desktop SSO
- Validate Agentless Desktop SSO
- Steps that may apply to your environment:
In order for Okta to negotiate Kerberos authentication for Agentless Desktop SSO, you will need to create a new service account and set a Service Principal Name (SPN) for that service account.
- Sign in to a server from which you can access Active Directory Users and Computers.
- Create a new account with the following properties. The service account itself does not need admin permissions, but you will need specific permissions to set an SPN as mentioned in Delegating Authority to Modify SPNs
User logon name: <username>
User logon name (pre-Windows 2000) : <username>
where <username> is any username of your choice.
Select a password and set to Password never expires.
In a Command window, configure an SPN for the service account, using the following syntax:
Setspn -S HTTP/<myorg>.okta.com <username>
Where HTTP/<myorg>.okta.com.com is the SPN and <username> are the values specified in step 2. For example,
Setspn -S HTTP/atko.okta.com atkospnadmin
The next step is to configure your browsers.
Configuring changes on Internet Explorer (IE) will be enough as Chrome will recognize these settings.
Note: Firefox and Edge are not supported.
There are three main steps involved in configuring the browsers on Windows:
- Enabling IWA on the browsers
- Adding Okta as a trusted site to the Local Intranet Zone in Internet Explorer (IE)
- Creating a GPO to apply these setting across all our client machines.
To configure your browsers:
- Enable IWA on the browsers:
- In Internet Explorer select Tools > Internet Options.
- Click the Advanced tab, scroll down to the Security settings, and select Enable Integrated Windows AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect..
- Click OK.
Note: Make sure that Internet Explorer can save session cookies (Internet Options > Privacy tab). If it cannot, neither SSO nor standard sign in can work.
- Configure the Local Intranet Zone to trust Okta:
- In IE, open Options > Security.
- Click on Local Intranet > Sites > Advanced and add the URL for your Okta org as configured in earlier steps. For example, https://<myorg>.okta.com.
- Click Close and OK on the other configuration options.
- Create a GPO to roll this out to all client machines that will use Agentless DSSO.
Agentless Desktop SSO is currently not supported on Chrome on macOS.
DSSO is enabled automatically in Safari on OS/X. Make sure that the macOS host is a Windows domain member. For how to add your Macintosh OS/X host to a Windows domain, see the article macOS Sierra: Join your Mac to a network account server.
Agentless Desktop SSO is currently not supported on Chrome.
Now that you’ve configured your SPN, and browsers, you will create a Group Policy Object to deploy registry keys.
Why registry keys?
Okta uses CNAME alias' to resolve to the Okta org. So when you make a request to <myorg>.okta.com, that subdomain is an alias to various load balancers. This is a modern Cloud infrastructure pattern to eliminate maintenance overhead. To support this architecture registry keys need to be deployed to tell any apps that rely on Kerberos to use CNAME and not ANAME.
You will need to add a registry key entry for each app that depends on Kerberos authentication for Agentless DSSO. This includes the Chrome and Internet Explorer browsers and any other thick clients that you may have. You can decide which apps to include based on whether you want Agentless DSSO functionality enabled for them. For example, if you have four native apps: MSWord, Excel, PowerPoint, and GoToMeeting and you only want Agentless DSSO on the GoToMeeting app then you'd need to add a registry key for the GoToMeeting app.
Important: Wildcards are NOT recommended as they could have unexpected consequences on other applications that rely on DNS.
Implications of enabling the registry keys
By deploying these registry keys, the behavior of all web apps that depend on Kerberos for authentication will change to resolve to CNAME rather than ANAME
You need to check the SPN set for these applications and see whether that SPN is an ANAME or a CNAME and decide:
- If the SPN is an A name, change the SPN to a CNAME.
- If the SPN is a CNAME, leave it as is.
Okta recommends that you test the Agentless DSSO changes in a limited scopeA scope is an indication by the client that it wants to access some resource. before rolling out widespread changes to your org. This includes deploying the registry key changes on a small but representative selection of machines in your domain. For details, see Test Agentless DSSO before rolling out to production
This section describes the deploying the registry keys on individual machines for test purposes and through Group Policy Objects when you are ready for production.
Before rolling out the registry key changes to all machines, you can test the implementation by applying the changes to individual machines.
To apply this on a single machine, create a .reg file on the machine with the following content inside of it:
Windows Registry Editor Version 5.00
Deploying registry keys through Group Policy
To deploy the registry key changes across your org, you will use Group Policies.
In order to create a group policy to apply broadly, do the following as a domain administrator from your domain controller:
- Launch Active Directory Users and Computers.
- Right click in the navigation structure and select New > Organizational Unit (OUAn acronym of Organizational Unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. It is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority.).
- Name the OU. This will be the computers OU used for this change
- From a domain controller run the command gpedit.msc to open the Group Policy Editor.
- In the Group Policy Management console, right click on Group Policy Objects.
- Select New, to create a new group policy object (GPO).
- Name the GPO and leave Source Starter GPO set to (none).
- Right click on the new GPO and select Edit
- Navigate to Computer Configuration > Preferences> Windows Settings > Registry
- Right click on Registry and select New Item, enter the following items values. Repeat the process for all of the below registry entries.
- For Internet Explorer:
Create Hive HKEY_LOCAL_MACHINE Keypath SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149 Value Name iexplore.exe Value Type REG_DWORD Value Data 1 Action Create Hive HKEY_LOCAL_MACHINE Keypath SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_CNAME_FOR_SPN_KB911149 Value Name iexplore.exe Value Type REG_DWORD Value Data 1
- For Chrome:
Action Create Hive HKEY_LOCAL_MACHINE Keypath SOFTWARE\Policies\Google\Chrome Value Name DisableAuthNegotiateCnameLookup Value Type REG_DWORD Value Data 1
The next step is to turn on Agentless DSSO.
You can enable Agentless Desktop SSO for testing or for production.
- Test — allows you to test by signing in using the direct Agentless DSSO endpoint URL:
- On — allows 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. to sign in from the default sign in endpoint, routing through the Agentless DSSO sign in endpoint. The end user doesn't need to explicitly type in the DSSO URL.
To enable Agentless DSSO:
- In the Okta Admin dashboard, navigate to Security > Delegated Authentication.
- Scroll to Agentless Desktop SSO.
- Click Edit and select a Desktop SSO mode:
- Test — For testing in your Preview environment.
- On — For enabling SSO in Production.
- For Allowed network zones, add the zones that are associated with the machines from which you will be implementing Agentless SSO.
Note: If IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. Discovery is turned on, the network zone options will not be available. When IdP Discovery and Agentless DSSO are both on, Agentless DSSO network zones are controlled through the IdP Routing Rules. For details, see Configure IdP Discovery.
- In AD Instances, select the Active Directory instance on which you configured the SPN.
- Configure Agentless Desktop SSO for this Active Directory domain with the following information and then Save.
Desktop SSO — Select Enable or Disabled depending on whether you are enabling for production or testing.
Service account username — This is the AD Sign on name, without any domain suffix or Netbios name prefix. It can be the sAMAccountName or the username part of the UPN. These two may be the same string unless the Org admin chose to use different values.
Service account password — Password for the account that you created in AD.
Once a domain has been configured and enabled users will be able to sign in with Agentless DSSO.
The next step is to validate Agentless DSSO is configured correctly.
After configuring Agentless DSSO, you can verify that everything is correctly configured by doing the following:
- Sign in to a domain-joined, on-network device that is joined to the Active Directory environment on which you have enabled Agentless Desktop SSO. Ensure that you are logged in as a user that is already active in Okta.
- If you haven’t already, add your Okta environment to your Local Intranet settings.
- In a browser, open Options > Security.
- Click on Local Intranet > Sites > Advanced and add the URL for your Okta org as configured in earlier steps. For example, https://<myorg>.okta.com.
- Click Close and OK on the other configuration options.
- On a Windows machine, sign into your Okta org. If Agentless DSSO is configured correctly, you will be automatically redirected to your end user apps dashboard without entering any credentials.
- Verify in the system log that the user authenticated via Agentless Desktop SSO. In your Okta org, you will see an entry for Authenticate user via IWA with no entries referring to an on-prem IWA server.
Procedures that may apply to your environment
Okta recommends that you test the Agentless DSSO changes in a limited scope before rolling out widespread changes to your org. This includes deploying the registry key changes on a small but representative selection of machines in your domain.
To test Agentless DSSO, follow these general steps:
- STEP 1: Create a service account and configure an SPN
- Perform the steps in STEP 2: Configure browsers for SSO on Windows and STEP 3: Configure browsers for SSO on Mac as appropriate.
- Deploying registry keys on a single machine
- STEP 5: Enable Agentless Desktop SSO in test mode
- Optional — Enable Kerberos event logging. For more information, see https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging.
- STEP 6: Validate Agentless Desktop SSO
by signing in using the direct Agentless DSSO endpoint URL:
If Agentless DSSO is configured correctly, you will be able to sign in without being prompted for credentials. If you experience problems signing in, ensure you have completed all the steps listed above. You can check the Troubleshooting section for additional help.
You may wish to have a back up plan in the event that Agentless DSSO fails. There are two fail over options:
- Okta will automatically fail over to the default sign-in page.
- You can use on-prem IWA DSSO as a backup.
Choosing to fail over to on-prem IWA DSSO, requires you to install and configure the on-prem IWA DSSO. If on-prem IWA DSSO is configured and enabled, it will automatically take over if Agentless DSSO stops working. For details, see Install and configure the Okta IWA Web agent for Desktop SSO.
If you have trouble after enabling the registry changes you can roll back the registry key changes you've made.
To roll back the registry settings using the GPO, simply edit the previously added registry keys changing the action item from Create to Delete.
Can I run Agentless DSSO and IWA Web App for Desktop SSO at the same time?
Yes. When both are enabled and the user tries to sign in, Okta first tries authenticating against Agentless DSSO and if that fails, it falls back to the on-prem IWA server.
Can I use Agentless DSSO while remote?
No. You need to be on-network to sign in via Agentless DSSO. However if using a VPN, Agentless DSSO will work.
Do I need to open any special ports for this to work?
Do computers need to be domain joined?
Yes. In order for Agentless DSSO to work, the computer needs to be domain joined.
Do I need to install an agent on my machines?
No. Agentless DSSO removes the need to have any IWA agents on your machines. Instead the Kerberos validation is done on Okta's servers.
When troubleshooting I see a 401 error from Okta, does this mean something is failing?
No that's expected. When the end user goes to the browser and types in <myorg>.okta.com, Okta sees your org has Agentless DSSO enabled and kicks off a 401 authenticate challenge to your KDC which then returns a Kerberos ticket back to Okta.
Can I recreate re-write rules?
Does my UPN domain name suffix need to be the same as the AD domain’s primary DNS suffix?
No. Okta uses the user SID to locate and authenticate the user. So it shouldn't matter if they don't match because the request resolves to the user object using SID.
Does Agentless DSSO have any rate limits?
The current rate limit for the Agentless DSSO endpoint /login/agentlessDSSO is 1000/minute. This is double the on-prem rate limit as described in Concurrent Rate Limits because each successful login performs two http commands to the Agentless DSSO endpoint. The number of successful logins per minute will be the same as on-prem IWA.
With Agentless DSSO enabled, you browse to your Okta tenant and see the regular sign in page.
You were not routed to the Agentless DSSO endpoint. Confirm your IP address is added to the correct zone and that zone is used for the Agentless DSSO.
I am working remote and Agentless DSSO doesn't work.
In order for Agentless DSSO to work your browser must be able to connect to the Key Distribution Center (KDC) on your domain. This is crucial to the Kerberos validation. If you are unable to reach the KDC you will not obtain a Kerberos ticket and will not be able to authenticate. If available, join your network via a Virtual Private Network (VPN). If the KDC is available via the VPN, Agentless DSSO will work.
I am in the right zone and on-prem and Agentless DSSO still fails.
Confirm the username and password are correct for the SPN account both in AD and as stored in the Okta configuration. If the account expired or was changed it will break the flow.
I have verified I am in the correct zone, verified the account used for the SPN is correct, I am on-premises and Agentless DSSO still fails.
This could suggest some type of Kerberos failure. Using tools such as Wireshark, capture your network traffic during your Agentless DSSO attempt. Once captured, filter for Kerberos traffic. Compare this traffic to the Event Viewer logs on your KDC. Using these two tools (or similar) you should be able to uncover Kerberos failures.
Note: In order to see debug-level Kerberos events you may need to enable Kerberos event logging. For more information, see https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging.
Kerberos validator and sign in failure
If the clock skew between your corporate network and Okta Agentless SSO becomes too great, Kerberos validation and sign in will fail. This issue will not occur if your domain controller's clock is synced to an external time server.
Slow or failed sign-on experience
During Agentless DSSO sign-in Okta does a SID look-up. During the EA time frame this is being done with a call to the AD Agent. If you experience a slow sign-in experience or failed sign-ins consider increasing the number of polling threads for your AD Agents or adding new AD Agents for your domains. For details on how to do this, see Install multiple Okta AD agents and Change the number of Okta Active Directory (AD) agent threads.
If this occurs, you will see the AD Agent logs filled with a large number of read LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. calls, without any Next action = NONE lines shown. For example:
2018/06/11 23:14:34.441 Debug -- N079-H076(57) -- Sending result for READ_LDAP action (id=ADS2n15k1yGW23cn10g7) finished, (executionTime=00:00:00.2196026)