In Advanced Server Access, a project is an authorization scopeA scope is an indication by the client that it wants to access some resource., similar to a 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). in Active Directory, or a Realm in Kerberos.
A project associates a collection of resources with a set of configurations, including RBAC and access policies.
Projects can be used to manage access to Windows servers, Linux servers, or web applications. You can think of a project as a programmable Certificate Authority for 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. certificates, including OpenSSH CA certificates and X.509 certificates, as well as signed objects such as JWTs.
No matter what you're going to secure with Advanced Server Access, you'll need at least one project. For your initial configuration, you can just create one project, and leave all the settings as defaults for now.
Creating a New Project
To create a project in the Dashboard, click Projects in the top bar, then click New Project.
Naming a Project
Choose a unique name to identify your project. It may not contain spaces or special characters, other than
Server User Account Management
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. can be configured to create and manage local user accounts on your servers. This option is enabled on new projects by default.
If your project is configured to create server accounts for 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., you can view a list of user accounts that the Advanced Server Access agent will create on servers under the "Permissions" tab of your project.
The alternative user management configurations for Advanced Server Access entail more coordination between your Identity Provider and your CM system. Please reach out to Support if you would like to deploy Advanced Server Access without enabling this feature.
The default permission level is "No Access"Be sure to grant yourself permissions to access your resources.
To grant permissions on a project to a group, under the Project view, click on the "Permissions" tab, then click "Add Group". You can then configure Server Account Permissions and other options when adding the group to the project.
During a trial or POC, it's usual to just grant permissions to the
everyone group while you're figuring out how you want to configure Advanced Server Access. You can always add more configurations later.
Server Account Permissions
When the User Management feature is enabled, Advanced Server Access will create an account for each member of a group which has been granted access to the project. You can configure the permissions of these accounts when you add the group to the project.
Choosing "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." under Server Account Permissions will cause user accounts created by the agent to have
sudo on Linux, or Administrator privileges on Windows.
Choosing "User" when granting access to a group will grant users in that group the ability to log into the server, but not to have administrative permissions on the server.Top