Okta recently released the AD-Joined feature for Okta Advanced Server Access. This feature extends ASA secured RDP access to Windows servers in an AD domain, leveraging user credentials also stored in Active Directory. The feature supports both traditional password-based access and passwordless access using AD certificates, with the flexibility of having a mix of both as needed. This article provides an overview of the mechanics of the new feature and how you can configure Okta to manage AD accounts in ASA.
Article contents:
An Overview of the AD-Joined Feature
Traditional ASA server connect flows with SSH and RDP to local servers involves an ASA client on the users workstation, leveraging the ASA and Okta cloud services for authentication and authorization, and an ASA server agent on the target servers (steps 1 – 4 in the following diagram). Traffic may be routed via ASA bastions and/or gateways. It relies on having that Server Agent deployed onto the target servers (and enrolled against projects) providing user/group management, certificate signing authority management and SSH daemon functionality on Windows.
However this approach will not work in a Windows Active Directory environment, where users are managed centrally, and Windows servers come and go in AD. To support AD-Joined servers, the ASA gateway was enhanced to work with AD domain controllers in multiple ways as shown in the following figure.
First, as the servers in the domain change, we need to be able to maintain the server list in the projects. This is done through a discovery process tied to specific AD connections (step 0).
Second, rather than deploying the ASA server agent onto each Windows server in the domain, the user connects (transparently) to the gateway. The gateway will perform user authentication (step 5) and the RDP to the individual Windows server (step 6).
The user authentication to AD from the gateway supports multiple AD accounts associated with each Okta user, and each AD account could be authenticated with a password to AD or in a passwordless mode (with certificate-based authentication to AD). The remainder of this article will explore how we map the AD accounts to the user and how it flows down to ASA.
Exploring the Mapping of AD Accounts in Okta and ASA
To support the AD-Joined mechanism, two new attributes have been added to the ASA user schema in ASA: activeDirectoryIdentity and activeDirectoryPasswordlessIdentity. Both are string array values. They represent a set of AD accounts that can be used for a user in password or passwordless modes.
ASA is an application in Okta with provisioning enabled, leveraging SCIM to provision user (and group) changes to ASA.
Within Okta (Universal Directory) the ASA users are represented in the ASA (application) user profile. Both attributes can be mapped to Okta user profile attributes using standard profile attribute mapping. You could have both ASA attributes mapped to a single Okta string array attribute (i.e. the user could access each AD account with or without a password). Or you could have different Okta profile attributes to represent different sets of AD accounts (some requiting password access and some using passswordless). This is a design decision on your part.
The final piece of the puzzle is where these AD accounts are coming from to populate the Okta profile attributes. One source is directly from AD, where the AD agent will provide AD accounts that can be mapped to one of these attributes. This makes sense when the Okta user is AD-mastered. The AD userName attribute is multi-valued so if there are multiple accounts for a user in AD, they can all be populated into the Okta profile attribute.
There may be other AD accounts you want to associate with an Okta user. For example, perhaps you have some privileged accounts (like DBA shared accounts) that you want to allow users to request for a period of time. These could be tied to some access request (like in Okta Identity Governance) or other external process to assign them, then API calls or Okta workflows could apply the accounts to this Okta profile attributes.
The following figure shows an example of how this mapping could occur.
In the diagram, the normal user AD accounts are imported via the AD agent and stored in the AD profile userName attribute. Profile attribute mapping will apply this set of values into a custom Okta profile attribute (asa_ad_accounts_passwordless) which is a string array. The profile attribute mapping will apply this attribute to the ASA profile attribute (activeDirectoryPasswordlessIdentity) and any profile change will trigger the provisioning to ASA.
There are also a set of AD DBA accounts that can be requested. The mechanism isn’t important, but there is a Workflow flow to add/remove the three AD DBA accounts into a custom Okta profile attribute (asa_ad_accounts) which is a string array. The profile attribute mapping will apply this attribute to the ASA profile attribute (activeDirectoryIdentity) and any profile change will trigger the provisioning to ASA.
Thus in this example, the end user will see their primary AD account(s) and three DBA accounts (if they have requested them) when they RDP. For example:
The rest of this article will look at how it’s implemented.
Implementing the Data Mapping
The AD-Joined documentation (https://help.okta.com/asa/en-us/Content/Topics/Adv_Server_Access/docs/ad-user-manage.htm) covers how to implement the mapping. The following shows an example of implementing the above scenario.
AD Profile Attribute
We are using a standard (Base) attribute of userName (userPrincipalName) that will be imported into the AD profiles from the AD Agent.
An example is shown below.
Okta Profile Attributes
In the Okta profile I added to new custom attributes, both string arrays.
They are standard string arrays on the profile.
An example is shown below.
ASA Profile Attributes
Two new attributes have been added to the ASA schema. For existing Okta+ASA deployments they need be added. For newer deployments they should be there.
An example of this is shown below.
AD to Okta Profile Attribute Mapping
In this example, we are mapping the AD userName attribute to the Okta passwordless attribute, and nothing is mapped to the other attribute, as shown below.
The other attribute, in this example is being managed by two Workflows tied to a dummy application (request access to dummy app triggers flow to update the password attribute, asa_ad_accounts, with a set of AD DBA accounts).
Okta to ASA Profile Attribute Mapping
The Okta to ASA Profile attribute mapping in this example has a 1:1 mapping from the two attributes in Okta to the corresponding attributes in ASA.
The end result of this can be viewed in the ASA administration console.
With these attributes populated, the user can access the accounts when RDP’ing.
This completes this article.
