Server Enrollment with Advanced Server Access Agent

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. (sftd) is a daemon that runs on your servers and integrates with the Advanced Server Access Platform.

The Advanced Server Access Agent configures 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. certificate authentication for SSH and RDP, audits login events to the server, and manages local user accounts.

Installation

For detailed instructions specific to your operating system, see:

Command Line Options

  • --conf: Provide alternative configuration file path.
  • --debug-device-info: Prints detected device information to stderr and then exits.
  • -h, --help: Display help.
  • -v, --version: Display version.
  • --syslog: Force syslog logging.

Configuration File

On startup, the Advanced Server Access Agent reads its configuration file sftd.yaml in order to set configuration settings. This file is in the YAML format.

If this file is not available, sftd proceeds with the default values.

Default Configuration:

---
# Common Configuration Options:
#
# AccessAddress is unset by default
AutoEnroll:            true
# Bastion is unset by default
# CanonicalName is unset by default
# InitialURL is unset by default

Common Configuration Options

AccessAddress

default: unset

For hosts with multiple interfaces, or behind DNATs; specifies the address clients will use when connecting to this host.

AltNames

default: unset

A list of alternative hostnames for this server. These names can be used as targetnames in sft ssh.

Example:

AltNames: ["web01", "web01.example.com"]

AutoEnroll

default: true

true or false. When true, sftd will attempt to automatically enroll with Advanced Server Access on initial startup.

Bastion

default: unset

Specifies the bastion-host clients will automatically use when connecting to this host.

CanonicalName

default: unset

Specifies the name clients should use/see when connecting to this host. Overrides the name found with hostname

InitialURL

default: unset

When AutoEnroll is set to true, this option specifies the InitialURL that the server can use to auto-enroll. When an enrollment.token is provided, this option is ignored.

Additional Configuration Options

LogLevel

default: INFO

Controls the logging verbosity. Valid values are WARN, INFO or DEBUG. Runing sftd with the --debug flag is equivalent to configuring a level of DEBUG, and will override values from the config file.

BufferFile

default: /var/lib/sftd/buffer.db

Path-prefix to the file(s) that sftd will use for it's local buffer store. Individual buffers will have a '.' and an incrementing number will be appended to the path-prefix. BufferFiles which have been synchronized will be removed automatically.

EnrollmentTokenFile

default: /var/lib/sftd/enrollment.token

Path to the file containing a secret token for token based enrollment. This file is deleted after a successful enrollment to the platform.

ForwardProxy

default: none

URL to an HTTP CONNECT proxy that sftd will use for outbound network connectivity to the Advanced Server Access Platform. Alternatively, the HTTPS_PROXY enviroment variable can be used for this configuration.

ServerFile

default: /var/lib/sftd/device.server

Path to the file that sftd uses to store the server URL that it will connect to.

SSHDConfigFile

default: /etc/ssh/sshd_config

Path to sshd configuration file. Note sftd will modify this file

TokenFile

default: /var/lib/sftd/device.token

Path to file that sftd uses to store its secret token for authentication to Advanced Server Access.

TrustedUserCAKeysFile

default: /var/lib/sftd/ssh_ca.pub

Path for sftd to write the list of trusted SSH Certificate authorities to.

Files and Paths

Linux

sftd on Linux runs under the root user. Paths follow the Linux Standard Base specifications when applicable.

State Directory

/var/lib/sftd

Config File

/etc/sft/sftd.yaml

Log Directory:

sftd uses the system logger when available.

Log files will be rotated after 5MB, and the latest 10 log files will be kept.

Enrollment Token:

/var/lib/sftd/enrollment.token

Disable Autostart

/etc/sftd/disable-autostart

By default the Advanced Server Access-server-tools packages on RedHat- and Debian-derived distributions will automatically start sftd after installation. In most circumstances this will cause the agent to automatically enroll in Advanced Server Access, create local users and remove the enrollment token from disk.

If a disable-autostart file exists at the time of installation the packages will not start the agent automatically. This can be useful when building OS images using a tool like Packer. Under these circumstances it is typically preferable to remove the disable-autostart file once the package has been installed.

Windows

On Windows, the Advanced Server Access Agent runs under the LocalSystem account.

%LOCALAPPDIR% is the default prefix for all filesystem paths.

State Directory:

C:\Windows\System32\config\systemprofile\AppData\Local\scaleft

Config File:

C:\Windows\System32\config\systemprofile\AppData\Local\scaleft\sftd.yaml

Log Directory:

C:\Windows\System32\config\systemprofile\AppData\Local\scaleft\Logs

Log files will be rotated after 5MB, and the latest 10 log files will be kept.

Enrollment Token:

C:\windows\system32\config\systemprofile\AppData\Local\scaleft\enrollment.token

Environment Variables

sftd reads the following variables when starting:

  • SFT_DEBUG: Prints additional debugging to stderr when set.

Warning: Moving a server between projects will cause the new project to take over user and group synchronization, which may result in changes to local user names, UIDs or other attributes on the server. This will not remove the existing local users or 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. from the original project, but any orphaned users will no longer be accessible via Advanced Server Access, with the exception of established SSH connections (which are not terminated).

Top