Configure a new Agentless Desktop Single Sign-on implementation
With agentless Desktop Single Sign-on (DSSO), you don't need to deploy IWA agents in your 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 implement DSSO functionality. This reduces or eliminates the maintenance overhead and provides high availability as Okta assumes responsibility for KerberosKerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. validation.
This diagram illustrates the Okta agentless DSSO workflow:
- You have an Active Directory 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). (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).
- If you are using a custom URL:
- Agents – Use the actual domain (example.okta.com) and not the custom domain (example.customname.com).
- IWA 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. – Modify the web.config file to include the custom url.
- To use AES128/256 encryption with agentless DSSO 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, the Kerberos error KDC_ERR_ETYPE_NOTSUPP appears in the Kerberos events log.
To enable encryption, see Windows Configurations for Kerberos Supported Encryption Type.
- Make sure that all sign-in flows and browser bookmarks use the correct URL.
- You need a service account. 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 doe 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.
- If you are using Windows functional level 2008 or below, be aware that it uses a less secure encryption RC4. We recommend that you upgrade to at least Windows functional level 2008 or above to use the most secure encryption algorithm.
- When re-enabling Agentless DSSO, Identity Provider (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.) routing rules must be manually reactivated.
- Agentless DSSO does not work when delegated authentication is disabled and Don't create Okta password is selected. To learn more about delegated authentication, see Delegated authentication.
When you implement on premises or agentless Desktop Single Sign-on (DSSO) in your environment, this is the process flow when users are imported using Just-in-Time (JIT) provisioning:
- For on premises DSSO, IWA sends Okta the Universal Principal Name (UPN). Okta uses the UPN to locate a user. Okta does not perform user authentication because Kerberos validation is done on the IIS side.
For agentless DSSO, the 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. Kerberos validation is done in the cloud in Okta.
When a user signs in using DSSO:
- If their information 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 Active Directory (AD) and the user signs in successfully.
- If their information has been imported but is not yet active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the user profile loads from AD, the user is activated, and the user signs in successfully.
- If their information has not been imported into Okta and JIT is enabled: 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 enabled. If the user name format is something other than the UPN, for example the email address or SamAccountName, the search cannot locate the user.
- If the their information has not been imported into Okta and JIT is off: Sign in fails.
In order for Okta to negotiate Kerberos authentication for agentless DSSO, you 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>.kerberos.<okta|oktapreview|okta-emea>.com <ServiceAccountName>>
Where HTTP/<myorg>.kerberos.okta.com is the SPN. <ServiceAccountName> is the value you used when configuring the Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. version of Agentless DSSO and <oktaorg> is your Okta org (either oktapreview, okta-emea or okta). For example,
setspn -S HTTP/atko.kerberos.oktapreview.com atkospnadmin.
Agentless DSSO is supported on Windows using Chrome, Chromium versions of Microsoft Edge, and Internet Explorer. Firefox and previous versions of Microsoft Edge are not supported.
There are three main steps involved in configuring the browsers on Windows:
- Enabling IWA on the browsers.
- Adding Okta to the local intranet in Internet Explorer (IE). The Okta URLs must include https://<myorg>.kerberos.okta.com.
- Creating a GPO to apply these setting across all our clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. machines.
- 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 Local Intranet > Sites > Advanced and add the URL for your Okta org as configured in earlier steps. For example: https://<myorg>.kerberos.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 DSSO is supported on Macs using Safari and Firefox. Chrome is not supported.
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 macOS Sierra: Join your Mac to a network account server.
- On the Okta Admin Console, click Security > Delegated Authentication.
- Scroll to Agentless Desktop SSO.
- Click Edit and select a DSSO mode:
- Test — allows you to test DSSO by signing in using the direct agentless DSSO endpoint URL: https://<myorg>.okta.com/login/agentlessDsso.
- On — For enabling SSO in Production. Allows end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. 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
- For Allowed network zones, add the zones that are associated with the machines from which you will be implementing agentless DSSO.
Note: If IdP 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. You will update the default IdP routing rule in Update the default DSSO Identity Provider routing rule .
- In AD Instances, select the Active Directory instance on which you configured the SPN.
- Complete these fields to configure agentless DSSO for the selected Active Directory domain:
Desktop SSO — Select Enabled or Disabled depending on whether you are enabling for production or testing.
Service account username — This is the AD sign-on name that you created in Create a service account and configure a Service Principal 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.
This field is case sensitive. When the UPN prefix differs from sAMAccountName, the service account username needs to be the same as the UPN and include the domain suffix. For example, agentlessDsso@mydomain.com.
Service account password — Password for the account that you created in AD.
- Validate service account credential on save — Optional. Validates the service account credentials as an optional step in saving the Kerberos realm configuration. If it's checked, the service account will be authenticated by the AD agent. If the credentials cannot be validated, an error message appears. If you don't want to validate or can't because the AD agent isn't responsive, the box can be unchecked to skip the validation.
- Click Save.
To complete this step you must already have an Identity Provider configuration.
After you turn on Desktop SSO, a default DSSO routing rule is created. You must configure the network information for this rule.
- On the Okta Admin Console, click Security > Identity Providers > Routing Rules.
- Select the Default Route to AgentlessDSSO rule. By default the network information is not configured and the rule is Inactive.
- Click Edit.
- Complete these fields:
- User's IP is: Select Anywhere to apply the rule to any user location, select In zone to apply the rule to a specific zone, or select Not in zone to apply the rule to users outside of a specific zone. For information on zones, see IP Zones.
- User's device platform is: Select Any device to apply the rule to users with any device type, or to apply the rule to users with specific devices, select Any of these devices and select specific devices.
- User is accessing: Select Any application to apply the rule when a user accesses any application, or to apply the rule when a user accesses specific applications, select Any of the following applications and enter an application name.
- Use this identity provider: Select AgentlessDSSO.
- Click Update Rule to save your changes.
- Click Inactive, Activate, and then Activate in the Activate Rule dialog box to activate the rule.
After configuring agentless DSSO, you can verify that everything is correctly configured.
- 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 Local Intranet > Sites > Advanced and add the URL for your Okta org as configured in earlier steps. For example, https://<myorg>.kerberos.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 through 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.
Okta recommends that you test the agentless DSSO changes before implementing widespread changes to your org.
- Create a service account and configure a Service Principal Name
- Configure browsers for agentless DSSO on Windows or Configure browsers for agentless DSSO on Mac.
- Enable agentless DSSO 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.
- Validate agentless DSSO
by signing in using the direct Agentless DSSO endpoint URL:
If agentless DSSO is configured correctly, you can sign in without being prompted for credentials. If you experience problems signing in, make sure you have completed all of the implementation procedures.
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 Single Sign-on.
If you have trouble after enabling the registry changes you can revert the registry key changes.
To revert the registry settings using the GPO, edit the previously added registry keys changing the action item from Create to Delete.Top