Initial Configuration

Creating a Team

Before using Advanced Server Access, the first thing to do is to create a team in the Advanced Server Access dashboard.

Every team requires a unique team name, and Okta tenant which Advanced Server Access can use to authenticate 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. in your team.

Team names are case-insensitive, alphanumeric, and may contain dots, dashes, and underscores. Generally, to use Advanced Server Access, you will only need one team, which you can name after your company. If, for right now, you are only going to run a trial or POC of Advanced Server Access at your company, you might want to name the trial team something like <companyname>-trial.

Configuring a Project

  1. Navigate to the "Projects" tab, and click "New Project".
  2. Name your project (could be something like demo), and click "Submit".
  3. Navigate to the "Permissions" tab and click "Add Group" to grant permissions on the project to a group of users.

Adding a group to your project lets you grant 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. of users access to the resources in that project. If you're just trying Advanced Server Access out for the first time, you can just use the pre-existing everyone group, and select the "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." option to grant maximum permissions.

Later, when you've added servers to the project, and more users have joined your team, configuring projects and groups more deliberately will allow you fine-grained control of access across your servers.

Setting up infrastructure access

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 one or more servers, and enroll those servers in your Project.

The Advanced Server Access Agent will automatically configure your servers to trust certificates issued by the Advanced Server Access Platform as a method to authenticate SSH or RDP users.

You can also configure the agent to create user accounts for the members of your team, and even manage administrative access with Advanced Server Access roles and permissions.

First-time User Setup

Have team members install 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. and enroll it with Advanced Server Access.

The recommended SSH integration method uses ssh proxycommand so users can use ssh transparently.

Once installed by the users in your team, the Advanced Server Access client will connect to the Advanced Server Access Platform to verify users against your 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.).

While a team member remains authenticated, the client manages the dynamic credentials that enable that user to authenticate to any resources they may access.