Use Cases

Now that you've configured a team and project, and granted permissions on the project to a group, you're ready to see Advanced Server Access in action.

The Free Trial plan includes every feature you need to try out web & infrastructure access with Advanced Server Access, including the Access Fabric, SSH, RDP, bastion support, user & group management, audit events, pre-authorizations, service usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control., and more.

Many advanced features are not enabled by default on Free Trial teams. If you'd like to learn more about our Pro and Enterprise features, please contact us.

SSH

To see the simplest SSH use case possible, you can spin up a Linux cloud server, install the Advanced Server Access 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. on it, and ssh directly to it.

Setup

At this point, you should be able to run sft list-servers and see your Linux server listed as a server you have been granted access to, and then you should be able to ssh <servername> to connect to your server with Advanced Server Access. Note that since you've configured OpenSSH ProxyCommand, your other tools which use ssh as a transport (git, scp, rsync, etc) can now natively use Advanced Server Access as well.

Next Steps

After you've built out the simplest SSH use case, a good next step is to add a second Linux server so you can try out Advanced Server Access bastion support.

RDP

To see the simplest RDP use case possible, you can spin up a Windows cloud server, install the Advanced Server Access Agent on it, and sft rdp directly to it.

Setup

At this point, you should be able to run sft list-servers and see your Windows server listed as a server you have been granted access to, and then you should be able to sft rdp <servername> to open an RDP session on your Windows server with Advanced Server Access.

Next Steps

After you've built out the simplest RDP use case, a good next step is to add a second server, a Linux server this time, so you can try out Advanced Server Access bastion support.

Notes

Port 4421

You must allow incoming connections on TCP port 4421 to the Windows server for sft rdp to succeed. Port 4421 has been allocated by IANA for Advanced Server Access's cloud server management service.

RDP Client Support

When you run the command sft rdp, the Advanced Server Access 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. will look for a supported RDP client on your workstation, and launch an authenticated RDP session with that client. On Windows workstations, the system RDP client is supported. On macOS, Advanced Server Access supports FreeRDP.

Web Access

Configuration

In Advanced Server Access, Web Access uses the same configuration concepts as Infrastructure Access. Web applications are added to Projects just as servers are, and the same RBAC and policies are used for authorization.

The simplest web application can be configured in Advanced Server Access with simply a name and an Origin hostname. The Origin hostname describes the HTTPS service where the Access Fabric will direct authorized requests.

Frontend

When a web application is configured in the Access Fabric, Advanced Server Access provides a automatically generated DNS record. This DNS record will be something like considerate-mummy-7889.accessfabric.com, and authorized users will be able to immediately access the web application by this name. Generally customers will create a CNAME record of their own, such as wiki.backend.example.com, for their users to use for these web applications instead.

Backend

Authorized requests to web applications are served via the Access Fabric. These requests include a signed JWT in a header which is forwarded to the backend web application.

To learn more about these JWTs, refer to our documentation: Access Fabric Signed Headers.

Gateway

Validating the signed JWT can be done directly in the web application, but the typical deployment uses a web gateway in front of the application. This gateway must be accessible to the Access Fabric, and serving HTTPS with a valid certificate (the most common deployment uses Let's Encrypt with Certbot).

Advanced Server Access provides Open Source modules for popular web servers to validate these JWTs:

  • httpd: https://github.com/ Advanced Server Access/mod_auth_accessfabric
  • nginx: https://github.com/ Advanced Server Access/nginx_auth_accessfabric
  • Envoy: https://github.com/ Advanced Server Access/envoy_filter_accessfabric

If we can help you by answering a question about web application deployment or configuration, please reach out to us.

Top