Okta Advanced Server Access

Case Study

Prior to our implementation, the client’s system administrators had unfettered, organization-wide access to all of their Windows servers via Remote Desktop Protocol (RDP). Furthermore, they struggled through an arduous, bloated process for adding new users and servers to Active Directory (AD) and granting remote access capabilities due to legacy AD configurations.

For this project, we had three main objectives which made Advance Server Access (ASA) a good fit for the client:

  1. Secure RDP access to internal IT assets with Multi-Factor Authentication (MFA)
  2. Re-tool a mess of security groups and AD group policy
  3. Simplify administration of users and expedite setup of new IT assets

Figure 1. (small-scale representation of this simplistic process)

After implementing ASA, we were able to restrict RDP connections via a combination of internal firewalling and Group Policy to only allow RDP access from the Okta ASA gateway.

Figure 2.

Worth noting is that in Figure 1., users are prompted to approve an Okta Verify prompt, thus satisfying the client’s need for MFA on remote sessions.

In order to address the complexities of governing access to newly added infrastructure, ASA’s automation features were configured. Okta ASA was configured to query the client’s AD, and newly provisioned servers are added and sorted to specific “projects” in ASA via Lightweight Direct Access Protocol (LDAP) queries.

A “project” in ASA is simply a group of servers.

Thus, infrastructure teams at the client site need to merely stand-up new servers and join them to AD – from there, Okta automatically doles out access to the correct team members. No further action is required as long as they have the “Safe File Transfer (SFT) Client”, as pictured above, installed on their device.

Finally, to untangle AD, groups of users with RDP permissions were flattened and sorted into Okta groups via Group Rules (IE users with help desk, infosec, sysadmin, app-dev, etc. mentioned in their Okta user profile).

Okta then assigned ASA project access based on these new group memberships. From thereon, any new users or adjustments to existing users are automatically permissioned and assigned access to servers within their business function, without any extra configuration required.